ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール12大きなチームには強い規則が必要

　本書の一番基本的な考え方は、プログラミングとは複雑なものであり、個人として、またチームとしての生産性は、そういう複雑性の制約を受けるってことだ。物事を複雑にすればするほど、あるいは物事が複雑になるに任せておけばおくほど、成功は遠のくだろう。物事を単純に留めておけばおくほど、大きく成功するだろう。だから、物事を単純な状態に保とう！

　このアドバイスは、取り掛かってるプロジェクトがどんな種類だろうが当てはまる。でも、当てはまる度合いはプロジェクトによって異なる。

　複雑性が余分にあったとしても問題にならないほど、小規模で単純なプロジェクトもある。とある午後に100行のコードを1人で書き、用が済んだら捨てるつもりなら、とにかくどんな風にでも好きに書ける。そうしたからといって、人に何か言われることもない。

　チームに入ると、たとえ2人のチームであっても、そういうわけにはいかなくなってくる。「自分のコード」と「他人のコード」の間に線を引いて、線で分けられた自分側のコードの書き方を各人が決めるようにしようとするかもしれない……でもあまりうまくいかないだろう。自分側の部分が、別の部分から非常にきれいに分かれていて、プロジェクトの存続期間中ずっとそのままってわけでもない限り、その境界の両側を短い間に定期的に行き来することになるだろう。半分に分かれた各部分同士のインターフェイスを定義する場合すら問題になる。例えば、境界線の両側にインターフェイスが半分ずつある場合、インターフェイスの名前をどうするかは誰が決めるのか？

　そういう「自分側と他人側」パターンを、もっと規模が大きいチーム向けに拡張する良い方法は、存在しない。にもかかわらず、やろうとする者が後を絶たない。プログラマーによっては、「自分の」コードに関するありとあらゆる決定を自分でやることに強い魅力を感じる者もいる。プログラミングとは創造的な行為であり、制約があれば創造性が失われていってしまうと主張したりする風潮も見られる。また、あるプロジェクトに属する別々の部分は、必要とするものも別々なので、別々に扱われるべきと主張しがちだ。あるいは、自分のプログラミングスタイルの一番細かい部分に執着してしまいやすい。でも、中括弧の場所 ...