bliki: Cannot Measure Productivity
We see so much emotional discussion about software process, design practices and the like. Many of these arguments are impossible to resolve because the software industry lacks the ability to measure some of the basic elements of the effectiveness of software development. In particular we have no way of reasonably measuring productivity. Productivity, of course, is something you determine by looki
bliki: Test Coverage
From time to time I hear people asking what value of test coverage (also called code coverage) they should aim for, or stating their coverage levels with pride. Such statements miss the point. Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are. Let's look at the second statement first. I've heard
技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
