前提

断続的に更新が行われているソフトウェアのエンジニア。Webエンジニア。開発サイドから見て、保守しづらいソフトウェアを管理している人。開発サイドから見て、再利用できないようなプログラムがコーディングされているエンジニア。中堅どころのエンジニアなど。

保守性について考えてみる

そもそも、保守しやすいプログラムとはどういうものか。
不具合発生時に、対応時間が短く、かつ影響が少ないのが一番だ。そのためには、「バグを発生させるための手順」を早期に確立して、再現性を100%までもっていくのが大事なこと（※1）だと思う。まぁ、ソフトウェアとしては操作ログを取っておくのが一番手っ取り早いだろう。経験的に、ヒアリングの結果はあまりあてにならないことが多かった。

※1 クライアントやプロパーにせかされて、場当たり的な対応を強要されるケースもあると思うが、慎重に判断したいところ。マネージャやリーダーはここで頑張れるか頑張れないかで、「上から評価される管理者、下から慕われる管理者」の振り分けが行われると考えてよいと思う。

ある程度の再現性が確保できたら、次は仕様を知る必要がある。ここはどうしてもドキュメントだよりになる。人の記憶などあてにならないからだ。さらに言うと、どのドキュメントが「最新であること」が重要になる。昔ながらのエクセル、ワードで書かれたもの。ソフトで自動出力されるようなものでもいいと思う。コード以外の手掛かりがない場合は泣くしかない。「アジャイルなんだからあるわけがない」という現場もあると思うが、アジャイルだからドキュメントが不要、という考え方はどうだろう？アジャイルが洗練されていく過程でドキュメント作成がなくなったのであれば、保守性が担保されているはずだからだ。

仕様の把握ができれば、あとは影響度を把握できればコーディングにたどり着ける。ここまでの過程で、どのくらいの時間がかかる（※2）のか、それが保守性の良し悪しとなる。

※2 時間を判断するのはユーザーであって、クライアントではない。クライアントは妥協点の線引きをするだけ。一日で対応しても遅いと思われることもあるだろうし、十日かかって早いと思われることもあると思う。

再利用性について考えてみる

一昔前であれば設計次第、と言いたいところだけど、個人的にはプログラマの裁量の範囲かなと思う。メソッドのレベルまで掘り下げた設計書を見かける機会がめっきり減ったからだ。年々、統合開発環境やアーキテクチャが洗練されていき、より短いコードで多くの機能を実装できるようになった。プログラム教育も充実し、当たり前のようにオブジェクト指向を扱う若者も年々量産されている。そうなると、大筋だけ設計しておけば、ある程度のプログラムが組むことができる。細かいことを支持しなくても、最初から再利用性の高いのだ。

逆に、オブジェクト指向についていけなかったプログラマのほうが、再利用性の低いプログラムを組んでしまうことがままある。一つのメソッドの中で、「何でもかんでも」実装してしまう書き方だ。SetFormとかSetDisplay、SetViewみたいな関数を作って、上から順にすべてのコントロールのValueをセットしていくような作り。再利用性は0。使い物にならないうえに、内部的には条件分岐だらけになっている。テストの労力も半端ない（※3）。

※3 仕様変更のたびに、すべての分岐のテストをしなければならないからだ。

こういった後悔のもとに、新しいアーキテクチャが提案されている。自分の書くコードが、果たして再利用性が高くなっているだろうか？と最低限見直して、リファクタリングは行うべきだろう。個人的には、再利用性が高くなってさえいれば、メソッドのコードが多少稚拙になっていたとしても良いと思っている。再利用するために、後々メソッドを分割しなければならない、なんて事態に陥るよりよっぽどましだからだ。この辺は、若者よりも中堅どころのほうが不安定なので、意識したいところだ。

まとめ

保守性については、知識を蓄積しているベテランのほうが有利だが、再利用性についてはむしろ、新人のほうが洗練されていると思う。たまに「困ったちゃん」がいて、せっかくオブジェクトを組んでいる若手のコードを、自分色に染めようとする中堅どころのエンジニアに遭遇する。厄介なことに、この困ったちゃん、意味不明だがやたらと声がでかかったり（※4）する。そしてなぜなのか、やたらとプライドが高い傾向にある。

※4 音量ではない。

確かに経験は大事だと思うし、自分の積み上げてきた実績もあるんだと思う。でも、それ以上の勢いでコンピュータの世界は変遷を遂げていて、進化し続けている。時代についていっているつもりでも、気付かないうちに取り残されている可能性は十分にあり得る。

若者から教えられることはまだまだ尽きない。