エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
TDDをするべきではない場合 - ひげろぐ
TDDBC 福岡2をきっかけにTDDネタをしばらく書いてきたが、ひとまずこれで最後。 さてTDDに慣れてくると... TDDBC 福岡2をきっかけにTDDネタをしばらく書いてきたが、ひとまずこれで最後。 さてTDDに慣れてくるとコードに対してコントロールを握っている感覚がやみつきになり、何でもTDDでやりたくなることが実際にあるのだが、それが失敗や無駄を招くこともある。 そうした間違った万能感を抱かないように注意したい。 例えば再現性の低いものに対するテストは無駄が大きい。 増えたテストがかえって負債になってしまう可能性も考えられる。 次に短期間のプロジェクトでテスト環境構築に大きなコストがかかりすぎるケース。 これは環境構築にかけたコストを回収する前にプロジェクトが終わってしまう。あるいは環境構築のコストがスケジュール的なリスクを招く。 それからユーザビリティやゲームバランス調整やレーティング設計のようなテストできないものをテストしようとしてしまう場合もある。 こうした調整が頻繁に入るような分野で数値の