本日のお題：得意だと早いけど、それだけ
プログラムは、当たり前を積み重ねて
作るものです。量ではなく質が求められます。
極めて論理的な作り方を求められます。
プログラムで問題が出ることを
バグと言いますが
特定の場所に集中していることが多いです。
source code review。
出来上がったソースを
作成者以外がチェックする事。
誰でも得意な事と不得意な事が
あると思います。
何度も繰り返していると速くなる作業。
手順を覚えると速くなる作業。
いろいろあります。
けれども
急ぎで片づけたい仕事が
必ずしも自分の得意な事とは
限りませんね。
source code reviewが、
システムの健全性を確認する手段として
最善の一手とは、言い切れませんが
実行結果が良好に推移すればと思います。
もちろん静的なチェックなので
動作上にしか起きえない事象は
論理的に追うことでしか
確認できません。
では、作成者以外とは誰か。
依頼者ではありません。
※ 依頼者は完ぺきを求めて修正を要求。
出来たソースコードを
読み解けるレベルの技術者が
source code reviewを行います。
お飾りの管理者は
適任ではありません。
分析が得意な人間には
source code reviewは
おいしい仕事。
しかし、
印刷や数値解析といった特定分野が
得意な人にとっては、全般を網羅する
source code reviewは難敵でしょう。
得意分野と優先順位の差を
どう埋めて読み解くか。
読み解けると一口に言いますが
新規開発されたプログラムの
難易度が、低いとは限りません。
その際に重要なのは説明文書です。
特に、改良ないし改修された場合は
● 「差分説明書」が鍵を握ります。
どのような意図で
どこをどのように
変えたかを詳細に
記述した文書です。
現在の証券コードは数字４桁ですが、
まもなくアルファベットを含んだ４桁に
変更されます。
もし、証券コードを数値で扱う形の
プログラムが存在し改定が必要になるなら
文字として扱う必要があり、
何処がその対象であるかを記述する
みたいな文書です。
差分説明書があれば、
ソースコードを辿るのは
楽です。
説明書がない場合は、
変更されていないと言える訳で、
変更部分に集中できます。
逆に言えば
説明書が不要と考えた人間が居る
証明になります。