レガシーコードを目の前にして
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち（電子書籍のみ）www.lambdanote.com
WebAssemblyの話ばかり書いてきましたが、現実の業務では、入社以来、ずっとレガシーコードの問題と向き合っているように感じています。個人的には、対処しないといけない範囲では、これまでソフトウェアエンジニアをやってきた経験の中では、一番大きなものですね。いろんな意味で、典型的なケースかと思います。ビジネスはうまくいっているので、余計にメスが入りづらい。入社直後が一番きつかったですが、ちょっと慣れてきている自分もいて、怖いなとも思います。
というわけで、気休めというか、自分なりに対処の方法を考えたいということで上記の書籍を読み直したりしています。いざ「ほんもの」を目の前にすると、ひとつひとつの文章の重みが違って見えます。。。
さて、現時点での考えを整理すると（あまり業務に関わるようなことは書けませんが、せめて事例紹介ということで）、
- ソフトウェア設計が局所的で、統一感がない
- ビジネス要求が実装と密結合になっている
ということかなと考えています。最初の点は、大きめの開発組織ならばよくあることかと思います。急激に人員が増えたということ、そしていままで仕組みが中途半端に作られてはアンドキュメントなまま、技術的負債が溜まっていくという話かと。。。わたしはまだ入社して日が浅いわけで主に負債の悪い影響を受けることが多いわけですが、次第に負債を積んでいく割合が増えていくことでしょう。なるべく自分の業務内では「立つ鳥跡を濁さず」をしたいんですが、修正前のコードがすでによろしくない状態の場合は、泣く泣く積み増してしまうことになることも（この短い期間の中でも）ありました。そう、問題箇所を引き剥がせないんですよね、ちょっとソースコードを見ただけでは。
二つ目の点は説明が必要かと思います。とはいえよくある話だとも思います。へーしゃ、結構、企画の人間もほとんどプログラミング経験がある（というかソフトウェアエンジニアだった）ことが多いんですよね。そうなると、ロジックレベルで話ができてしまう反面、修正方法がシステム的な整合性や統一性を欠いていても、実現はできてしまうので話が通りやすいんですよね。いや、それ自体は素晴らしいことだと思います。本当に。ただ、どうしてもこの方法だとすばやく企画を実行していく側に軸足を置く仕様になるので、これも技術的負債が溜まりやすくなる一因となるんですよね。意外と。みんなプログラミングできればハッピーかというと、そうでもなく。みんながドメインモデルとアーキテクチャを共有できていればいいんですけど（夢のまた夢）。
そんなこんなで、読書しながら引き続き、考えます。
