レガシーコードとの格闘 その１
しばらく書いてないと忘れる。これいつも通りやわ。
熱出してるときに書くことではないのであるが、愚痴りたくなったので書く。
ちょっと大きいレガシーコードに対して品質向上をするにはどうするべきなのか？という問い。
設計書関連のドキュメントが整備されていない、ウォーターフォール型の開発現場で、しかも
テストコードはない環境で、です。
Javaで組まれてるけど、OOな記述がされていない。無秩序にコピペしたコードが散在してる。
記述自体が冗長で、やりたいことがコードを見ても理解し難いものが多い。
製造時、ソースレビューはしていない。仕様がわかっている人間が設計書を作成していない、
レビューもしていない。それはバグっても仕方ない。
まずは仕様の確定ってことで、設計書から何からドキュメントの整備から始まるんだろーな、
と思うけど、実際に品質を向上させるにはやはり、叩くしかないのかな…
最終的には「目で確認する」という作業は必要になるだろうけど、あまりバカ正直に「叩く」
という作業に没頭したくない。時間もコストもかかるし、再利用ができないし、人がやること
だから、ミスもでるんですよ。
そのミスを防ぐために、プログラマーでないSEが考えたのが、各作業に対してスクリーンショットを
必ず取る、取ったものをレビュアーが確認する、という作業。
この作業自体は品質向上や問題発生の防止に効果はあると思う。ただし…
時間も人もかかるんです。しかも、スクリーンショットを取ること自体が目的になってしまうんです。
※この作業をする、ということはそれだけ「レベルが低い」という証明でもあるのだが。
ここ数日、どうするのがよいかな、と考えたのだけれども、あまりに手をいれるべきものが
多すぎるため、何から始めてよいかがわからない状態。
今、やらなければならないと思ってるのは以下のようなこと。（あーレベルが低い…）
- 設計書、要件の整備。これがないと障害か元々ない機能なのか判別ができない。
- リファクタリング。この概念がうちにない。コードの重複をなくす。冗長なコードをシンプルに。
- テストの自動化。無理せずに徐々に導入する。リファクトするには必要だと。
- 仕様書に沿ってテスト仕様書作って叩く。
若造の単純な発想ですけど、狭い私の見識ではこれを地道に続けるしかないかな、と思う(泣)
ただ、一番の問題は、課長・部長レベルをどうやって説得してプロセス自体の改善を行うか、
ということなんですけどね。
