この記事は、「プログラマが知るべき97のこと」について、英語と日本語訳を記載したものです。
プログラマが知るべき97のこと(オライリー・ジャパン、2010年)
Kevlin Henney(編)、和田 卓人(監修)、夏目 大(訳)
各エッセイはCC-by-3.0-USによってライセンスされています。
At some point every programmer will need to refactor existing code.
私達プログラマには必ず、既存のコードの「リファクタリング」が必要になる時がやってきます。
But before you do so please think about the following, as this could save you and others a great deal of time (and pain):
ただ、リファクタリングをする前にいくつか考えてほしいことがあります。次に書くようなことに注意すれば、自分を含め、開発に関わる全ての人の時間と労力を大幅に節約できるでしょう。
The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code.
リファクタリングするにあたってはじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。
This will help you understand the strengths and weaknesses of the code as it currently stands, so you can ensure that you retain the strong points while avoiding the mistakes.
具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。
We all think we can do better than the existing system… until we end up with something no better — or even worse — than the previous incarnation because we failed to learn from the existing system’s mistakes.
既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。既存のコード、テストを十分に検証しなければ、過去の失敗に学ぶことが出来ません。
Avoid the temptation to rewrite everything.
すべてをゼロから書き直したい衝動に駆られることもありますが、その誘惑に打ち克たなければなりません。
It is best to reuse as much code as possible.
既存のコードをできるかぎり活かすべきです。
No matter how ugly the code is, it has already been tested, reviewed, etc.
いかに醜悪なコードであっても、そのコードはテストやレビューを通っているものなのです。
Throwing away the old code — especially if it was in production — means that you are throwing away months (or years) of tested, battle-hardened code that may have had certain workarounds and bug fixes you aren’t aware of.
既存のコード(特に、すでにリリースされていたシステムのコード)をすべて破棄するというのは、それまでの何ヶ月(何年)という時間を捨ててしまうということを意味します。大変な作業を経て、曲がりなりにも形にしてきたコードです。その過程では無数に発生した問題の回避策を講じ、数えきれないほどのバグ修正もしてきたでしょう。
If you don’t take this into account, the new code you write may end up showing the same mysterious bugs that were fixed in the old code.
仮にコードを新たにゼロから書き直したとすると、同じようなことをまた繰り返すことになりますし、既存のコードでは発見／修正できたバグを、今度は見逃してしまうかもしれません。
This will waste a lot of time, effort, and knowledge gained over the years.
これでは時間と労力の無駄だし、過去の作業で得た知識も無駄になってしまいます。
Many incremental changes are better than one massive change.
一度に大幅な変更を加えるよりも、少しずつの変更(インクリメンタルな変更)を数多くするべきです。
Incremental changes allows you to gauge the impact on the system more easily through feedback, such as from tests.
インクリメンタルな変更ならば、テストからのフィードバックを得ることで、変更がシステムへ及ぼす影響を容易に知ることが出来ます。
It is no fun to see a hundred test failures after you make a change.
変更を加えたらテストが百個以上も失敗する、というのは非常につらいものです。
This can lead to frustration and pressure that can in turn result in bad decisions.
いらだちと焦りから、誤った意思決定をしてしまう恐れもあります。
A couple of test failures is easy to deal with and provides a more manageable approach.
失敗するテストが2つや3つならば、冷静に確実な対処ができるでしょう。
After each iteration, it is important to ensure that the existing tests pass.
各イテレーションの最後には、既存のテストが通るか必ず確認します。
Add new tests if the existing tests are not sufficient to cover the changes you made.
既存のテストだけでは、変更を加えた部分をカバーするのに充分でない場合は、新たにテストを追加します。
Do not throw away the tests from the old code without due consideration.
十分な検討もせずに、古いコードに対応するテストを破棄してはいけません。
On the surface some of these tests may not appear to be applicable to your new design, but it would be well worth the effort to dig deep down into the reasons why this particular test was added.
古いテストの中には、一見すると、変更後のコードには合わないのでは、と思えるものも確かにあります。しかし破棄する前に、そもそもなぜそのテストが存在したのかを深く掘り下げて検討する必要があります。
Personal preferences and ego shouldn’t get in the way.
個人の好みやエゴを入れてはいけません。
If something isn’t broken, why fix it?
壊れてもいないものを直すのは無意味です。
That the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring.
コードの書き方の流儀や構造が自分の好みに合わないというのは、修正の十分な理由にはなりません。
Thinking you could do a better job than the previous programmer is not a valid reason either.
自分のほうが前任者よりも能力があるのだから良いコードが書けるはず、というのも十分な理由にはなりません。
New technology is insufficient reason to refactor.
新技術を使いたい、というのもそれだけではリファクタリングの十分な理由にはなりません。
One of the worst reasons to refactor is because the current code is way behind all the cool technology we have today, and we believe that a new language or framework can do things a lot more elegantly.
最悪なのは「今流行の新技術が取り入れられていない」「時代遅れである」というだけのりゆうでリファクタリングをする、ということです。新しい言語やフレームワークを使えば、今と同じことがもっとうまくやれるだろう、というような単純な考えでリファクタリングをすべきではありません。
Unless a cost–benefit analysis shows that a new language or framework will result in significant improvements in functionality, maintainability, or productivity, it is best to leave it as it is.
コストの分析を行い、新しい言語やフレームワークの導入により、機能、保守性、生産性が著しく向上するという結論が得られた場合を除き、現状の技術のままにしておくのが得策です。
Remember that humans make mistakes.
人間は必ずミスをする、ということを常に忘れないようにしましょう。
Restructuring will not always guarantee that the new code will be better — or even as good as — the previous attempt.
コードを書き換えてもコードがもとより良くなるとは限りません。何かミスをして、かえって質が下がることもありえます。
I have seen and been a part of several failed restructuring attempts.
実際、私は何度かコードの書き換えに失敗しています。
It wasn’t pretty, but it was human.
情けないことではありますが、それが人間というものです。
by Rajith Attapattu
