「XP エクストリーム・プログラミング実践記」を読みました。
>> Amazonのリンクを貼っておきます。
https://amzn.to/4adzxb2
amzn.to
以下に当てはまる方々は読み価値ありです
- Javaプログラマーのかた
- テストファーストを実践してみたいかた
- テストコードがないSIerの管理職がチームをカイゼンしたくなったかた
- エクストリーム・プログラミングの実践はどんなものかが知りたいかた
勉強になったことをまとめる
- 「テストが書きにくい」とわかったら、それはシンプルな機能ではないのでカイゼンする
- ただ、難しい機能でもテストコードは必ず書くこと、後々救われるシーンが何度もくる
- 手動テストは数を重ねるにつれて、手順が複雑化する
- テストは2回実行しよう、1回目と前提が変わっている可能性がある
- テストコードはリファクタリングをする際の安定剤になる
- 顧客がエンジニアだったらテストケースを書かせるのもあり
- 要件の前提を間違えていないか、ペアプロするかたとコミュニケーションを密に取ろう
本を読んで現実の環境を交えた感想
実際の開発で問題が発生した部分をストーリーにそって書かれていてわかりやすい。見逃しがちですが、この本のやりかたは「開発 => 振り返り => 問題を発見 => 原因特定 => そこから学んだ教訓」を小さく繰り返しています。これはJavaだけのコードに限らず、プロジェクトチームでの振り返り、実生活でも捨て活の振り返りなど、応用できます。小さく行い、振り返りを行うチームは成長できます。
SIerに業務委託としてアサインした経験が10回ぐらいはあります。振り返りを行っている現場は1か所だけでした。それでもエクストリームプログラミングの手法は取り入れていませんでした。今の会社のことを考えると、管理職側でウォーターフォール開発の経験がやはり多く、アジャイル開発の手法であるエクストリームプログラミングを取り入れる段階ではないように感じます。上の変えるのは大変です。というわけで予め取り入れている会社に転職したほうがやっぱり早いよねという結論にいたりました。
Web業界で急成長中のメガベンチャーさんに業務委託としてアサインしたことがあります。そこでは毎週のように振り返りが行われていたりします。尊敬できる方々がたくさんいまして、「先にテスト書いてみますか！」と提案していただき、はじめてテストファーストで作ったことがありました。明らかにスムーズに開発が進んだので、そのかたがドライバーの助手席で指示を出してくれたことに、今でも思い出すたびに感謝しています。
ありがとうございました！
