レガシーなアプリのコードをメンテナンスしていると、「なぜこのコードが必要になるのか？」「この部分は不要なのではないか？」などという疑問にぶつかることが多くある。
昔の話だが、思い込みで改変したところ、後で大事故を起こしてしまったこともある。
原因は、タイトルにある通り、「仕様」をきちんと確認もせず、自分のエゴを押し通してしまったことにある。
当たり前のこと過ぎて、こうして文章化するのも恥ずかしいが、堂々と書き出してみたいと思う。
ズバリ、「すべては仕様に通じている」「仕事を仕様に合わせる」ということだ。
基幹系システムなどの SOR（System Of Records）の場合、仕様を元に設計され、設計よりコーディングを行い、テストを経て、アプリケーションとしてリリースされる。
リリースされたアプリは、ユーザーに利用されて、必要なデータがＲＤＭＳに書き込まれていく。
このフローは、ウォーターフォール開発でも、アジャイル開発でもリリースのタイミングと頻度こそ違うが、まったく同じだと考える。
つまり、スタート地点は「仕様」なのだ（大事なので、連呼）。
既存のアプリケーションを改変する際には、とにかく最初に仕様を確認することが大切である。
しかし、その仕様書が無いというケースがある（実際にそういうケースは稀ではない）。
その場合、どう対処したら良いのだろうか？
簡易的でもいいので、仕様をまず整理することから始めたい。
当然、修正する箇所が限定的であっても、その修正で思わぬ落とし穴に落ちてしまうことも考えられる（前述の通り、私も経験した）。
まずアプリの役割を知り、全体像を把握する。コードに手を加えるのはその後だ。
もちろん、過去のデータを参照することもあるが、あくまでも参考に過ぎない。
自分が改変する箇所が仕様全体に影響が無いように慎重に改変する。
作業後は、この箇所のテスト＋退行テストを実施する。これでその手術は成功間違い無しだ。
最後に、システム全体の仕様や思想をきちんと把握しておくことも大事である。
目の前の仕事を通じて、成功体験を重ねていければ、自然とその思想を感じることができるのだが、自分が開発中に持った疑問点や仮説については、レビュアーに質問してクリアにしておくことが近道になるだろう。
いち早くその思想を理解できると、明日からの開発が劇的に楽になるはずだ。
