レガシーコード体質改善 1 はじめます

長年、レガシーコードがほとんどの職場で働いています。

レガシーコードにはこれまで、散々、苦しんできましたし、書き続けてきました、最近になって、TDD、PFD、XDDPと言う武器を見つけました。

「レガシーコードと対峙する方法を考える」から半年 - 道草道

今、レガシーコードからの脱却を試みています。

仕事の内容は書けないですが、その記録を書いていこうと思います。

まず、自分の思うレガシーコードの定義は

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコードとは、単にテストのないコードである

テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更できる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当には分からない。

10年も同じ会社で働いていると、最初はちゃんとしたコードだっただろう無残なコードを散々見てきました。

どんな綺麗にコードを書いても、整備しなれば何年か後にはレガシーコードです。

それに、いくら綺麗なコードでも動かなければ、何の価値もない。

綺麗なコードと正しく動くかは別問題。

テストがないと、コードを綺麗にしたところで、正しく動いている確証が全くない。

自分が現場のレガシーコードにこだわる理由は、

１．ほとんど、自分も関わってきたコードだから

よくコードを読んでいて、誰やこのクソみないなコード書いたのは！と思っていると、

//Add 2009.10.12 by honobonotarou 

と、残念なコメントが見つかり、

自分かいな・・・・。って場面によく遭遇します。

別に若かりし自分だけが、ひどいコードを書いた訳ではなく、自分が引き継ぎた時点で、相当ひどいコードたったのですが、次の人には、もう少しましな状態にして託したいとの思いがあります。

２．どんなコードも一瞬でレガシーコードになるから

先ほど、テストのないコードはレガシーコードだと定義されていましたが、コードはメンテナンスしないと劣化します。

以前は、自分の職場だけレガシーコードなのかと思っていましたが、和田卓人さんのTDDBCなどに参加するうちに、自分の職場だけでないことが分かりました。

TDD のこころ @ Agile Samurai Base Camp from Takuto Wada

TDD のこころ @ Agile Samurai Base Camp

レガシーコードな職場から逃げればいい、などの意見もあるようです。

でも、プログラミングに関係する以上、レガシーコードから逃げられないのではないか？そんな気が最近してます。

どんなコードも気を抜けば、すぐにでもレガシーコードになる、そのたび毎に逃げるのかな？そんなことを思います。

正しい技術さえあれば、レガシーコードを制御可能な状態にもっていける。

最近、そういう気がしています。

単体テストで保護して、リファクタリングして、ドロドロのレガシーコードから本来の構造が姿を現す瞬間気持ちいい。

今回のプロジェクトの内容は、

既に存在する、ソフトをベースに新しいソフトを作ること。

既存のソフトの規模は、

• ファイル数：111個
• 総行数：27349行
• コード行数：17884行

これは昔の自分が書いたコードで、自分で言うのもなんですが、若干、残念なコードです。頑張って作った、現在も現役のコードですが、途中から設計が破たん気味です。あるクラスに責務が集中していて、行数が7323行もありました。。。。

この派生開発を、自分ではなくこのソフトの知識のない人に担当してもらいます。

開発の手順としては、

1. PFDでスケジュール見積もり
2. USDMで既存ソフトの要求仕様書を書く
3. 7323行ある巨大クラスから、単体テストを書きながら部品の取り出し（仕様化テスト）
4. USDMで改造仕様書を書く
5. TDDでコーディング

こんな感じです。

 今の段階は、

３．7323行ある巨大クラスから、単体テストを書きながら部品の取り出し（仕様化テストを書く）

今のところ、いい感じできている感触はあります。

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

「派生開発」を成功させるプロセス改善の技術と極意

プロジェクトマネジャーのためのプロセスデザイン入門