リーダブルなコードを保つためには、コードが読まれるような文化をつくらなければならないのではないか

アプリケーションに不具合が起こっても改修しやすい、仕様も確認しやすいコードであるためには、可読性の高い（＝リーダブルな）コードである必要があります。プロダクトを継続して改善していくためには、コードがリーダブルであるということは必要条件です。

リーダブルなコードである、というのは個人の資質の問題なのか？

ところで、「僕らのコード、リーダブルじゃないよね」と言ったときに、

テクニックの浅いプログラマがいるからリーダブルにならないんだよねー。
リーダブルコードを読んでない奴がいるせいだ！
テクニック以前に意識が低いよね。そういう文化だし、仕方ないよね。

と、自身のチームメンバーに責任を持って行きがちな気がするのですが、本当にそうでしょうか？

確かにリーダブルなコードを書くためには、ある一定の技術水準、テクニックは必要です。でも、それが全てなんでしょうかね。

読まれないコードの可読性が高くたってしょうがない

そもそも可読性が高いというのは、読まれることが前提の言葉です。

読まれないコードの可読性を高くするモチベーションなんて、論理的に考えて、ないですよね。

コードを読まれるから、可読性を高くするモチベーションが生まれるのです。

リーダブルなコードを保つためには、コードが読まれるような文化づくりが必要

それゆえに僕が最近思うことは、リーダブルなコードを保つためには、コードが読まれるような文化づくりが必要だということです。

コードを読む機会として一番よくあるのはコードレビューでしょう。

「ここ、意図が伝わりやすくていいね！」「ここはこうした方が、もっと仕様の意図が伝わりやすくなると思うよ」

こういったコミュニケーションが、よりコードをリーダブルにしていきます。

「もっと意図が伝わりやすくなる書き方はないかな？」

こういった問いかけが、メンバーの技術力を底上げするものになります。

リーダブルであるというのは、一般的な指標に適合させるというよりは、まずはチームメンバーにとって読みやすいものであることが大事なのではないかと思います。読むのはあくまでチームメンバーな訳ですし、しっかりメンテされたコードというのは、保守するメンバーにとっても自信につながりますよね。

そしてこういった下地があってこそ、こんなスライドで紹介されているようなチームが作れるのではないかなーと思います。

書いたものは読まれる。読まれるから、伝わりやすくする。文章を書く上では当たり前のことですが、ことコードになると、そうではなくなるようです。もっとコードが読まれる文化づくりをすることで、不具合改修のコストが軽減される、新しい機能の開発への負担が軽減される、それゆえにチームメンバーがいきいきと働けるようになるといった効果が生まれるのであれば、こんな素晴らしいことはないですよね。