--- # レガシーコードについて考えてみた #wewlc_jp URL: https://agile-monster.com/blog/legacy-code/ Published: 2014-09-27 --- [レガシーコード改善勉強会 in東京 - パスマーケット](http://passmarket.yahoo.co.jp/event/show/detail/01pitgwzj67m.html) に参加しています、なう。 勉強会出ててくる内容（キーワード）や雰囲気はハッシュタグから追えると思いますのでぜひ！ - [Twitter / Search - #wewlc_jp](https://twitter.com/hashtag/wewlc_jp) 参加レポートではなく、せっかくなので勉強会のテーマの “レガシーコード” について個人的な想いをつらつら書いてみます。 ### レガシーコードってなあに？ - レガシーコードとはテストのないコードである というわかりやすい定義もありますが、 - 仕様がわからないコード - 意図がわからないコード - 読めないコード といった主観的なイメージもよく聞きます。 定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。 【余談】このあたり読むと面白い！ - [技術的負債 - Wikipedia](http://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5) - [技術的負債 - Qiita](http://qiita.com/erukiti/items/9cc7850250268582dde7) ### レガシーコードとの遭遇 今までの自分の経験では、コードが存在するところには（程度の違いはあるけど）必ずレガシーコードが存在していました。 仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。 ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、**レガシーコードとどう向き合っていくか**はエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。 ### よくあるレガシーコード 今までレガシーだなーと思ったコードを思い出してみました。 - メソッドでやりたいことがわからない - インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい - メソッドが大きすぎてテストコード書こうにも複雑すぎる - AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない - 変更部分にしか注意がまわっていない書き方をしている - 歴史を感じるくらい人によって書き方がバラバラ - そもそもシステムやテストの設計方針がない - とにかくわけがわからない 思い返してみるとこれらの共通点は、 - テストコードが存在しない でした。 もちろんテストコードがあればいいってわけじゃないけれど統計的に！ ### レガシーコードができそうなにおい 今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。 - メソッドが長い - インデントが深い - 条件文が複雑 - メソッドからreturnするパターンが多い これらを見つけた時に聞いてること。 - メソッドが長い →「このメソッドの目的ってなに？」 →「このメソッドテスト書いててつらくなかった？」 - インデントが深い →「ここ通るときの条件を教えて！」 - 条件文が複雑 →「この条件文を文章で説明してほしいなー」 - メソッドからreturnするパターンが多い →「このメソッドのreturnのパターンを教えて！」 コードを書かない時にもレガシーなにおいを感じるタイミングはあります。 - 説明が不安そう - 仕様理解があいまい - タスク自体のDoneの定義があいまい - （項目・コード問わず）テストが書けてない - 本人がぱつってる こんなときはあやしいですよね。 ### レガシーコードとどう向き合ってきたか もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。 でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。 でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。 だから、 ***状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう*** ってことを考えるようになりました。 ### 今後レガシーコードとどう向き合っていくか 今後以下の2つのアプローチを考えてます。 - やってきたことをアウトプットする - 知識をインプットする #### 1. やってきたことをアウトプットする レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。 自分は本能で動くタイプなので、やってみたあとから、 「あのときやったことに名前・方法論があったんだ」 と知識がついてくることが多いです。 それはそれでいいと思うんですが、やってきたことを[形式](http://d.hatena.ne.jp/keyword/%B7%C1%BC%B0%C3%CE)知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。 #### 2. 知識をインプットする アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。 考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。