https://martinfowler.com/bliki/FrequencyReducesDifficulty.html

私が気に入っている引用の一つに「もしそれが痛みを伴うのであれば、さらに頻繁にそれを行え」という引用がある。 この言葉は、表面的には馬鹿げたことに見えるという幸せな性質も持っているが、深く探れば価値のあることがわかる。 このことを説明するための例示できる文脈は、統合だ。 ほとんどのプログラマーは、自分の仕事を他の人と統合することは苛立たしくてつらい経験であることを早い段階で学ぶ。 そのため、自然な人間の反応として、できるだけ統合を先延ばしにしようとする。

指数関数

上記グラフのように、その行動を起こすまでにかかる時間と、その行動に伴う痛みに指数関数的な関係がある場合、その行動をより頻繁に行うと、痛みを大幅に軽減できる。 そして、これが継続的インテグレーションで起こることだ。毎日統合することで、統合の痛みはほとんどなくなる。 ただ、それでもまだ痛みがあったため、更に更に頻繁に統合を行ったら、今やもう痛みはなくなった。

痛みの伴うことを頻繁に行うという考え方は、アジャイルの考え方の中で多く現れる。 テスト、リファクタリング、データベース移行、顧客との会話、計画、リリース、など様々な活動が頻繁に行われる。

何がこのような効果を引き起こしているのか。私は主要な3つ理由があると考えている。

まず、これらのタスクのほとんどは、実行する量が増えるにつれてはるかに困難になるが、小さな塊に分割すると容易になる。データベースの移行は、この良い例である。複数のテーブルを含む大規模なデータベース移行することは難しく、エラーが発生しやすくなる。しかし、一度に1つの小さな変更を加えると、それぞれを正しくするのがはるかに容易になる。さらに、小さな移行を簡単にシーケンスにまとめることができる。したがって、大規模な移行を一連の小さな移行に分解すると、すべての処理がはるかに簡単になる。これがデータベースのリファクタリングの本質である。

2番目の理由はフィードバックである。アジャイルの考え方の多くは、フィードバックループを設定して、より迅速に学習できるようにするためのものである。 フィードバックはエクストリームプログラミングの明確な価値であり、定義されたプロセス制御と経験的なプロセス制御の違いに関するKenSchwaberの議論の中心だった。ソフトウェア開発のような複雑なプロセスでは、自分がどこにいるかを頻繁にチェックし、コースを修正する必要がある。 これを行うためには、フィードバックループを増やし、フィードバックを受け取る頻度を増やして、より迅速に適応できるようにするあらゆる機会を探す必要がある。

3番目の理由は練習である。どんな活動でも、私たちはそれをより頻繁に行うにつれて上達する。 良い手術を受けるために大事なことは、頻繁に手術を行う外科医を見つけることだとよく言われる。 練習することで、プロセスのねじれを解消し、何かがうまくいかない兆候について知ることができるようになる。 また、自分がしていることを振り返ると、練習を改善する方法も思いつく。 ソフトウェアには、自動化の可能性もある。ある作業を数回実行すると、それを自動化する方法がわかりやすくなり、自動化する意欲も高まる。自動化は、速度を上げてエラーの可能性を減らすことができるため、特に役に立つ。

したがって、痛みを伴う活動に直面したときはいつでも、これらの力が適用されるかどうかを自問して欲しい。 もしそうなら、頻度を増やすことはあなたをより効果的にし、ストレスの原因を取り除くことができる。