82-他者への思いやりを意識したコーディング

「プログラマが知るべき97のこと」の82個目のエピソードは、コーディングとコミュニケーションに関する話です。他のエピソードでも何度か登場していますが、現在のプログラミングは孤独な作業ではありません。ほとんどの開発はチームで行い、自分の書いたコードは否応にも他人の目に晒されれる事になります。ソフトウェアを保守していくのであれば、拡張や不具合の対応の時にも他人の書いたコードを読みます。ですから、コードの可読性が高いことは重要な事です。
このエピソード以外のエピソードでは、ソースコードという成果物に関して、客観的に見て、可読性が高いかという点に着目して書かれています。解りやすいクラス名/変数名・メソッドの行数・for/ifのネスト数など、コーディング標準を用意して対応することが多いと思います。また、ほとんどの部分を静的解析ツールやコードレビューでチェックし、ソースコードを健康な状態に保つべきという主張です。
客観的にソースコードの可読性が高いことはとても重要です。しかし、このエピソードではソースコードを書く時の意識面に関して書かれています。

孤立していても、自分の世界に没入していても、質の良いコードを書くことは確かにできます。

言い換えれば、チームの他のメンバーを意識しないとしても、客観的に可読性の高いコードは書けるという事です。ほとんどの場合、それで十分な事もあります。しかし、このエピソードでは、その仕事が本当に開発チームのためになっているかについて疑問を持つべきと主張されています。
Ubuntu*1の理念は「人間は、他の人間がいるお陰で、人間になっている」というものです。これをソフトウェア開発やプログラミングにあてはめると、「プログラマは、他のプログラマがいるお陰で、プログラマになっている」「コードは、他のコードがいるお陰で、コードになっている」と言えます。あるプログラマの思想や行動は他のプログラマに影響を与え、コードも同じように思想やスタイルが影響しあっていくという考え方です。
これはソフトウェア開発を行っているとなんとなく感じていた事でした。同じレベルのプログラマが別のプロジェクトで作業を行っているとした場合でも、明らかに成果物であるソースコードの質やソフトウェアの質に差が生まれます。同じレベルのプログラマであれば、品質は大きく変わらないはずなのに、です。特にコードベースを引き継いだ時は顕著です。元があまりよくない設計でコードも汚い場合、自然と「いいや、どうせきれいなコードじゃないし…」と考えてしまいます。コピペだらけのコードではコピペに心が痛まないでしょう。逆に元がきれいに書かれているコードの中に、コピペコードやレベルの低いコードを追加していくのは、心が痛みます。読みやすく解りやすいコードが書かれていれば、自然と自分も読みやすく解りやすいコードを心がけるようなるのです。
結局の所、コードベースを健康な状態に保ち可読性を高めていけば、チームの他のメンバーにも影響を与え、全体の質が向上するわけですから、一人でプログラミングをしても変わらないと思えるかもしれません。ですが、質の高いコードを書く時の意識としてその意識が他のプログラマに影響を与えること、結果としてそれが自分に返ってくると意識することで、チームがより良い方向へと成長していくことができます。チームが成長する事は自分にとってもより有益な事である事は言うまでもないでしょう。

プログラマが知るべき97のこと

*1:Linuxのディストリビューション