ここ数日はてなや僕のTL界隈で「技術的負債」話が盛り上がっていたので書いてみた。
僕自身、同業の中では比較的長命なプロダクトを受け継いで関わっている手前、日頃の業務の中で「負債」にぶち当たることは多々ある。
では、そもそも何が「負債」なのか?
もちろん世の中にはどう考えてもクソとしか表現できないような実装だって存在はするのが、それよりも業務上よく見るのは結果として負債化してしまった実装の方である。
ある時点では間違いなく素晴らしい実装だったものが、時がたちいつの間にか負債へと姿を変えてしまうことが多々ある。
僕の環境での事例を挙げると
管理画面から簡単入力! のはずが……
クソ実装の端的な例の一つに「設定値がコード内に散らばっている」というのがある。
ちょっとした変更のはずが何時間もかけてスパゲッティーをひっくり返すはめに、ということは同業者なら一度は体験したことがあるだろう。
運営側は「いつまで待たせるんだよ」と目に見えてイライラし出し、かといってエンジニア的に適当な部分で値を書き換えるわけにもいかず、、、
そんなわけで「管理画面からDBに設定値を入力し、プロダクト側はその値を使って振る舞いを変える」という機能を作成したとする。
運営は速やかに施策を反映できる、エンジニアも下らない思いつきにいちいち付き合わされてストレスが貯まることもない、素晴らしい解決策である。
しかし、時がたち人がかわりプロダクトもどんどん手が加えられていくとどうだろう。
「今回のイベントだけは〇〇な動きにしたい」「△△はいらないから□□に変えて」etc...
いつの間にかそこに残っているのは、運営に伝わる謎の風習と摩訶不思議な挙動、そしてメンテナンスできない管理画面。
(まだ読める言語だったら良いんだけど、Flash製の管理画面とか死ねる。ついでにソースも行方不明。)
そして、使い勝手が悪くなった管理画面は怖いからと新たな管理画面の作成チケットが発行され(以下無限ループ
そんな感じに、個々には妥当な(ベストとは言わないまでもベターな)実装でも積もり積もって結果的に「技術的負債」になるみたいなパターンがよくあったりする。
なんか言いたい事が正しく表現できてない気がするけど、つまるとこチームのレベルとか非合理的な運営とかそういうので、本来は素晴らしい実装だったものがいくらでも負債化するみたいなことがあるって話。
じゃあどうすればよいか?
チームはお互いの作成物にも気を配り、各々スキルアップに励まなきゃいけないね、という一般論しか僕には思いつかない。
コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2013/04/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (28件) を見る