読者です 読者をやめる 読者になる 読者になる

@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

アジャイルサムライ-達人開発者への道- その5

book development

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

第5部はアジャイルなプログラミングについてですね。
第12章はユニットテスト:動くことがわかるです。今更説明する必要もないと思いますが、テストを書きましょうと。イテレーティブな開発には必須です。バグを見つけたときもいきなり修正するのではなく、再現させるテストを書いてから修正して、きちんと治っていることを確かめよう。効用としては素早いフィードバックが得られ、極めて低コストでリグレッションテストが実行出来て、デバッグ時間を大幅に削減でき、自信を持ってデプロイ出来る。ユーザーストーリーに対してテストケースを上げていき、それをテストしよう。

第13章はリファクタリング:技術的負債の返済です。開発が進むにつれ、不自然だったり重複したりするコードは生まれてしまうものだけど、その負債を返済するべくリファクタリングをしよう。それもこまめに継続的にだ。コードだけではなく、データやビルドファイル、設定ファイルやテストも対象だ。今後問題になるかもと思ったところは問題になるもんだ。後でやろうとすると大変だ。いますぐやろう。テストがあれば安心だ。

第14章はテスト駆動開発(TDD)です。レッドグリーンリファクタリングのリズムでやろう。テストを書いてからコードを書くんだ。すでにユーザーストーリーのテスト条件があるのだから、それをもとにテストを書けば良いのだ。

第15章は継続的インテグレーション:リリースに備えるです。ショータイムやリリースに備えて一度も結合していなかったり、デプロイしていなかったりしたとしたらどうだろうか。動くか動かないかわからないものを大量に結合して動かなかったら原因を調べるのに時間がかかる。それを避けるには日々結合して置く必要がある。継続的インテグレーションを実施していれば、日々、毎時のように結合されるわけだから、バグが入ったらすぐに今変更した箇所が原因だとわかるはずだ。つまりそういう事だ。作業単位は小さければ小さいほど良い。

目次