 |
||||||||||||||||||||
|
||||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| コーディング規約の問題点 | ||||||||||||||||||||
|
第4回で「スペックパターン開発プロセスでは、まず、実作業者の能力を信じます」と述べましたが、これは「実作業者のコードを読み、理解する能力が一定レベル以上であることを軸に開発プロセスを考えている」ということです。 ですので、例えば「○○についてはしてはいけない」などということを羅列した、まるで校則のようなコーディング規約を提示することは重視しません。 「してはいけないことをすべてしていないコード」はどういうものなのかを考えるだけで大変です。しかも、それを常に考えると同時に「実際に業務に耐える」コードを実現するというのは極めて大変な作業です。 さらに、プログラマがそれぞれ最適なコードを各個に考えながらコーディングを行うことはとても効率の悪いことですし、細部に渡って統制を取ることは難しいものです。しかもバグを減少させたり、ロジック面でコードの質を高めることには直接繋がりません。 コーディング規約を説明するためだけの目的で作られたサンプルソースを見せられたところで、実際に稼働するプログラムのコーディングを行うのにどれほど役に立つのかということは疑問です。 実際にコーディング規約が要因となってコーディング作業の負荷が高くなることから、納期に遅れたり、成果物に多くのバグ発生するようなことも起こっているようです。ヘビーなコーディングを経験した読者には、「同時に考慮すべきことが、ある一定のラインを超えると急激に脳の生産性が落ちて、同一人物の成果物でも、大きく品質が下がる場合がある」ということは実感として理解できると思います。コードの見やすさや保守性を追求するのは大切ですが、結局プログラマに過剰な負担を強いてしまって、システムの保守どころか稼働ができない方向へプロジェクトを向けてしまうのでは本末転倒です。 もちろん、ルールは一切なしでよいという意味ではありません。コードの見やすさや保守性は確かに重要です。しかし何よりも重要なのは、必要とされる機能を最初から可能な限り少ないバグで作り上げるということです。コードがコーディング規約に合致していたところで、役に立たない不要なコードを入れてしまうことはあり得ますし、フレームワークや共通クラスの使い方の誤解などによって、いくらでもバグが作り込まれる可能性やロジックの表現がバラつく可能性は残ります。 |
||||||||||||||||||||
| 現場の実情を考慮したスペックパターン開発プロセス | ||||||||||||||||||||
|
「スペックパターン開発プロセス」ではこのような実情への対処を考え、極めて早期に代表的な画面（あるいは最も多くのコントロールの種類を含む画面など）についてのリリースレベルのコードを慎重に作成します。そして顧客の現場による徹底的なテストや詳細外部仕様書記述との照合を行ってもらい、顧客承認済みとします。このロジック的にも高品質かつバグがない納品レベルのコード（実際に納品します）を「モデルソース」と呼んでいます。 ここでも「徹底的な顧客業務理解（第6回参照）」は活かされることになり、「モデルソース」は仕様策定者とインプリメント・リーダーが上流工程を丁寧に行った成果といえるでしょう。この「モデルソース」をプログラマに提示して、同じく承認済みの詳細外部仕様書と照らし合わせながら詳細な説明を行います。 同じ仕様書表現については対応する「モデルソース」を必要に応じてコピー＆ペーストして、インデントを合わせるというような要領で使ってもらいます。詳細な外部仕様書の（個々の）記述と対応する「モデルソース」の（対応部分の）セットが「スペックパターン」です。 そのまま使える「モデルソース」と「スペックパターン」を活かす運用（スペックパターン開発プロセス）によって、次のようなことが実現できます。
表1：「モデルソース」と「スペックパターン」を活かす運用で実現できること |
||||||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
