レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

そのシステムの常識をサンプルコードに語らせろ

システムの仕様について、常識として通用してしまっている部分があると
新規参入者は非常に困るということを実感した。
こういうときに、メンテナンスされているかどうかわからない設計書はあまり役にも立たないし、
その人が常識だと思っていることまでは設計書に書いてくれないから
実装のサンプルコードを残しておいてくれたら良いのにと思う。


以下に、少し脚色して例示する。*1


あるシステムでは、”当年”といえば”日付マスタ”の”当年度”の値だった。
これはよくある仕様だが、初心者だと知らずに

new Date();

をする人もいる。


こういう共通処理は、どうせ共通処理クラスがある。
サンプルとして、以下のように残しておいてくれたら読んで分かる。

int year = jp.co.exmple.DateUtil().getCurrentYear();

設計書はシグネチャが変わったときとか、メンテが面倒だけど
コードだとコンパイルエラーになるのできっと直してくれる。
まぁこの例は、まだカワイイもんだ。
大抵の場合、テストで判明するし少なくともリリースするまでに気づくことができる。


そのシステム独特の仕様が常識化している場合がやっかいだ。
例えば、このシステムでは「前年度の部門マスタ」という言葉が頻繁に使われていた
参画した当初、僕は「M_DEPT(部門マスタ)」を以下のように検索するのかなと思っていた。

SELECT * FROM M_DEPT WHERE YEARS = 2009 - 1 

M_DEPTに「APPLY_DATE(適用日)」という項目があったので、それだと思っていたがどうも違うらしい。
(適用日は、マスタの有効期間を設定するものだった。)


この点に関して、他の設計者と話をしていても話が通じないのでおかしいなと思っていた。
そうしていると、ある画面の「部門の年度選択」で、年度指定がラジオボタンになっていたのを見つけた。

◎前年
◎当年
◎翌年

意味が分からなかった。「2年前はどうすんだ?」と。
実装を覗いてみて始めてわかった「前年度部門」とは
「M_DEPT_LASTYEAR(前年度部門マスタ)」という別テーブルのことを指していたのだった。


推測するに、これはシステムを増改築する中で生まれた仕様だろう。
適用日で、マスタの世代管理をしたのは良いが、
過去の実績帳票などを参照するには、過去時点のマスタデータが必要だ気づいたんだろう。
過去年度の全てをデータ管理すればよいのだろうが、
データ領域の問題と、頻繁にJoinで使うマスタなので前年だけにしたようだ。


この設計のウマイ・マズイはさておき、これを膨大な既存設計書から読み取るのは、馬鹿らしいほど困難だ。
たしかに他の機能の設計書には「前年度部門マスタを参照」という風に書いてあるが、
理解して読むのと知らずに読むのではえらい違いで、知らずに読んで読み取れるものではない。
「前年度事業部マスタを参照」という記述では、「WHERE YEARS = 2009-1」のやり方だったりしたから、
統一されているわけでもないし、読み取れなくて当然だろう。


人に聞いてもわからなかった。というより、僕の問題意識に上がっていなかったので、聞きようもなかった。
一方そのころ、先に参画している設計者達は、標準仕様書を読んでるからこの辺の常識は共有できてると思っている。
この問題は比較的早く発覚して解決できたが、他にも多々の認識違いがあった。


こういった問題を解決するために新規参画メンバーに
「標準仕様の設計書を一通り読ませる」
よりも
「標準仕様のチュートリアルを実装したサンプルコードを読ませる」
ほうが、はるかに正確に仕様を理解できると思う。


今回、標準仕様の設計書は沢山あったが、やけに特殊なシュチュエーションばかりの
標準設計書だったので、常識レベルのものが全く見つからず苦労した。
(特殊な状況の仕様をまとめておく気持ちは良くわかるが。)


とまぁ、他社の下請けで保守っぽいプロジェクトに入っているんだけど、毎日勉強になることばかりだ。
システムの初期開発で、やるべきこと、やってはいけないことの結果がここに詰まっているからだ。
こういうプロジェクトも良い。


保守がシステム開発の最前線だということを実感する毎日だ。

*1:具体的なので機密がらみを避けるため