Readingagilesamuraiindwango20110928

2011年9月28日：アジャイルサムライ@ドワンゴ道場

参加者：@futoase @guccii @kwappa @erukiti @tetsu @hedachi

前回はこちら。

第12章 ユニットテスト：動くことがわかる

12.1 ラスベガスへようこそ！

12.2 はじめてのユニットテスト

• ユニットテストのイントロみたいな話。
• ユニットテストの価値は書いてみないとわからない
• 最近ホッテントリに上がった記事は昔からある話の再発見だった
• プライベートメソッドをテストしたい場合、全部パブリックで書いて最後にプライベートにするという方法もある
• プライベートメソッドまで全部書いてると終わらないし細かい変更に弱くなる。インプットと最終的なアウトプットだけチェックするとか
• IDEのテスト機能をうまくつかう
• カバレッジ１００％を目指してると終わらない。カバレッジを上げることが目的になると本末転倒
• 目的を見失わない。なんのためのテストか。テストのためのテストにならないように。
• テストを書くのに時間を割く価値を理解してもらうのが難しい
• 「テストを書くと時間は２倍かかるけどバグは半分になる」という人もいた。
• 前の職場で「なんでテストばっかり書いてプロダクトコード書かないんだ」と言われた

第13章 リファクタリング：技術的負債の返済

13.1 どうしてこうなった

13.2 技術的負債

13.3 リファクタリングで技術的負債を返済する

• 家に例えて、家に住みやすくするためにリファクタリングしましょうという話

• 技術的負債

• 技術的負債という言葉は最近でてきた

• 名前がついて認識しやすくなった

• 技術者じゃない人にも説明しやすい、理解してもらいやすいメタファ

• 負債が負債を呼ぶ。指数関数的に増大していく

• リファクタリングという言葉は最初はソースコードの話だったけど、データ構造などにも適用されるようになってきた

• 割れ窓理論

• 既存のコードを見てコピペが多かったら、ここはコピペする文化なのかな、という感じでコピペしちゃったり

• プログラマの時間の９割は名前を考えること、という記事が最近あったけど的を射ている

• 名前が決まれば９割できる

• 規約のせいでよろしくない名前になる場合もある

• Pearの規約とか

• MSのはEXがついたり

• ハンガリアン記法とか http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

• デプロイの仕方などは最初のやりかたを後で変えるのが難しい。最初が肝心

• 最近サーバのリプレイスがあって、そのついでに色々と技術的負債を返済できた

• 大きくなった負債を返すには工数がかかりすぎて、その割にメリットが目に見えにくいので、永遠に返せない負債になってしまう

• 毎回出てくる話だけど「レガシーコード改善ガイド」は必読