技術的負債の生態 - maru source

@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので

[h13i32maru]

技術的負債について考えてたら「技術的負債が生まれること自体はボジティブ」とか面白いことをいくつか発見したのでブログに書いてみた。

[otihateten3510]

一番やばいのは「仕様の複雑性による負債」「事業の複雑性による負債」だと思ってるんだけどどうだろうか。ここらへんに手をツッコむエンジニアもっと欲しい。

[shikiarai]

技術的負債の定義は高尚なもので、我々が普段から抱えてるのはただの負債

[tattyu]

こんな高尚なもんじゃ無いよ。UIのトグルを1箇所入れ替えるのに優秀なプログラマで1週間以上かかるとかあるんだぜ？。ハードコーディングにスパゲティこそ真の負債。

[odakaho]

“どんな場合も「今この時、自分が考える必要十分で最善なコードを全力で書いた人」が責められる理由は一つもない” ／現実は、他人の「雑なコード」に苦しめられることが多い。

[harumomo2006]

客の内部闘争に起因する矛盾した仕様を実装させようとするのとかやめてほしい

[nakag0711]

これはこれでわかるけど、本当の技術的負債は原開発者の退職によって生じる。そうなったら作り直す以外にない。マイクロサービスはこの範囲を小さく留められるのではないかという気がしているが

[vndn]

負債の発生ってメタファがなんか気になる。①プロダクトを作る ②学びを得る ③プロダクトに改善点を見つける ④改善する としたとき、②と④の間にあるのが負債で、③と④の間は……タスク? 間に潜在的負債があるよね

[kamayan1980]

これ「リリースされたコードは当然リファクタリングなど済んでいるべきだ。君はパンツも履かずに外出するのか」って次元の話なので、下々の人間にはかなり厳しい内容ではある。

[easy-breezy]

仕様の浅さによって、実装する前から負債になるのが確定している機能は割とある。作るときに気が重いやつ。

[iekusup]

ほー。

[uzuki-first]

“リファインメント”

[ken2mer]

負債は避けられないがポジティブなものとして捉える。人が成長(学習)するということなので、それに合わせてソフトウェアも成長(学習を反映)させていく必要がある

[nanakoso]

みんなベテランに仕事してほしいが、だれだって最初はビギナーだ

[Tomato-360]

“ここまででわかった技術的負債へのアプローチは次の2点だ。 「ビジネスドメインの新たな理解を定期的にコードに反映する機会」を作る 「必要なときに必要なプログラミングスキルを学習する機会」を作る”

[braitom]

ふむ。“ビジネスドメインの技術的負債は「新たな理解をコードに反映できない」から発生する、プログラミングの技術的負債は「知らない」から発生する”

[lbtmplz]

GetWildしたい

[yetch]

新人が書いたコードはベテランにとって全て負債ということになりはしないか。

[abcdefghijklmnopqrstuvwxy5]

「保守するの俺じゃないからヨシッ！」

[fuji_haruka]

「技術的負債は学習して新たな理解を得られた結果生まれるものなので、生まれること自体はポジティブである。」

[rryu]

問題なのはかさむ利子によって首が回らなくなることなので発生すること自体は許容すべきだと思う。COCOAみたいに全体が負債になったりするとなかなかつらいが…

[hnishi2509]

“経験した技術的負債”

[rck10]

ドメイン負債はまだしも、プログラミング負債は、客からしたらふざけんなってなると思うが。”完璧なコード”は夢物語だとしても、これでは低スキル人材をアサインして開き直るようなロジックにしか聞こえない。

[t-wada]

技術的負債とは対象についての理解と目の前のコードのギャップ。ビジネスドメインの負債は新たな理解をコードに反映できないから、プログラミングの負債は知らないから発生する。翻訳を参照いただいて嬉しいです

[pavlocat]

プログラミングの技術的負債で言うと、技術者間のスキルの差によってAさんが書いた瞬間、Bさんにとっては既に負債、みたいなこともある / こっちも本来の意味では無いとは言え本質的に不可避で重要だと思う

[gcyn]

『「学習しない・意図的に雑なコードを書く」というのは考慮していない。それは別次元の話である』というのを読んで、"意図"ってことの理解・表現は難しいんだな、それそのままこのテーマだなと思いました。

[clash_m45]

素晴らしい洞察

[ardarim]

「「学習しない・意図的に雑なコードを書く」というのは考慮していない。それは別次元の話である」しかし自分の書いたコードなら負債も喜んで受け入れようが、引き継ぎで渡された秘伝のソースに含まれる負債は…

[turanukimaru]

カラテ…じゃなかった。テストだ。テストあるのみ。正しい動作をテストとして文書化するんだ。カラテの動きを見て学ぶようにテストの動きを見て新人も正しい挙動を理解できる。カラテのようにテストを洗練するのだ。

[khtokage]

ああ、元記事 https://bit.ly/2NEfIUt で「技術的負債」が改めて定義し直されてるのか。私もリンク先読んでないズレたコメントになってた。

[gfx]

"むしろ技術的負債が生まれることそれ自体はポジティブである"

[hamasakie]

技術的なものは作り方に個人差ありすぎるから別の人が作ったもの修正するより作り直した方が早い（理想）んだけどコストややる気の問題があって難しいよね

[knok]

作り直しが一番いいんだろうとは思ってはいるのだがなかなかそれを許す状況は特に仕事ではないねえ

[haruten]

面白いし腑に落ちる話だった。構想を形にした瞬間に、変化を止めない現実との間にギャップが生まれるということだよね。「負債」と呼ぶのが良くない気がする。ブコメの大半は負債でなく単なる手抜きでは。

[shodai]

“ビジネスドメインの技術的負債” そんなのあんのか

[tobigitsune]

数十年モノのシステムで採用言語そのものが古臭いとか、当時の言語のバージョンやコーディング規約が古いとかは、どういう分類になるんだろうか