先日現場のメンバーと、コーディングスタイルについて少々議論したのですが、その結果、プログラミング言語選択やコーディングスタイルには、
- 目下の書きやすさを重視した姿勢
と、
- 後に第三者が読むことを想定した、読みやすさを重視した姿勢
の二つがある、という結論に達しました。
「書きやすさ重視派」は、、、
・動的型付け言語を選び、
・記号メソッドや、記号を用いたシンタックス・シュガーを歓迎し、
・短めの識別子を好み、
・識別子を決定する時、確定した目下の要件のスコープを考慮し、
・いわゆる「Webサービス系」に多い。
・もしくは、インディペンデントなパワー・プログラマーに多い。
「読みやすさ重視派」は、、、
・静的型付け言語を選び、
・記号メソッドは避け、
・長めの識別子を好み、
・識別子を決定する時、将来の仕様変更の方向性や隣接要件との関係性を考慮し、
・いわゆる「エンタープライズ系」に多い。
・もしくは、SIer系シニアー・エンジニアに多い。
このように特徴を対比させられると考えました。ここに挙げた特徴は典型例としてなので、常に全てそうだ、という訳ではありません。ただ、そういう傾向はあるだろう、という理解です。
・
「デリバリー重視（＝短期に次々と更新リリースすること）」とならざるを得ない、Webサービス系のスタートアップ期の開発は、自ずと「書きやすさ重視」となるのでしょう。エンタープライズの開発は、当初から「将来第三者が保守に入った時困らないこと」が（最）重要視される文化です。
ちなみに、Javaというプログラミング言語は、「将来第三者が保守に入った時困らないこと」に対して障害となりそうな言語機能をC++から削除するかたちで設計された、ものと理解しています。（※削除機能の最右翼は「暗黙キャスト」と「演算子オーバーロード」でしょう。ちなみに、これらの組み合わせで（だいぶ無理やりですが）C++でもちょっとしたDSLライクな拡張を実現することもできました。）Javaは、便利だとしても読みやすさを阻害する可能性のある機能を廃した、明らかに「読みやすさ重視」の言語です。
*第三者*が保守するケースを明示的に意識する姿勢は、エンタープライズの強い特徴と思います。“Web系”でも、保守や機能拡張は当然やるのですが、*第三者*がそれを行う、という想定はあまりありません。つまり、保守を行う人間は、対象システムの当初設計（およびその経緯を）をよく知っているという前提です。このあたりの姿勢の違いは、こちらの記事に記したような「個人の当事者意識に賭けるアジャイル」か「組織的に対応しようとするウォーターフォール」か、という対比軸に通じるものがありそうです。
・
プログラミング言語やコーディングスタイルの“嗜好”も、引いて見ると単なる神学論争ではない、それとしての背景理由が見出されるものだ、という訳で、“主義”に陥らずに、対象システムのフェーズや規模やそもそもの特性によって適切に選んでいこう、という話でした。
◆以上
