開発／テスト／デバッグ サイクル
GoogleのUpdate-Engineのテストとカバレッジについて書いてある文書がとてもためになります。
テストしやすいコードを書くことが重要 ・ユニットテストを行いやすいので、バグを発見しやすい ・テストで書いたコードの使用者になることでそのコードのAPIの使いやすさがわかる ・テストしやすいコードは独立性が高い傾向にある ・テストしやすいコードは柔軟性が高い傾向にある
というのはテストユニットを書けば実感できますし
「Cの関数をラップしてもそれはオブジェクト指向じゃないよ」「staticメソッドしかないクラスとか意味ない。namespace使え」なんてのはうん、うんよくいるよねーと共感できます。
またリファクターを行ったほうがよい兆しとして
・コードについて毎日のように悪態をつく
・メソッドや関数、クラスが巨大／複雑になりすぎて変更がしづらい
・クラスの機能が多すぎる
・クラス同士が結合しすぎている
・オブジェクトのテストが「とても難しい」
ということをあげていて、まさしく今見ているコードそのものだったりしてあせりますよ。
シングルトンの多用はよくない、とも主張していてこれはちょっと新鮮でした。説明を読むともっともだとも思えるんですが、うーんなかなか別の方法が思いつかない。
なんかGoogleのプログラマーといえども、（レベルは違うだろうけど）困っているところは同じなんだなぁと親近感を覚えました。特に
develop / test / debug / curse cycle
ってところに。やっぱりデバッグの後には悪態をつく過程が必要なんですな
トラックバック(0)
このブログ記事を参照しているブログ一覧: 開発／テスト／デバッグ サイクル
このブログ記事に対するトラックバックURL: http://hogelab.net/mt4/mt-tb.cgi/1753
コメントする