最近のお仕事は保守開発をメインにやっていまして、そのときに考えたことを残しておきます。
短くまとめると「当時の設計思想を崩さない方がバグる可能性を減らせるし、崩すなら影響範囲をよく調べて考えて本当にやっていいか考えてからにしよう」という話です。
世の中にはすでにたくさんの製品があるので、新規開発よりも保守開発の方が多くあるのかもしれませんね。
設計思想とは
この言葉自体に厳密な定義はたぶんないと思うけれど、ここではシステム開発である機能を作ったときの背景、設計の意図、プログラムの書き方の理由などのことを指して書いている。
まあこれ自体はそんな厳密な用語ではない（と思う）ので、要は「これ作ったときは何をどうしたかったのか（詳細不明の場合は想像する）」ということ。
国語の問題で言うところの「作者の気持ちを考える」。（当然作者ではないので正確にはわからないんだけど）推し量ること。
どうしてこの書き方をしているのかを考える
10年以上前のシステムともなると、今見ると「どうしてこの書き方になってるんだろう」「どうしてこの設計になっているんだろう」と思うことは山ほどある。
たとえば毎回無駄にデータベースにアクセスして登録しているようなものがあったとして、今見ればそれは非常に無駄なアクセスに見えるかもしれない。
でもそれはフォームで送られてきたデータを確定させる前に一旦保存して、その後確実にそのデータで処理をしたかったから一旦データベースに登録する処理を挟んでいるのかもしれない。
また、関数で一発判定できるのにforeachでループして突き合わせて判断しているのは何か理由があるのかもしれない。
もちろん、当時作った人が考えなしにやっただけの可能性もある。納期がなかったから機能を優先させたとかね（あるある）。
それでも当時どうして設計したのかがわかれば、その考えを崩しても大丈夫なのか、他の機能にも影響が出るからダメなのか、がちょっと見える。わからなくてもプログラムから想像できれば、崩したら炎上するかも、と危険察知ができるかもしれない…
どんな小さなプロジェクトでも危機回避はしておきたいところ。
それに、今新規開発していたとしても5年も経てば古いシステムになってしまう。5年前のコードを見ると「どうしてこの書き方になっているんだろう？」と疑問に思うことは多々あるよね。あるあるすぎる。
既存システムに新しい機能を追加するときでも同じ
そんな既存システムに新しい機能を追加するとき、可能なら他の機能のプログラムと同じような書き方をした方が良い。あちらこちらを見るときに「ここだけ書き方が違って読みにくい」みたいなことを防げるかもしれない。100%同じにはできなくても（癖は出るものだし）なるべく同じ、ならできるはず。
「俺の書き方」がやりたければ、それは個人開発か完全なまっさら新規開発でやればいいこと、きっと。
前にそのプログラムを書いた人の気持ちを考えよう
こう書くと国語の問題か何か？と思ってしまうけれど、案外そういうところはある。
国語のテストと違うのは正解がないこと。なぜなら9割方当時の開発者はすぐ聞ける場所にはいないから。推し図る、しかない。
プログラムも文章よりはわかりにくいけれど、書いた人の癖はどうしても出るし、一種の言葉だと思う。
この書き方をするのはどうしてだろう、こちらの書き方にしなかったのはどうしてだろう。
- 納期が迫っていたからとりあえず動くようにした
- 当時の開発者のスキルが足りなかった
- 実はこう書かないとあるデータが来たときにバグる
- 他の機能と合わせた書き方をしている
- 確実に処理をしたいから回りくどい書き方をしている
- 実はバグってるけど気付かれずにここまで生きていただけ
など本当にいろいろなパターンが考えられる。
ドキュメントやコメントに残してあったら万々歳だけど、実際の現場ではそんなしっかりしたものはあったら御の字、ないのがほとんど（私はしつこいかなと思うくらいコメントに残す派だ、時間があれば）。
保守開発であれば前に書いた人がいるわけで、その人の気持ちを考えてソースを読み解き、問題の箇所や実装したい内容が可能なのか考えた方が良い。国語の能力もその成績も本当に馬鹿にできないね。
単に機能を実装するだけではバグが混入して炎上してしまうかもしれないから、防ぐためには「プログラムを書いた人の気持ちを考える」ことが結構重要なことだと思う。
好き好んで炎上現場に行きたくないし、いろいろな人が大変な目に遭うのは見たくもないからね。
