たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

書きやすさ重視か、読みやすさ重視か

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

関連記事