-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinhiroshima20151104
２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。
二週間に一回の頻度で開催していた、アジャイルサムライ読書会in廣島道場ですが、このままでは年内のスケジュールが過密になることが分かったので、先週今週は連続して行うこととしました。１２章が短いというのも、先週が居酒屋だったというのも、影響しておりますが、年末ギリギリでの開催は避けたいというのが、一番の理由です。
個人的な話ですが、昨日平和国際マラソンに参加いたしまして、１０km走っておりますので、体がギシギシで辛いです
あーもう一つ別件が、プロジェクトマネジメント協会で本日「PMシンポジウム2016の第１回企画会議」が行われるようで、１９時からSkypeで参加できるようなので参加します。こちらは主にヒアリングのみと言ってありますが、突然PCにボソボソ話しかけても怖がらないでください（笑）
次回は、１１月１８日にしたいと思います。
「確固たるエンジアリングプラクティスで支えなければ」という文章、確固足りているのか？ プラクティスは守破離の守ではないとのツイッターを最近見かけた。だたらかもしれないが、プラクティスを守るよりも、なぜそれが必要かを本当に理解する必要があるとかなんとかだったと思う。
「アジャイルなソフトエンジニアリングの、ほとんどを支えているプラクティス」プラクティスがアジャイルエンジニアリングを支えている。のであれば、守破離の守はプラクティスと考えても良さそうです
最初にジョーカーをはずした際に、なぜそこに仕様を記載しない？ 少なくとも削除した痕跡を残せば、わざわざ追加はされなかったかもしれないではないか。と考えてしまうのは、テストコードを書いていない証拠かも？
ジョーカーの場合エラーとなるユニットテストを書いておけば、いろいろな際に役に立つということか
素早いフィードバック、コーディングと同時にテストコードも書くために素早くなる
低コストにリグレッションテストを実行できる、ソースを改修すればそのたびに再テストする必要があるが、自動化することによってそのコストは、人間が再テストするよりも随分と低コストになる
デバック時間を大幅に削減できる、壊してしまった箇所がわかるというのはユニットテストの書き方次第だとは思うが。それほど現行ソースに手を入れるのは怖いものである。
自信を持ってデプロイできる、自信が持てるというのもユニットテストの書き方次第、仕様を網羅する内容でかけていることが前提ですよね
「危なっかしいところをすべてテストする」のはXPのマントラ（註釈下）
マントラ：マントラ（मन्त्र [mantra]）は、サンスクリットで、本来的には「文字」「言葉」を意味する。真言と漢訳され、大乗仏教、特に密教では仏に対する讃歌や祈りを象徴的に表現した短い言葉を指す。
ケントベックの有名な入門記事：http://www.objectclub.jp/community/XP-jp/xp_relate/testinfected-j
本：Pragmatic Unit Testing in C# with NUnit[HT04] や Pragmatic Unit Testing in Java with JUnit[HT03]
壊れやすいテストとは、汎用性のないテストであり、仕様がうまく反映できていないということだと思う。壊れにくいテストが書けるということは、仕様がよく理解できているということの証明でもある。最小のテストで、最大の仕様検査を
次回はリファクタリングだ、自動化したユニットテストが前提のリファクタリングだ！
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。