技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
なぜ TypeScript の型システムが健全性を諦めているか - Qiita
class Animal { kind: string } class Dog extends Animal { dog_type: string } function showDogType(dog: Dog) { console.log(dog.dog_type) } // 代入不可のコンパイルエラーになってほしい const someAnimalFunc: (animal: Animal) => void = showDogType // 実際はここでランタイムエラー someAnimalFunc(new Animal()) このコードがコンパイルエラーにならず, 実行時エラーになってしまうことについて. TL;DR 型システムの健全性 (型の矛盾が生じないこと) vs 利便性のトレードオフから, 現在の TypeScript は健全性を諦めている 関数型はパラメータについて biv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
