ソフトウェアの捨てられビリティ(Disposabiliy) 2021

こんにちは、魅惑の何かです。秋の夜長にポエムでも描いてみました。

夜にmagnoliakさんのこの辺のツイートをみててアウトプットしたいものを思い出したので忘れずに書いておきます。

本当に必要なビジネスロジック以外はいつでも捨てられるように処理を書くのがいいんじゃないかなと思い続けている。個人的には　捨てられビリティ　とか呼んでる。捨てられビリティ　が低いと後に変更が厳しくなりがち的な
— Nakamura Masato (@Masahito) 2021年3月6日

背景

初期開発、リリース後に変更を加えていくことで変更のコストが大変になることが多い。

また途中で開発の(いろんな意味での)事情がかわり設計を変えたくなることも多いかなーと思い続けています。

ただ、すでに動いているシステムを変えるのは大変なんですよね。

じゃーどうするの

ソフトウェア自体は動きを止められても、毎日の経済活動を止めることはできない。

だから要は今あるものを動かしつつ、捨てる or やり直すことを前提に処理を書き続けるにはどうするかということを考えるのが良いかなと。

例えば並行でシステムAを動かしながら、同様の振る舞いをするシステムBを動かすなど。

まだまだ自分でも上手く言葉にならないのだけど、いつでも対象システムのマイグレーション(移行)ができるように備えていくのが良いのだと思う。

この対象システムの裏側の制約を明らかにすること(例: このバッチはなぜこの時間から実行開始しているか、また後続システムではこの処理がいつまでに終わることを期待しているか)
ビジネスロジックへの(少なくとも)ユニットテストの付加
ここで行っている処理は短期、中期、長期で使うものなのか。(大体の場合生存期間がビジネスロジックは捨てられビリティをあげる必要あり。なぜならここの施策は短期間で変わるから)

まとめにならないまとめ

なーんてことを近頃考えながらお仕事をすることが多いです。

変更にコストがかかるような状態は本当にしんどく、保守する側の人は疲弊してしまうことが多いんですよね。ビジネスロジックも短期的に必要なものとか、経営方針で変わるものとか、長期で変わらないものとか本来分類できるはずなんですよね。捨てていいフラグとかをビジネスロジックに書いておくとかがあってもいいのかもなーと思ってます。

そのためには、やはり対象システムのやってることの明確化（ドキュメント化を含む)と最低限のユニットテストでもないとそもそもやり直すのも大変になりがちだよなーと思ってます。