ソフトウェア開発者の7つの誤り その5

• 私のコードは動く

• 私のコードは常に機能する

• 私のコードは規模に関係なく動く

• ユーザーの不正な入力によりシステムが破損したのは私の責任ではない

• 後でリファクタリングしよう

• ただの設定変更だ

• それは私の分野ではない

後でリファクタリングしよう

「後でリファクタリングしよう」はソフトウェア開発における最大の嘘のひとつです
「今は締め切りがあるから最低限動くプログラムで済ませますが、後でリファクタリングします」
「今回はちょっとした機能追加だけなので下手に抽象化しないまま実装しよう」
私を含めてITエンジニアたちはいつもこういうのです
でも、もうご存じの通り、これらが日の目を浴びることはありません

リファクタリングは狭義では特に新しい価値を生み出すことはないので、上長や経営層に「なぜ行うか」の説明するのが難しいんですよね
そんな負債が積み重なって、文化となって、いつしか砂上の楼閣が出来上がるのです
文化にまでなってしまうともはや一エンジニアができることはなくなってしまいます

リファクタリングしなければならない事態、つまり技術的負債がどうして生まれるのかというと、抽象化が不適切だからです
共通化すべきコードが共通化されていなかったり、逆にすべきでない共通化をしてしまったり―

例えば経理部門が扱う「注文」と出荷部門が扱う「注文」は同じ概念でありながらも別々の処理フローが存在して別々の用語が使われています
確かに共通化できるところはあるでしょうが、そうすると不必要に巨大で扱いにくい「注文」モデルとなり、経理部門由来の機能追加が出荷部門に思わぬ悪影響を及ぼすことになります

はい、聡明な読者の皆さまにおかれましてはすでに履修済みのことでありましょう、DDD（ドメイン駆動開発）の話をしております

ドメインエキスパートと会話に会話を重ね、質問を通して設計に磨きをかけるのです

とはいえ、いくら完璧な設計をしても技術的負債がなくなることはありません
そのときは完璧でも、ビジネスが成長するにつれてどうしても技術的負債は発生します

やはり定期的なリファクタリングは必要なのです！