なんかコメント書く書かないというそれが話題になっていて、それ自体はそういうところもあるんだなあという感じではあったんですが。
リーダブル・コードの名前がちらほらと出ていたので、また自分の振り返りもかねて、ちょっとまとめてみたいと思います。
「わかりやすさ」に全力
本書はその主眼を「プログラムのわかりやすさ」ということに置いていて、具体的には
・変数名などを明確に名付ける
・コードの見た目は美しく。ブロック、インデントを駆使して整理整頓する。
・コメントは「読み手」に伝えたいことを書く。コードだけでは伝わらないことを書く。
・制御の流れは浅く、追いやすく、簡潔に。ネストは浅めに。gotoは使うな。
・変数のスコープ(寿命)は短く。余計な変数は使わない。
・処理はまとめて汎用的に抽出する。インターフェースは簡潔に整理。
・ひとつの処理でひとつのことを。簡潔に説明していくように。コードサイズは小さく保つ。
・テストはひとつづつ、明確な名前を付け、追加しやすいように簡単、単純に。そして役に立つエラー情報を。
といったことが、具体例を交えて書かれています。
普段から気をつけていること、なるほどということ、真似しようということ、ちょっと合わないなあということなど感想はいろいろだと思いますし、この本が絶対だというつもりではないですが、プログラムを書く方であれば一読しておいて損はない、と言い切れる本だと思います。
また、コードを全く書いたことが無くこれから書き始める方より、少し書いたことのある方のほうが実感できてより読みやすいかもしれません。
時代に合わない部分もある？
それはそれとして件のエントリにおいて、追記で入っている部分。
ブコメでも指摘を頂いた通り、プログラムで表現しきれない部分は、すべてコミットメッセージやコードレビューのログ、チケットへのコメントなどに書いています。コミットとコードレビューのログはチケットに紐付いており、相互参照が可能です。
結局コメント書いてるじゃんと思われるかもしれませんが、「なぜこの修正を行ったのか」「修正前後で動作がどう違うのか」などの情報は、プログラムそのものではなくコミットやチケットに付随する情報のため、プログラムのコメントとして残すのは不適切です。さらにいえば、プログラムのコメントはドキュメントとしての可読性に乏しいので、より詳しい情報を書こうとすればするほど読みにくくなります。ただのプレーンテキストなのですから当然です。それならば、文字の修飾、ファイル添付、ユーザIDのコールなどの機能が使えるチケットにコメントを書くほうが理にかなっているでしょう。
なおコードレビューに関しては、デベロッパー全員がレビュアーとしての役割を担っており、各チケットに関して複数人がレビュアーにアサインされます。結構これが厳しくて、なんてことないコードであっても、少しでも改善の余地があると判断されればリジェクト食らいます。
プログラムの仕様書にあたるドキュメントについては、詳細かつ簡潔（1チームにつき Word 数十ページ程度）にまとまったものが共有されており、仕様変更が発生した場合には随時メンテナンスが入っています。コーディング担当者がメンテを忘れても、レビュー時にたいてい誰かが指摘してくれるので、メンテナンス漏れが起きることは少ないです。
さらに、ソースのコミット後はサーバ上で自動コンパイル、自動テストが走る上、リリース前にも品質チェック部隊による最終テストが実施され、確実な動作を担保しています。
これら、製品の品質を守るための強固な仕組みがあってこそ、コメントを書かないという文化が実現可能なのだと思います。
今はもう、プログラム内にコメントで注釈ということが、ナンセンスになっているのかもしれないですね…(というかもうなってて、俺がついていけてないだけなのかも)
コメントのあるなしについては昔から「注釈として必要だ」派と「分かりやすいコードを書くべきであり不要だ」派がしのぎを削っているわけですが、第三派閥として「仕様と注釈は外部委託してコードは実働のみにするべし」という感じでしょうか。それはそれで正しい気はする…
当時は必要とされていたものが、今となってはバッドノウハウみたいなことは特にコメント回りではよくありますが(例えばバージョン管理システムが無かった頃は変更点を全部コメントアウトして残していくことがありましたが差分が取れる今となっては邪魔なだけとか)、これもまたその類なのかもしれません。
そうだとしても、コメントを書くコツなどは役に立つとは思います。
なぜ「わかりやすさ」を求めるのか
まあ個人の感想になりますが正直他人のプログラムはわからん。
あんまり見たいとも思わんし直すのなんてもっといやや。自分のですら数ヶ月経ったらやばい予感しかしない。
…だがやるしかない。お互いそう思っていようとやるしかないんや。
そのときに変数名にちゃんとした名前が付いていたら。関数が簡潔に、関数名通りの動きをしてくれていたら。理解の足がかりになるコメントがあったら。(あんまり意味なくても「日本語」ってだけで心が落ち着くもんやで。割とマジで)
それだけで救われることがあるんじゃないかと思っています。
電子版はKindleなどの電子書籍ストアにはないですが、オライリーの公式からPDFで購入ができます。電書派の方はこちらを是非に。
あーあとそれから事の発端のこれ。
あー………ねぇ？
私からは以上です。
