分別のある行動 – プログラマが知るべき97のこと

Act-with-Prudence

この記事は、「プログラマが知るべき97のこと」について、英語と日本語訳を記載したものです。

プログラマが知るべき97のこと(オライリー・ジャパン、2010年)
Kevlin Henney(編)、和田 卓人(監修)、夏目 大(訳)
各エッセイはCC-by-3.0-USによってライセンスされています。


Whatever you undertake, act with prudence and consider the consequences.

何をするにせよ、常に分別を忘れてはならない。自分のしたことがどういう結果を生むか、よく考えるのだ。

Anon – 作者不明

No matter how comfortable a schedule looks at the beginning of an iteration, you can’t avoid being under pressure some of the time.

どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。

If you find yourself having to choose between “doing it right” and “doing it quick” it is often appealing to “do it quick” on the understanding that you’ll come back and fix it later.

そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者の方が魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。

When you make this promise to yourself, your team, and your customer, you mean it.

プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。

But all too often the next iteration brings new problems and you become focused on them.

次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結局、修正が不可能になってしまうことも多いのです。

This sort of deferred work is known as technical debt and it is not your friend.

このように先送りされていく修正作業のことを技術的負債(Technical debt)などと呼ぶことがあります。当然、好ましいものではありません。

Specifically, Martin Fowler calls this deliberate technical debt in his taxonomy of technical debt, which should not be confused with inadvertent technical debt.

Martin Fowler は特に、いま述べたような技術的負債のことを故意の技術的負債と呼んでおり、故意でない、不注意から発生する技術的負債とは区別すべきであると言っています。

Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest on it until it is fully paid off.

技術的負債は、その名のとおり、借金のようなものです。短期的には利益になりますが、完済するまで利息を払い続けなくてはなりません。

Shortcuts in the code make it harder to add features or refactor your code.

早くできるからと手を抜いてコードを書くと、機能追加やコードのリファクタリングが難しくなります。

They are breeding grounds for defects and brittle test cases.

新たな不具合を生む温床となり、テストケースの価値を損なう原因にもなります。

The longer you leave it, the worse it gets.

長く放置するほど害は大きくなるでしょう。

By the time you get around to undertaking the original fix there may be a whole stack of not-quite-right design choices layered on top of the original problem making the code much harder to refactor and correct.

ようやく元々の問題を解決したら、その問題が原因で生まれた新たな問題が山積みになっていた、ということになりかねません。問題が放置されていたために、正しい設計の選択ができないこともあります。リファクタリングや修正の難しいコードを仕方なく次々に書いてしまうこともあるでしょう。

In fact, it is often only when things have got so bad that you must fix it, that you actually do go back to fix it.

実のところ、事態が極端に悪化してしまい、もう他にどうすることもできない状況に陥ってはじめて、元々の問題の修正に取り組み始める、そんなことが多いのです。

And by then it is often so hard to fix that you really can’t afford the time or the risk.

その頃には、修正は極めて難しくなっています。修正しようにも膨大な時間がかかるため、あるいはリスクが高すぎるため、手の打ちようがないこともよくあります。

There are times when you must incur technical debt to meet a deadline or implement a thin slice of a feature.

納期に間に合わせるため、ほんの少しの機能追加のため、どうしても技術的負債が生じてしまう、ということがあります。

Try not to be in this position, but if the situation absolutely demands it, then go ahead.

そうならないように努力はしなくてはいけないのですが、状況によって、どうしてもそうせざるを得ないことがあります。その場合は、あえて技術的負債を抱える道をとる以外ないでしょう。

But (and this is a big BUT) you must track technical debt and pay it back quickly or things go rapidly downhill.

しかし(ここからが何より大事です)、技術的負債の存在は常に忘れないようにし、できるだけ早く返済すべきです。さもなければ事態は急速に悪化していきます。

As soon as you make the decision to compromise, write a task card or log it in your issue tracking system to ensure that it does not get forgotten.

やむなく妥協をする決断を下した時は、すぐにタスクカードに書く、問題管理システムへの登録をする、などの対処をし、技術的負債の存在が忘れられないようにしておくべきでしょう。

If you schedule repayment of the debt in the next iteration, the cost will be minimal.

次のイテレーションでの返済をスケジュールに組み込むことができれば、コストは最小限に抑えられます。

Leaving the debt unpaid will accrue interest and that interest should be tracked to make the cost visible.

負債を放置すれば、利息が発生します。この利息を常にトラッキングし、コストを明確にする必要があります。

This will emphasize the effect on business value of the project’s technical debt and enables appropriate prioritization of the repayment.

そうすれば、技術的負債が事業価値にどれほど大きな影響を及ぼすかが意識され、返済のための作業の優先順位が自然に上がることになるはずです。

The choice of how to calculate and track the interest will depend on the particular project, but track it you must.

利息の計算、トラッキングをどうするかは、プロジェクトごとに違うでしょうが、トラッキングをしなくてはならない、ということだけは、どのプロジェクトでも同じです。

Pay off technical debt as soon as possible. It would be imprudent to do otherwise.

技術的負債はできるだけ早く返済する。分別のある人ならそうするはずです。

By Seb Rose

タイトルとURLをコピーしました