« 告知「第1回 DOA+関西分科会」 | トップページ | 「アジャイルなスクラッチ開発」ではダメ »

2011.09.24

コードを仕様書にするために

 「実行可能な仕様書」の技術は、古くから開発者を悩ませてきた「仕様書とコードとの不整合問題」を解決する。エクセル方眼紙等で「そのまま実行できない仕様書」を書いて、それを見ながらプログラミングし、仕様変更の際には両方に手を入れる――これまで当然と思われていたそんなスタイルがレガシーになる。

 ただし一口で「実行可能な仕様書」といっても、方向性の違いから大きく2つのタイプに分かれる。様式化された仕様書データを専用エンジンに解釈させて機能を起動するタイプ、それに、プログラマの書いたコード(おもに動的言語)を仕様書とみなすタイプの2種類だ。

 両者の違いは、不整合の元凶である「仕様書とコードとの並立問題」に対して、前者はコードを書かないことで、後者は仕様書を書かないことで対処しようとする点である。便宜上、それぞれを「動的制御方式(注)」、「スクリプティング方式」と呼んでおこう。

 いずれかの方式だけでは行き詰まる。なぜなら業務システムというものは、想像以上に複雑膨大なソフトウエアだからだ。すなわち、すべての機能の仕様を専用エンジンで解釈させるには処理内容が多彩すぎるし、すべての仕様を端正なコードで表すにはコードの量が多すぎる。

 ゆえに、両者を併用するやり方が有効だ。拙作の開発基盤「XEAD Driver」では、全体の6~8割の定型的な機能の仕様については「動的制御方式」で扱われる。いっぽう、特殊な機能の仕様や、テーブルの拡張定義として格納されるビジネスロジックの仕様については、Rhino/JavaScriptを用いた「スクリプティング方式」で扱われる。

 前者の方式については何度も書いたので、ここでは「スクリプティング方式」の論点を取り上げたい。その最大の課題は、コードの可読性(読みやすさ)をいかに担保するかだ。結論を先に言えば、腕のいいプログラマを起用することが肝心である。なぜなら、コードの可読性が書き手によってまるで違うからだ。

 腕のいいプログラマを起用しながらも、コーディングの機会を削減するための工夫を怠ってはいけない。上述したように、定型的な機能についてはコードを書かずにすませられるようなしくみの併用が求められる。そうでなかったら、端正にまとめるべきコードの量がハンパでなくなってしまう。

 コーディングの機会を削減するための工夫ばかりでなく、読みやすくコーディングできるような工夫も求められる。たとえばXEAD Driverの次のリリースでは、SQLを組み立てるためのユーティリティクラス(TableOperator)が、Rhino/JavaScript上で利用できるようになる。導入前と導入後でのSQLの宣言ステップを並べると、以下のように読みやすさの違いは明らかだ。

Zu110924
 ご存知のようにSQLのinsert文では、フィールドIDの一覧とフィールド値の一覧とが構文上泣き別れになっている。またinsert文に限らず、文字系フィールドについて値にリテラル(\')を補う必要がある。スクリプト上ではサブクエリやJOINを使った複雑なSQLはまず不要なのだが、それでも操作文を組み立てるためのステップが読みにくくなりがちだ。

 上掲のユーティリティクラスは、データ型を考慮しつつSQLを整形して実行してくれる。この例ではわからないが、コネクションの取得、結果セットやステートメントのクローズ処理も面倒見てくれる。結果的にテーブル操作の記述部分がすっきりして、より「仕様書風」になる。

 このような基盤上の工夫はやれるだけやったほうがいい。何のためか。「削減されたコーディングの機会」において「腕のいいプログラマ」に気分よく腕をふるってもらうためだ。


注.仕様書の内容からコードを自動生成させるタイプも含まれるが、そのなかでも、生成されたコードに対するプログラマの介入を許す方式は「実行可能な仕様書」ではない。あくまでも「仕様書」と「起動される機能のふるまい」とが1:1対応しなければならない。

|

« 告知「第1回 DOA+関西分科会」 | トップページ | 「アジャイルなスクラッチ開発」ではダメ »

コメント

コードを仕様書にするためには、まずはコードを日本語で書けることが前提ですね。

投稿: hongcz | 2012.05.08 15:51

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: コードを仕様書にするために:

« 告知「第1回 DOA+関西分科会」 | トップページ | 「アジャイルなスクラッチ開発」ではダメ »