15章 廃止
前文
廃止は、システムの長期的管理方法についての考慮を要するため、これもまた正確にはプログラミングというよりソフトウェアエンジニアリングの専門分野に属するトピックの一例だ
「ソフトウェアエンジニアリングは時間で積分したプログラミング」という1章の文言を思い出した
f(t)の値がマイナスになることもあるよね
15.1 何故廃止するのか
コードは債務であり、資産ではない
価値をもたらすのは、コードが提供する機能なのだ
「ハンマーしか持っていなければすべてが釘に見える」現象で、コードを書くのが好きだとこの罠に陥りがち
コード0行で寝ててもカネが入ってくる仕組みが理想である、というのは繰り返し確認しておきたい
これまさにだなーっておもいましたね。B/Sで考えるのとか大事ー。
『単体テストの考え方・使い方』でも似たような表現してたな
時間やお金をかけたものをできるだけ残しておきたいという心理が働くのもわかる
15.2 何故廃止はこれほど難しいのか
Hyrumの法則
これは「仕様として何を約束しているかに関係なく、システムが持つあらゆる挙動に依存するユーザーが出る」という話だけど、似たようなディスコミュニケーションが起こっているのを見たことがある
ビジネスマッチングシステムで候補者を紹介すると謝礼金を渡す機能を廃止する際、「自分はそちらに協力してあげてるのになぜこの機能を廃止するのか」というクレームがついた
廃止する理由は候補者紹介を業務として行っている紹介者が大半だったため。つまりクレームをつけた人はほとんど紹介をしていなかった
謝礼金の機能はインセンティブとして設計したものだったが、お金を渡すことで紹介者の増長を招いていた
機能の使用方法だけでなく、提供意図も予想もつかない形で捉えられる場合がある、という話でした
開発者の愛着によって廃止が進まないって言うの、現場のエンジニアみているとよくあった。
完全移行よりも、インクリメンタルにリファクタリングしながら廃止する方が政治的にもコスト的にも安いって言うのは経験とも一致する。
「システムを最終的に廃止できるように設計するという発想は、ソフトウェアエンジニアリングにおいては過激かもしれないが、他のエンジニアリング専門分野ではありふれたものだ。」
ちょうどシステムリプレースに取り組んでますが、今のを入れ替えるためにどう廃止して入れ替えていくかは考えても、入れ替えしたものが廃止される時のことまでは考えてなかった…というか今まで設計段階で作成中のシステムの廃止のことは考えたことない気がする…
ソフトウェアエンジニアリングはここを過小評価されがち。物理的に劣化するものではないので
アプリケーションコードより、データベースの移行が大変
15.3 廃止の類型
勧告的廃止と強制的廃止の2つがある。っていう整理なるほどな。
「勧告的廃止をするときには移行先システムはβテスト期間中ではなく、本番稼働に耐えるべき」っていうのなんか失敗したんだろうなっていうのを感じるなw
昔のニコニコ動画は新バージョン移行時に大抵荒れてたのを思い出しました。勧告的廃止でもこだわりのない人をとりあえず移行させないと全然新バージョンを使ってもらえない。かといって旧バージョンに戻せないと荒れるので旧バージョンに戻せる機能を作る。新バージョンの出来が悪いとこだわりない人も旧バージョンに戻しちゃうので、移行が進まない
15.4.3.3 後戻りの防止 に似た話があった
15.4 廃止プロセスを管理する
重要だけど緊急性が低い作業は20%ルールで行うっていうのもいいな。
廃止予定の機能にかかわるコードを呼び出しているかどうかをログからわかるようにするっていうのは、影響度を測る上でもいいなー。APIのログだけで判断するとこういうリファクタリングの工数がわかりにくくなりがち。
使ったユーザのIDとタイムスタンプを吐くよう仕込んでおくとやりやすいですね。ログではなくできればDBに
15.5 結論
保守のオーバーヘッドとエンジニアの抱える認知的負担を軽減する
廃止をする理由はこれがすべてだけど、ビジネスサイドに納得させるのが難しい
逆に、一度納得してもらえれば強力な味方になるので小さい「使ってない機能」を積極的に廃止していくのを個人的にはおすすめしたい
「どのくらい使われているか」を計測する機能をつけるのはセット
やはりまずは透明性。
15.6 要約
Googleでも計測が難しいって結論になっているのが、ことの難しさを象徴している気がする。ここまでめちゃくちゃ計測について書いてあったのに。
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
事例が多数あるかどうか
やったことがないとやることのメリットを感じづらい
現場でどこまでできているか?
実際にサービスのクローズをしたり、画面をみれなくしたりはしてきたり、あとはAPIをがらっとかえたりしてきた。ただ、どれもやはり数年に1度くらいのものだったなー。
この本があるのになぜ実践する企業はすくないのか?
書籍にも難しいとあったとおりだけど、20%ルールみたいなのがないのもおおきいのかも?
「お客様のために」というお題目が使われがちなので、計測しないとしんどい。でも計測は難しい
それの乗り越え方はなにか?
コード行数をめっちゃ小さくするとしたらって議論をするとか。Q毎に小さい機能を1つ廃止してみるとか?
たしかA Scrum Bookにあった。Product Wakeだった。
コードを触っていてイラッとしたらまず「消せないか?」を考える習慣
ステップを小さくするとしたらどうできそうか?