-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinhiroshima20151202
２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。前々回から日本プロジェクトマネジメントの「PMシンポジウム2016のボランティアの企画会議」にも同時参加させていただいております。こちらはヒアリングが主体で、発言することもありますが、読書会参加者には迷惑かけないように進めていきます。あー、あと一回で最終章となり、第二回アジャイルサムライ読書会廣島道場も終わりを迎えます。
次回は、１2月16日にしたいと思います。
「エリックみたいにコードをかけたらなあ」これを感じるということは正解が分かっているということであり、少なくともエリックのコードを読んで理解できているということである。それが前提で、テスト駆動開発が存在するのでは？
テスト駆動開発は、テストを先に書くことでロジックが整理され、仕様がはっきりするということ、テストロジックを考えることは同様にプログラムロジックを考えることと同じだと思う。
テストロジックとは結果の判定を行うロジックである。判定であるがゆえに、はっきりと真偽に分かれないといけない
ついつい曖昧に考えている、自分の頭の中を判定できるように仕様決めを考えないといけなくなるので、テストを先に書くと良いということだ。
その他にも、テスト駆動にすることで、単体レベルの完成度が上がるということが挙げられる、単体レベルの完成度が上がれば、時間が経過しても、逆戻りが少なくなるということであり、やっていて安心感につながる。
レッド、グリーン、リファクタリング、このサイクルを回すことで、徐々にブラッシュアップされたコードになり複雑でもわかりやすいコードが書けるようになるということだ。
最初から高品質のコードを書かないと品質は上がらない、あげられない。この現実は存在する、最初に優秀なプログラマで基礎を作っておき、メンバーが増えても品質を下げないようにすることが大事だ。最初から品質の悪いコードだと、それが増殖して手がつけられなくなる。
まずテストを書き、それが失敗することを確認してから実装するというTDDの手順を踏んでいくことで、日々のコーディングで直面する数々の複雑さに立ち向かうことができる。複雑な仕様（プログラムレベル）は頭の中だけでは入りきらないこともある。
ケント・ベックの「テスト駆動開発」を読むこと。
必要なテストコードが、そこにあるがの如くコードを書く。大きなところから狭めていく感じで、書く。TDDは本当は設計手法であって、テスト手法ではない。（これは言い過ぎ）
次回は「継続的インテグレーション」だ。
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。