生産性と保守性を高めるコーティング規約？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060228/231310/

中でも重要なのが，システム稼働後の変更・保守費用に直接影響する「保守性」である。

これには完全に同意する．

プログラミングの世界では，周知のとおり「リファクタリング」（プログラムの設計改善）という言葉もあるほどだ。

こういう中途半端な説明を入れると，かえってリファクタリングに対する誤解を与えそうだ．*1

システムの保守性を高めるためには，実装工程（開発工程）で保守性の高い「良いコード」を作成しなければならない。

これは「従うべきでないプログラミングのアドバイス10カ条*2」の「1) コードを書く前に設計せよ」を暗に前提にしている．このような「設計と実装の分離」が良い結果をもたらすことはほとんどない．

具体的に言えば
(1)可読性に優れており読みやすい，
(2)インタフェースが直感的である，
(3)変数などのネーミングが適切である，
(4)ロジックがシンプルである，
(5)コードの重複（コードクローン）が無い，
(6)APIが適切に使用されている，
といった条件を満たすソースコードである。

この辺りは必ずしも間違いではない．

とはいえ，2はかなり怪しい．まず「直感的」という単語はあまり専門的な用語ではない．また，たしかに良いインターフェースを作ることは設計上極めて重要なポイントだが，その設計指針は「直感的」というものとはほとんど関係ない．*3

3も重要ではあるが，ここでいう「適切」というのが曲者だ．少なくとも簡単にドキュメント化できるような単純な名前付けルールは知られていない．真に適切な名前を付けるのは実に難しく，専門家でも意見が分かれ，二転三転することも珍しくない．

こうした条件を満たす良いコードを作成するためには，なんらかの「品質基準」に従ってプログラミングし，それを同じ品質基準に従ってレビュー（インスペクション）する必要がある。

ここが間違い．
そのような「品質基準」が存在しないのがソフトウエアだ．
http://d.hatena.ne.jp/JavaBlack/20050605#p2

このソースコードの品質基準が「コーディング規約」だ。

ここまで来ると論外になる．

多くのSEやプロジェクト・マネジャーが実装工程で品質管理をきちんと行わない原因の1つは，「SEの基本的な仕事は設計書を作ることであり，ソースコードを作るのはプログラマの仕事」と考えているからだろう。

それ以上に，おそらくSEやプロマネと呼ばれている人の多くが，品質に口出しできるほどの技術力を持ち合わせていない．技術力がないからこそ「コーディング規約」という自分たちにでも理解できる殻に閉じこもらざるを得ないのだろう．

さらに，プログラムのソースコードが読めないために，どうしても「実装工程のことはプログラマに任せがちになる」というSEもいるのではないか。

そんなレベルで品質を議論するのは論外だ．ソースコードも読めずして，一体どうやって設計ができるというのだ？*4

実装工程でコーディング規約を導入すると，たとえ開発言語に不慣れなプログラマがいたとしても，品質が均質化したソースコードを作成できるようになる（図2[拡大表示]）。また，コーディング規約がソースコードの品質基準となるので，ソースコードの保守性向上にも直結する。

これはウソだね．
満たされるのは「均質化」部分だけ．ただし最低レベルに統一されるのだが．

最終的にシステムの品質を左右するのはソースコードである。となれば，設計書の品質管理だけでは不十分なことは明らかだろう。

ここまでは全くその通りだ．しかし

やはり，しっかりしたコーディング規約を策定してプログラマにそれを遵守させ，SEや品質管理者がコーディング規約に沿ったインスペクションを実施する--という実装工程での品質管理をきちんと行うべきである。

なぜこうなるんだろう．．．．この部分の前提と結論には何の関係もない．

ひょっとして品質の良いコードと悪いコードの違いを，まったく理解していないのだろうか．

米サン・マイクロシステムズが作成した「Code Conventions for the Java Programming Language」などの既存のコーディング規約は，フォーマットやネーミング，コメントに関する規約が中心だった。主にソースコードの“見た目”を意識した内容となっているのである。これでは，保守性の観点から見て良いコードを書くには不十分な内容だ。

その通り．それは「見た目についての基準を示しただけのもの」だから当然のことだ．

保守性云々の話までするのなら普通はこっちでは？

The Elements of Java- Style (SIGS Reference Library)

参考：http://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode.html
ただし，これも"double checked locking idiom"など，一部に間違いが含まれている．*5

あとはやはりGoF本とEffective Javaだな．ただしいずれもいわゆるコーディング規約の本ではない．そして，最低でもこのレベルのものを使いこなせなければ，高い保守性は実現できない．しかしこれらはコーディング規約ではないし，またJavaに不慣れな開発者が理解できるような代物でもない．本当に保守性も考慮し，ライフタイム全般も含めたトータルのコストを最小化したければ，質の低い開発者の出る幕はほとんどない．

あとは政治的，経営的な問題だな．どれほど技術があろうとも，経営的な失敗があるとどんな努力も無意味になる．
http://d.hatena.ne.jp/JavaBlack/20060106#p1

*1:リファクタリングは設計改善かもしれないが，設計改善＝リファクタリングというわけではない．

*2:http://labs.cybozu.co.jp/blog/akky/archives/2006/02/10.html

*3:ひょっとして以下のページの「アカウンタびる」のことを指して「直感的」と言っているのだろうか．だとすると１００％間違いだ．
http://www.atmarkit.co.jp/fdotnet/nagilemind/nagilemind01/nagilemind01_01.html

*4:たとえばマルチスレッド．マルチスレッドをサポートする言語としない言語では，それを使う設計がガラリと変わる．マルチスレッドの同期プリミティブも言語によって異なる．さらにJavaになるとHotSpotVMのような動的最適化が含まれるようになり，JMMのことも知らないと満足な設計ができなくなる．http://gee.cs.oswego.edu/dl/jmm/cookbook.html

*5:これはおそらく"double checked locking idiom"の問題が出版当時に知られていなかったことによるもの．