Showing 3 Result(s)

レガシーコードからの脱却 まとめ – 10.8 – 10.9

10.8 テスト駆動開発をチームに広める 内容 テスト駆動開発の正しいやり方を身につける唯一の方法なんてものは存在しないが、まずは、良い共通理解を形成するところから始める。 テスト駆動開発導入にあたって足かせになるのは、経営者と開発者それぞれ異なったテスト駆動開発に対する負の先入観。これらを統一した共通認識にするところから始める必要がある。 10.9 テストに感染する 開発者の最初の大きな課題は最初にテストを書くことが不快だということだ。なぜ不快かというと、実装を集中して書くことを訓練してきたからだ。その習慣をやめて最初にテストを書くようになるまで長い時間がかかる。 開発者は「目的」と「やり方」の世界を行き来するが、まず「作るものは何か」(目的)から始めるべきだ。それがインターフェイスであり、テストだ。 まず、呼び出すメソッドの外観、名前、入力パラメーター、戻り値を明らかにする。それから「どうやって作るか」に焦点を合わせる。 一直線にプロダクションコードを書くという習慣をやめれば、自然にテストファーストに考えられる。この現象を、テスト駆動開発の初期提案者の1人エリック・ガンマ氏が「テストに感染し始めた」と言った。 学び チームに導入したければ、経営者、開発者はそれぞれの観点でメリット、デメリットを整理して共通認識になるように準備する必要がある。 テストを最初に書く違和感の直し方は、「作るものは何か?」(外観、名前、入力パラメータ、戻り値)を明確にし、そのテストを書くところから始めよう。 最初にテストを書く習慣が開発者にはない。 学びを活かすアイディア・行動 テスト駆動開発のメリデメの整理。経営観点と開発観点。 テストコードの目的の事前知識整理

レガシーコードからの脱却 まとめ – 10.6

10.6 テスト可能なコードを書く 内容 テスト駆動開発をやっていないし、やりたくもないマネージャーに対して納得させた言葉。 テストファースト開発するかどうかは気にしないが、テスト可能なコードを書くかどうかを気にする。テスト駆動開発はそうするための方法だ。 テスト駆動開発はテストファーストでテストを書くため、自然とテスト可能なコードになる。 うまくいかない状況というのは、設計の問題があって考え直すべきであることを示している。テスト駆動開発は、難易度のダイヤルを持つようなものだ。詰まってしまったときには、いつでも「哀れになるほど簡単」にセットして、そこで少し自信をつけてから難易度を上げる。これを自分自身でコントロールしていくのだ。 このようにして、うまく進めなければ謙虚に前に戻り、設計し直し、最後にはよいテストとテスト可能なコードを作る。 学び テスト可能なコードかどうかが重要。 テスト駆動開発はテストファーストでテストを書くため、自然とテスト可能なコードになる。 間違ったなら、素直に認めて前に戻ろう。 学びを活かすアイディア・行動 テストコードの目的の事前知識整理

レガシーコードからの脱却 まとめ – 10.4 – 10.5

10.4 テスト駆動開発はすばやいフィードバックをもたらす 内容 ソフトウェアを開発するいちばん安価な方法は、最初からバグが発生しないようにすることだ。次に安価な方法は、あとで別のチームが修正するのではなく、発見したらすぐに同じ人または同じチームによって修正することだ。 一連の刺激と反応のトランザクションが精神に定着するためには、刺激に対してすばやい反応を続けることが必要だと、ある生物学者は示している。この生物学的観点でも、バグを生んだ本人がすぐ治すのが早いということになる。 そして、テスト駆動開発はすばやいフィードバックをもたらしてくれる。 10.5 テスト駆動開発はリファクタリングをサポートする コードがテストによってサポートされている場合は、リファクタリングが安全にできる。何かを間違えたらテストが失敗してすぐに教えてくれるからだ。 リファクタリングが必要なシーン 視野が狭くなっていると命名が少しずさんになる傾向がある。 ふるまいを実装している最中に、何に命名をする必要があるかわからなくなることがある。 アジャイルはリファクタリングしながら進むと効率的 アジャイル開発では、すべてを最初から理解しようとせず、反復的にソフトウェアを「間違いながら」「設計しながら」作ることが許されており、そのほうがはるかに効率的。そうするためにはリファクタリングしながら進むのは必須で、そのためにはテストが常にサポートしてくれる環境が必要。 学び 記憶を定着させるには反復練習が必要。 レガシーの匂いがするコードは対処を先延ばしにしないようにしないと、レガシーコードを作った本人がいなくなる可能性がある。レガシーコードが残ると拡張しづらいシステムになるので、レガシーコードはなるべくリアルタイムで修正する。 レガシーコードを産まないようにするにはテスト駆動開発とペアプロすると、正しく進んでいくのがよいのではないか。 リファクタリングにはテストを担保するものが常に横にある必要がある リファクタリングは開発中が一番コストをかけずにできる 学びを活かすアイディア・行動 現場にテスト駆動開発をシフトさせる。どうすればいいか。。 現場のリファクタリング計画のためにリファクタリング内容に紐づく修正ファイル対象の一覧を作る。案件があるときに、合わせて修正を検討する。