ReadingAgileSamuraiInShibuya20110907
テストは命綱。コードの修正や追加をするときに、既存のユニットテスト群が警告を出してくれたおかげでバグを作りこまずに済んだことが何度もある。
テストによるフィードバックは短いほうが良い。コミット時よりもはやく、保存時にテストが実行されるようにテストの実行を自動化すれば、 より早く気づきの機会が得られる。
各言語でのツール例
- ruby: autotest, spork
- php: Stargehand_TestRunner, MakeGood
- autoprove, Test::Continuous
テストを書く能力、読む能力、読み易くある為の書く能力
テストが書きづらい…でもそれは設計がまずいのかもしれない(p241) テスティングフレームワークを知ると共に、オブジェクト指向やデザインパターン等の知識もあったほうが良いと感じた
オブジェクト指向の理解やデザインパターンの理解は、アジャイルな開発をしていく中で「行き着く先」という認識でもよい、とにかくできる事からやっていく事が大事
テストをしっかり書くとプロダクトコードより多くなりませんか？ → なる(「行き着く先」に近づいていると言う事)
まずいコードは「負債」なので、もう終わりが見えていて破棄されるもの、大きすぎるもの以外は「負債を返さなければいけない」 という意識が必要と再認識
「リファクタリングとは、（...)少しずつ継続的に設計を改善していく手順の総称だ。」の「少しずつ」という言葉が重要。「まとめて一気にリファクタリングする機会を設けよう」とかいう話が出たら「なにか変だ」と思わないと。
書籍の中盤までは「今考えなくてよい事は後で考える」な考え方が示されたが、リファクタリングは「後回しにしない」という考え方が示されている。それは技術的負債はこっそりと忍び寄る(p250)からで、日々の開発では物ができていく事には気が向くけど、その裏で積み重なっていく負債には、認識できても後回しにしたりしていた…結果としてスパゲティー→汚名(p257)…よくないパターン、ありました。
###[感想] angler_ishikoro Agile Conference」で「Martin Fowle」氏からも以下のコメントがありました In software development, “perfect” is a verb, not an adjective. ソフトウェア開発においては、完璧というのは形容詞ではなく、限りなく改善を続けるという意味の動詞である。 「To Perfct」ってことでしょうか。何より続けることが大事なんだと思いました。
###p261 「どうやったらそんなにわかりやすくて見通しのよい、きれいなコードが書けるんだい？」の"きれいなコード"は、原著ではClean Codeとなっている。Beautiful Codeとかではないことに注意されたい @remore
動的言語では、テストファーストでテストがまずコケる事を確認するのは大事
ペアプロ、良いですよね。
なんでペアプロすんの？ → ちょっと解らないと事か聞けるから
先週末のXP祭りのLTで"常にDemo Ready"という言葉を知ってかっこいいと思いました。（下記スライド16ページ目）
"常にDemo Ready" これができないと良いものは作れないよね
とは言え大きな機能を作る際には、マージの間隔が長くなってしまう。もっと機能を細かく分割すべきかな。
デイリーで各ブランチにトランクの変更を取り込んでから終業する様に習慣づければ良い
###p280 この図は大事な手順が足りない。1の最新のコードを取得したら、テストがオールグリーンであることを次に確かめなければならない。そうでないと、以後の変更によってテストが落ちたのかどうかがわからなくなる。 -- @HIROCAST
こういうことやる人はプログラマと名乗らないで欲しい。具体的な例（あるある -- @HIROCAST
- 手元でテスト通るの確認しないでpushしてくる
- ビルド、テストが落ちた状態で帰宅する
- ビルド、テストが落ちてるのに修正せずに他のコードをコミットする
- テストが遅いからコメントアウトする。だったら、早くしろよ。
- テストが通らないからコメントアウト（削除）する。もうプログラマ辞めた方が良いですよ。
###いくつか具体的に書いておく -- @HIROCAST
- 代表的なビルドエージェントは Jenkins 大抵の環境、大抵の言語、大抵のことはできる
- リポジトリ(git,svn)を監視して変更があればビルドして、メール、IRC、Skype、Growlで通知
- デプロイの自動化は capistrano が王道 大抵の環境に適応できる
- push → ビルド（テスト）→ オールグリーン → Capistranoでステージングへデプロイ を自動化すれば非エンジニアがいつでも確認できてフィードバックしてもらえる
上記の様な環境をイテレーションゼロで用意しよう
つまらないバグなんて出しているヒマはない、CIがないとアジャイル(イテレーション)は難しい
###p285 これらの4つ(ユニットテスト、リファクタリング、テスト駆動開発、継続的インテグレーション)を実践することなしにアジャイル開発を成功させることはかなり難しい。本当に難しい。難しい。難しい。 -- @HIROCAST
1日1回の夜間ビルド程度だと、他人のチェックイン（例：DBスキーマ変更）で自分のテストが落ちる（そして犯人扱いされる）ということがあるので、できるだけ細かくビルドしたいところ。「自分のコード」というのがなくなるくらいコードの共同所有が進んでいればいいんですが、なかなかそういう現場は見ませんよね。
リファクタリングについても同様に言えるけど、日々これらのプラクティスを規律正しく実践(p302)していく姿勢がBushibo(p299)の精神だったり「サムライ」っぽい。
###P286 誰かにアジャイル開発をおしつけるのはだめだ。何をするべきか口で言うだけじゃいけない。具体的に行動して、君が模範を示すんだ。 -- @HIROCAST
強力で危険な知識とノウハウ(p285)、「危険」について皆さんの意見をうかがいたいです。
- 上手じゃなくても完璧じゃなくてもやらないよりやった方がいい
- 結局やんなきゃ変わらない
- 問題点を明言しよう、マインドとメリットを伝えて吹き込む(最初はアジャイルアジャイル言わない方がよい)
- テスト書く事に許可なんていらない
- 考えて、振り返る、考えて、振り返る、だんだん良くなっていくからク・ジ・ケ・ナ・イ
- 初めなければ現状の変化はゼロのまま、目の前の現実に向かう！
##A.1アジャイルソフトウェア開発宣言
##A.2 アジャイルソフトウェア開発の12の原則
「もっとソフトウェアをうまく作りたい」という情熱・思い・価値、ちゃんと伝えられる様に実践で試行錯誤していきたいです
p304 「でもやるんだよ」は根本敬氏の言葉らしい。町山智浩氏がよく使う。
 |
ジャック・ブラック￥ 980
|
 |
ジャック・ブラック￥ 1,200
|
p306 師を仰ぎ、師を追いかけ、師に歩調を合わせ、師の意図を組み、そして自らが師になるのだ -- @HIROCAST
- 大塚さんお疲れ様でした、話が面白かったです
- 胸を打たれた
- 明日から(すぐにでも実践するぞ)っていう空気
- Shibuya-Agile として To be cont.
- 次回も何かやる・出席する
- Wiki 新規ページ作ってみた
- 1回の欠席以外は全部これた
- 遅刻
- 週一の平日夜はちょっとキツかった…
- うまくまわせなかった(ファシリテータ) ←そんな事なかった、GJ!
- 会場提供できるかも、何かのイベントの時はお声かけ下さい
- テスティングフレームワークやツールを試す
- Jenkins、Capistrano、Chef、Redmineとかを試したい・深く使いたい
- CI、コミットからデプロイまでを自動化する
- アジャイルのメリットをもっとわかりやすく説明する(社内で)
- 現場を変えていきます!!(少しずつ…)
- アジャイルを自分の運用業務に活用する
- アジャイル体験談を話せるように
- Shibuya-Agileの題材募集