11月28日(月)に行われた、達人プログラマー読書会@札幌に参加しました。
テストの話やプロジェクトの話など、今も大切だとされていることが10年前に書かれていたことに驚きました。
34. テストしやすいコード
- テストによりコンポーネントの信頼性を高めることができる
- コードの実装を開始する前にテストを作成することでインターフェースのテストをしている
- テストは手近なところになければ使われない
- テストは繰り返し実行されなければいけない
- テストは技術というよりも文化
この短い章の中に、ユニットテスト・テストの自動化・CI・TDDなどの重要性がすべて書かれていました。
これらのことが重要である、とこの頃から言われていることにまず驚きました。すごい本だ。
「場当たり的にデバッグでテストを済ませない」であるとか「プロジェクトにテスト文化を植え付ける」であるとか、今、まだできていないことがたくさんあります。
テストの書き方にもまだまだ悩みます。
「テストは文化」とは、まさにそうだなと思います。
今のプロジェクトにはテスト文化を広めてくれる指導者がいます。おかげでさぼらずにテストを書く、テストから書くという習慣（思考の変化）ができてきました。
これからも精進したいと思います。
35. 邪悪な魔法使い（ウィザード）
新人〜2,3年目の自分に読ませたかった章。
何となくソースコードが書けるようになってきた頃に陥りがちなこと、それは
「フレームワークが何となく使えてればコードが書けている気になる」です。
でも、それだと自分が何を書いているか（どんなバグを埋め込んでいるか）ちっともわかってないのですよね。
- 作り出されたコードの意味が本当に理解できていなければ、自分自身をだましていることになる
- 生成されたコードが理解できないようなウィザードを使うということは、自身のアプリケーションのコントロールを放棄することに等しい
昨今は開発を加速化するため、便利にするために作られた素晴らしいフレームワークやウィザード形式のコード生成ツールなどがたくさんあります。
それらのコードをすべて理解しなければ使うな、ということではなく、
- 何が起こっているか（少なくてもどんなソースがどこにできているか）を理解しておくこと
- いざとなったらきちんとソースを解析できること
- 自分がそのソースコードに手を加える際に適当になんとなくコードを書かないこと
これらを意識しておくだけでも「自動生成コードに振り回されない」プログラマになれると思います。
36. 要求の落とし穴
ここから第7章「プロジェクトを始める前に」に入ります。
お客様の要求を捉える、掘り起こすという、ちょうどアジャイルサムライ読書会でも行っているテーマでした。
どちらも同じことを言っていました。
- 要求が表面上に現れていることはほとんどない
- 最終的な目標はお客様のビジネス上の問題を解決すること
- 要求の掘り起こしは、ユーザーとの親密な関係を築いていく始まりの時
- 要求とは設計ではなくニーズそのもののこと
一つニュアンスがアジャイルサムライ（アジャイル開発）と異なるなと感じたところは
「お客さんは何もわかっていないから開発者がすべてのお客様のニーズをうまいこと引き出す必要がある」
という立場が達人プログラマの方が強めに書かれているなというところでした。
アジャイルサムライでは「お客様がプロジェクトチームの一員となる」ことの重要性が説かれています。
「ユーザーと親密にならなければよいものは作れない」という考え、目指すところは同じですが、アプローチの方法が若干違うなぁと思いました。
名前大事
この章の後半に書かれている「プロジェクト用語集」は本当に大切で、しかし、往々にしてプロジェクト途中で空中分解してしまうもの、です。
プロジェクトの終わりの方には全然更新されてない「（参照してはいけない）用語集」がサーバーに残っていたり・・・。
wikiを使うのも一つの方法かもしれないし、SVN管理することで自分のアクセスしやすい場所においておくこともできるのかな、と思いました。
そして、なにより、開発者間、開発者とユーザー間で「名前大事」という感覚そのものを共有することが大切なのだな、と感じています。
みんなに知らせる
wikiの重要性。2年前だったら言っていなかったと思うこの言葉。「wiki大事。」
使ってみなければわからないとはまさにこのことだよなー、とこの1年ちょっとで実感しております。
だいぶ、本の終わりが見えてきました。
最後まで頑張ります。