技術的負債 - koushisa

https://pbs.twimg.com/media/FtQp4_caMAAQPiC.pnghttps://pbs.twimg.com/media/FtQp4_facAAsz1G.pnghttps://pbs.twimg.com/media/FtQp4_haYAI3xvq.pnghttps://pbs.twimg.com/media/FtQp4_ZaIAAg5H1.png

@tanakahisateru: 下手で安いプログラマーを雇ってやっつけで開発しても、それで商売が成り立てばいい、という流れで生まれた技術的負債もあるだろうけど、その負債の選択はそもそも経営者の判断なんだから、いくら開発者が奮起してそれを負債だなんとかしなきゃと言っても意味がなくて、もう経営やるしか手がないのでは

@wonderful_panda: その場しのぎのコードは必ず負債になる、それは全くその通りだな。

だがオレは、その負債を返すのがオレじゃないって可能性に賭けるぜ！

@sinsoku_listy: なんか昔にツイートしたけど、技術的負債を積みながら分かりやすい成果を生んで、その成果をアピールして転職した方が合理的という話があってな…

技術的負債は経営判断（責任の在り処はトップにある）というのは一理ある #エンジニアリングの経済性

契約形態や開発組織の構造によっては無理ゲーな場合もあり、諦めるのも合理的だ

「どうせ責任とるのは上なので、いまの責任範囲で割り切ってサッと作ってシュっと去る」みたいな

戦略の失敗は戦術で補うことはできない

業務委託エンジニアと直接雇用エンジニアの最大の違い

だからと言ってそれを免罪符に書き捨てなコードを量産してはならんが

だれかがオーナーシップ持たないと解決できない

まあ、問題が見える化されづらいところから分断が起こっていることと推測する

ウォーターフォール型だとそうなりがちなのかもしれない

意思決定のレイヤが複数重なっていて、末端では太刀打ちしようがない（時すでに遅し）

見えないステークホルダもいたりする

過剰な分業によるオーナーシップ欠如

こういう文脈では小さいチームが向いてる

フィーチャーチームで、WIP制限を設ける

要件定義や仕様定義やQAもチーム分けせずに、小さいチームで完結させる

デザインは特権であるべきではない

QAは特権であるべきではない

開発者はフルスタックである必要はないが、チームはそうあるべき

→Stream aligned

→モジュラモノリス

根本的に複雑な組織課題

Stream alignedやアジャイルの適用条件に「全員がプロフェッショナルで越境できる」や「能動的に学べる」そして最後に「人事権」の壁がある

全体を見れる人が少なかったり、複雑性の問題で分業せざる得ないというのもある

なぜゲーム作りをまるごと理解できる人が増えないのか？

困難は分割せよ(サブドメイン分割)

@Kory__3: 「未来予知は不可能なので、可能な限り誠実にメンタルモデルをそのまま落とすことが後々の様々なコストダウンに繋がる」というどこで得たのか全然わからない謎の直感があって、これがここ数年の僕のプログラミング経験の中では驚くほどとてもうまく機能している

@Kory__3: 言語をより深く知ること、抽象的な理論を学ぶこと、形式を直感の永続化として重んじること、Premature Optimization を避けることは全部この謎の原理によって動機付けされている

@k1_c_: 必要に迫られて速さを追求した結果やむを得ず質が悪くなってしまったコードって実はこの世にあんまり存在しないくて、単に技術レベルが低いかだらしなさの結果なんだよな

「綺麗なコードを書くために勉強しながら開発してたら遅くなる」ってだけで、「綺麗なコードを書いてたら遅くなる」って話ではない

こんな話は何十年もの間無限に繰り返されている話なんだけど、ここで真になにが言いたいかというと、日頃の素振りがだいじということ

@fushiroyama: Twitterがゆっくりとしかし確実に壊れていっていることに残念ながら驚きはないというか、非常に複雑なソフトウェアの面倒を見る人を減らして急な機能追加をすると「分かりやすい大爆発」を起こすのではなくて「あちらこちらから無視できない水漏れが起こる」みたいな壊れ方をするんですよね

世界最高峰のTech Giantsが世界最高峰の頭脳を世界最高峰の報酬でかき集めて作られているものは鬼怒川温泉の崖に作られた無理な建て増しのような状態になっているというのは案外外からは想像しづらいと思うけど、僕がかつていた会社も多かれ少なかれそうだったし他の会社も似たようなものだと思う。

これは当事者のPMや経営陣からすら見えづらいことなんだけど、中の開発者はみんな知ってることだと思う。例えば機能Aがあって、これをBに変えるとする。理想的にはある一箇所を変えるだけですべてが切り替わる。こんなの簡単だと誰もが思う。でも実際はそうではない。同じフラグが2箇所にあったりする

これは極端な例だけど、ある状態機械があって状態変更を次々に伝播させていくときにbroadcastのような仕組みが多段になっているケースがあって、しかもラグや失敗があるのを表面からはリトライやsleepで隠しているようなロジックが普通にあったりする。こういうのが「水漏れ」である。

#水漏れ,_割れ窓

@fushiroyama:比較的大きくてもキレイなコードは本当に優れた技術者が独りとか2-3人で書いてる方が圧倒的に実現可能性が高くて、反対に数百人で開発してるソフトウェアは「クソコード」と「マシなクソコード」しか存在しない。

しかしこれはsarcasmではなくて、大規模ソフトウェア開発とは取りも直さず、停まることを許されないなかで走り続けながらクソをマシなクソに直しながらそれでも未来永劫走り続けることです。これこそが大規模開発の腕の見せどころなのですね。

@fushiroyama: もちろんみんなコーディング規約に則って、ユニットテスト書いて、コードレビューを通して、QAの末に皆の所に届くんですね。それでもバグるんですね。皆で何とか水漏れに蓋しながらコードを少しでもマシなクソにしながらそれでも走り続けるしかないんですね。これが大規模開発なんですね。

スタートアップで戦い抜いてきたRailsアプリをどう直す？既存Railsアプリを攻略する時にCTOが見ているポイント

https://scrapbox.io/files/6407f5f9d23455001bf95efd.png

#OODA

ハードシングスを引き起こしたHype Driven Development(HDD)

正しく開発したスタートアッププロダクトの初期設計は、正しく成長した未来からは壊れた設計にみえてしまう