SIerとリーダブルコードのほどよい着地点を考えてみる
リーダブルコード、良書ですよね〜
プログラマならぜひ一度は読んで欲しいと思いました
最近社内で勉強会でスピーカーをする機会があったので、
この本の内容の紹介と、特筆して紹介したい部分を話しました。
ただ、その際の資料作成と実際の勉強会での反応を受けて、
いろいろ思うところがありました。
1. 納期の壁
リーダブルコードに書かれている内容はすばらしいです、
やっぱり綺麗なコードが一番だと思います。
でも、やはり現実的には理想論的な部分もあると思います。
納期が存在する受託開発の場合、
どうしても付きまとうのが「で、間に合うの？」という話。
私：どうですか！？すごい読みやすくて綺麗なコードでしょう！？
上司：で、間に合うの？
私：いえ、無理です！！
上司：おい！
こうなるのは目に見えています。
そこで思うのは、
「そんな一気に綺麗にしようとせずに、少しずつ全員の意識を変えればいいじゃない」
という案
でも・・・
2. スポットメンバーの壁
全員が「いつものメンバー」なら問題なしです。
でもよくある状況として
私：この期間だときびしいです！
上司：あと１ヶ月で４人月ぶんだな！よし、BPと新人で４人投入だ！
私：うわー！！
こういうケース。
妊婦さん９人集めても１ヶ月じゃ赤ちゃんは産めないの！！
上の例は結構極端ですが、
一時期だけ入ってすぐ抜けてしまうようなメンバーがいた場合、
リーダブルコードを徹底することによるメリットが薄くなってしまいます。
徹底したとしても
私：いいですか、綺麗なコードを書いてくださいね！
BPさん：はい、わかりました！
〜１ヶ月後〜
BPさん：どうですか！綺麗なコードでしょう！
私：すてき！
上司：で、終わったの？
BPさん：いえ！では契約終了なのでさようなら！
私：さようなら！
上司：おい！
こうなります。
そして最大の障壁が・・・
3. 古株との意識の壁
リーダブルコードの勉強会内で
「returnを使ったガード文を利用してネストを浅くするといいですよ！」
と紹介しました。
すると、
「returnは１個しか使ったらダメだって教わった」
という意見が聞けました。
リーダブルコードに書かれている内容の中には、
古くからエンジニアをされている方が教わった内容と
相反する部分がどうしても出てくるようです。
他に考えられる例としては、たとえば
「変数は使う箇所の近くで定義する」
なども挙げられると思います。
こういうときにどう説明するのかが難しいな〜、
というより、どう説き伏せるかを考えないといけないんだな、と感じました。
というわけで
色々と問題がたくさん。
どうしていけばいいんだろう・・・？
私はあくまでも「リーダブルコードは素晴らしい」という考えです。
やっぱりこの考えは広めたい。
自分なりに少し考えてみました。
1. アンチパターンを用意する
ただし、あくまでも納期などを考える必要があるため、
ここでいうアンチパターンというのは
「こういうコーディングをしてはいけません！」
ということではなく
「こういうのはあんまり綺麗じゃないですよ」
というもの。
期間が無い状況などで出来るだけ高い効果を出すためには
ガチガチにしばるのではなく、ざっくりとした方針だけを示すのがベストだと思います。
そのときに、やはり口頭だけでは分かり難いので、
簡単な例を用意しておけばいいのかな〜と思いました。
極端な例ですが、たとえば変数名で
var newOrderIdForRegistrationNewManagedUser
とかを見せて、「ほら、長いでしょう？」みたいな。
覚えさせるよりも雰囲気を感じ取ってもらうほうがいいと思います。
2. 相反する意見の理由も知っておく
先ほどの例でいうと
「returnは１個だ！」
と言われて
「は！？バカじゃねえの！？」
と言わないようにしましょう。
今、returnを複数使うことで読みやすくなるケースがある、というのに理由があるように、
returnは1個だ、というのも根拠があるということです。
かくゆう私も「なんでだろう？」と思って調べたところ、
構造化プログラミングの考えから、goto＝悪！みたいな認識が広がり、
制御ルーチンは上からちゃんと読めるようにしようね！
↓
途中でreturnしたら飛ぶからこれもやめようね！
みたいなことだという認識です。
でもこれも立派な考えであり、先人の知恵です。
これを認めた上で
・言語や取り巻く環境などが変わっていること
・むしろreturnが多い方が可読性が上がること
などを説明すれば分かってもらえる・・・かもしれません。
（だめかもしれないけど
3. あきらめない
でました！精神論！
もはや究極はコレかなと。
もう正直、自分だけでも徹底的に頑張るしかないと思いました。
そしてその上でパフォーマンスも出すと。
身をもって綺麗なコードのメリットを証明するのが一番説得力がある気がします。
と言ってしまうとひどいですが、
案外周りを見渡すと同感してくれる人がいるもんだと思います。
むしろ意外と多いかもしれませんよ。
少しずつ意識改革を広げていくのも重要なことだと思います。
というわけで、結局何が言いたかったの？みたいな内容でしたが、
私は綺麗なコードを書いていきたいです。
お わ り
