昼間、エンジニアのパートタイムな仕事再開して5ヶ月経ちます。以前は自分が仕切ってやっていた開発ですが、今は自分より全然優秀な（そしてきちんとコミュニケーション能力があり、すぐに結果を出せる）エンジニアが上にいてくれるので、すごく気が楽です。もうね、方針とかコーディング規約とかプロジェクト進行の細則とか、好みちゃうのって思うような小さいところまで全部おまかせにして、それに従うようにしています。僕の好み通りにコーディングしたところで、僕がずっとこの会社にいるわけでもないのでね。それなら、統一性があった方がずっといい。
で、コードレビューの際にそういう指摘を受けて修正する機会が多くあるんですけど、そのうちの1つがとにかく徹底的にシンプル志向。少しでも技巧的な処理を行うと、「難読なのでシンプルな構造にしてください」という指摘を受けます。なんだろう、例えば入れ子の三項演算子とか一目でNG。そんなの僕も好きじゃないのでやらないけど。変数が多く乱立してるのもお好みじゃないみたいで、array_map() とかarray_filter() とかを無名関数と組み合わせて処理するのが好きみたい。その方が見えにくくなることもあるんじゃないの、と思ったりもするけれど、処理部分を明確にわけておきたいというのは理解出来ます。そうしておけば後で手を入れることになったとき、わかりやすいしね。
現在触っているプログラム群は、僕が退職後に導入された新システムで、今の上司が入社する前に、外注先で作られたシステムなんだけど、これがねー。あんまり言及するのはよして置くけど、難読って言うか場当たり的に建てられててすごくメンテナンス性が悪いのよね。700行くらいswitch構文につっこむとか平気でやってるし。しかもその中で変数使い回したり、global変数呼んだりやりたい放題で、コードが難しいというよりかは純粋にわかりづらい。きっと納期ギリギリで、リファクタリングする暇がなかったんだろうね。今2人でタスクをこなしながら触った部分はリファクタリングを進めてるけど、まあ大変。僕が来るまでに1年くらいあるのかな、そう考えると今はまだマシになった方だろうし、そこでの経験もシンプル志向の元になっているのかも。
個人的にはコードの難読性と、プログラム全体の難読性は必ずしも一致しない、部分であれば短い行数で終えることを志向してもいいのではと思ったりするんだけど、でも同時に、誰か優秀な人が言うことにとりあえず従ってみて結果を見てみるというのも面白いよねと思って日々働いてます。若い頃だったら議論したかも知れないけど、まあ今はね。自分の思い通りにコーディング出来なくたって何に影響することもない、そもそも賞与も昇給もないんだし評価されるということ自体がない、ストレスもなんもない、むしろ違う考え方を知れて面白いと思うし。
この考え方は、未経験で飲食に入れてもらってそこで「私は何も知りません」というスタイルで全部言われたとおりにやってみて、身についた考え方かな。決して「自分の意見を持たずに他人の言うとおりにする」って言うことではなくて、自分の狭い了見でごちゃごちゃ言う前に、他人のいうことも試してみるべき、そういう意見を聞く耳を持つべき、自分の実力が劣る場合にはそれが一番早く成長する手段ってこと。自分のこだわりを持つのはそれからでも遅くないし。
なんか、大人になっちゃったなー。
とか言いつつ、今でもすげー小さいことで議論しようとしたりするけど（笑）
ま、性分が変わったわけではないってことで。
「シンプル志向」と他人の意見を聞くことと
