# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
6．リファクタリングの際に注意すべきこと ラジット・アタパトゥー (Rajith Attapattu)
私たちプログラマには必ず，
既存のコードの「リファクタリング」が
必要になる時がやってきます．
ただ，リファクタリングをする前に
いくつか考えてほしいことがあります．
次に書くようなことに注意すれば，
自分も含め，開発に関わるすべての人の時間と労力を
大幅に節約できるでしょう．
・リファクタリングをするにあたって始めにすべきことは，
既存のコードベースと，
そのコードに対して書かれたテストコードの洗い直しです．
具体的には，
現状での良い点，悪い点，強み，弱みを1つずつ確認していきます．
これは，良い点，強みを生かしながら，
悪い点，弱みを克服することにつながります．
既存のシステムに手を加えれば，
必ず元より良いものになるはずと考えがちですが，
実は何も良くならないこともあるし，
元よりも悪くなることもあり得るのです．
既存のコード，テストを
十分に検証しなければ，
過去の失敗に学ぶことができません．
・すべてをゼロから書き直したい衝動に駆られることもありますが，
その誘惑に打ち勝たなければなりません．
既存のコードをできる限り活かすべきです．
いかなる醜悪なコードであっても，
そのコードはテストやレビューを通っているものなのです．
既存のコード，
特に，既にリリースされたシステムのコードを
すべて破棄するというのは，
それまでの何ヶ月（何年）という時間を捨ててしまうことを意味します．
大変な作業を経て，
曲りなりにも形にしてきたコードです．
その過程では無数に発生した問題の解決策を講じ，
数えきれない程のバク修正をしてきたのでしょう．
仮にコードを新たにゼロから書きなおしたとすると，
同じようなことをまた繰り返すことになりますし，
既存のコードでは発見・修正できたバグを，
今度は見逃してしまうかもしれません．
これでは時間の労力の無駄だし，
過去の作業で得た知識も無駄になってしまいます．
・一度に大幅な変更を加えるよりも，
少しずつの変更(インクリメンタルな変更)を数多くすべきです．
インクリメンタルな変更ならば，
テストからフィードバックを得ることで，
変更がシステムへ及ぼす影響を容易に知ることができます．
変更を加えたら，テストが100個以上も失敗する，
というのは，非常に辛いものです．
苛立ちと焦りから，
誤った意思決定をしてしまう恐れもあります．
失敗するテストが2つや3つならば，
冷静に確実な対処ができるでしょう．
・各イテレーションの最後には，
既存のテストが通るのか必ず確認します．
既存のテストだけでは，
変更を加えた部分をカバーするのに十分でない場合には，
新たにテストを追加します．
十分な検討もせずに，古いコードに対応するテストを破棄してはいけません．
古いテストの中には，一見すると，
変更後のコードには合わないのでは，
と思えるものも確かにあります．
しかし，破棄する前に，
そもそもなぜそのテストが存在したのかを
深く掘り下げて検討する必要があります．
・個人の好みやエゴを入れてはいけません．
壊れてもいないものを直すのは，無意味です．
コードの書き方の流儀や構造が自分の好みに合わない，
というのは，
修正の十分な理由にはなりません．
自分の方が前任者よりも能力があるのだから，
良いコードが書けるはず，
というのも十分な理由にはなりません．
・新技術を使いたい，というのも
それだけでは，リファクタリングの十分な理由にはなりません．
最悪なのは，
「今流行の新技術が取り入れられていない」
「時代遅れである」
というだけの理由でリファクタリングをする，ということです．
新しい言語やフレームワークを使えば，
今と同じ事がもっとうまくやれるだろう，
というような単純な考えで，リファクタリングをするべきではありません．
コストの分析を行い，
新しい言語やフレームワークの導入により，
機能，保守性，生産性が
著しく向上するという結論が得られた場合を除き，
現状の技術のままにしておくのが，得策です．
・人間は必ずミスをする，ということを常に忘れないようにしましょう．
コードを書き換えても
コードが元より良くなるとは限りません．
何かをミスして，かえって質が下がることもあります．
実際，私は何度かコードの書き換えに失敗しています．
情けないことではありますが，
それが人間というものなのです．
■著者データ
[ラジット・アタパトゥー (Rajith Attapattu)]
Red hat, MRGteamのシニアソフトエンジニア．
オープンソースの信奉者であり，
Apache Qpid, Apache Synapse, Apache Tuscany, Apache Axis2など，
いくつものApacheプロジェクトのコントリビュータでもある．
最近は，スケーラブルで信頼性の高い
メッセージングミドルウェアの構築に重点的に取り組んでいる．
またAMQP(Advanced Message Queuing Protocol)
ワーキンググループのメンバーでもある．
論文などの執筆や，ApacheCon, Colorad Software Summit, Toronto JUGなど
のカンファレンス，ユーザグループでの講演も行う．
研究の対象としているのは，スケーラビリティの改善，
分散システムの可用性の向上である．
休日は，絵を描いたり，
クリケットをするなどして楽しんでいる．
ブログも参照のこと．
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
