レガシーコードを語ろう

第1回 レガシーコード前夜

この記事を読むのに必要な時間:およそ 5 分

はじめに

「レガシーコード」――この言葉を聞いて何を思い浮かべますか?

もしかしたら,COBOLで書かれたコード,Windows NT 4.0用のコード,書いた人がわからなくなってしまったコードなどが思い浮かぶかもしれません。

しかし,このレガシーコードをメインテーマとして正面から扱っている書籍『Working Effectively with Legacy Code』WEwLC ※1では,レガシーコードについて異なった見解を示しています。そう,「明日自分の書くコードもレガシーコードになるかもしれない」というWEwLCが発するメッセージは,私たちに切実に迫ってくるのではないでしょうか。

この連載では,WEwLC読書会の有志が,WEwLCが語りかけるものや,現実の課題への活かし方などを対談形式で紹介していきます。この本が発するメッセージについては連載の中でおいおい明らかにしていきたいと思います。まず初回となる今回は,WEwLCに出会う前に各人が抱えていた課題や WEwLCとの出会いなどについて語っていきます。これにより,有志の面々がWEwLCによって変わる前に直面していた課題を明確にしていきたいと思います。

※1)
最近,『レガシーコード改善ガイド』というタイトルで日本語訳が出版された。

実プロジェクトで遭遇したエンバグと引き継ぎの問題(中谷)

テストの必要性はわかっていたけれど…

川西:第1回目のテーマは「レガシーコード前夜」ということで,WEwLCに出会う前に遭遇していた課題や,WEwLCとの出会いなどについてお聞きしたいと思います。 WEwLCに出会う前に,テストとか品質といったものに対してどういう課題を抱えていたかとか,うまく取り組めていなかった部分とか,もともとどういう印象を持っていたかとか,そういう事柄について語り合えれば良いと思っています。

ではまず中谷さんから,もともと抱えられていた課題はありましたか。

中谷:まずはユニットテストですかね。必要性はとても強く認識できていたんですが,なかなか習慣づけられない。

テストがないとバグを作り込んでしまうというのは感じていて,後で痛い目に遭うので書かないといけない,書けば楽をできるかもしれない,そういうのは頭ではわかっていました。ただ,いざ開発が始まると,納期などいろいろ言い訳してしまうんですよね。

すでにテストを書いていないコードベースが大量にあるのに,「ここだけテストを書いてもな」という意識が働いてしまったり,それでも「やっぱり必要だから」と思って,実際に新しく開発したコードにテスト書いてみたりしても,いまいちピンとこない。

読書会でもよく論点として挙がっていましたが,「ここにテストを書くのでいいのか」とか,「privateメソッドのテストできない」などという問題がありますよね。それから,テストの項目についてもどこまで網羅性を求めていくのか─なにしろ,すでにテストを書いてないコードが大量にあるのでカバレッジとかあまり意味ないんですよね。指標がない。

かといって,そのコードを外に見せて「どうすればいいですか」なんて相談できるわけもなく,「理屈では必要であることは大変強く認識しているけど,でもどうしたらいいのかさっぱりわからない」という状況でした。

川西:この辺りは難しい問題ですよね。みなさん共通の悩みだと思います。

和田:テストを書かないとレガシーコード増える一方ですもんね。もちろん,WEwLCを読む前の「レガシーコード」という言葉の意味づけは違っていたかもしれませんが。

中谷:WEwLCを読む前は,テストがないコードを呼ぶ名前がなかったので議論のしようもなかったですね。テストを書いた方がいいのはわかるけど,テストを書かないのが悪いことだとはわからない。

川西:書かないことで何か具体的な問題があったのでしょうか?

中谷:やっぱりエンバグですね。特に複数人で開発していると,各メソッドがどういう仕様なのか必ずしも細かいところまで理解しているとは限らないので「動作確認」する場合でもいろいろ抜けてしまって。

高橋:自分が変更したものの影響範囲も,「このあたりのはず」くらいの当たりを付けて,作業を始めちゃうこともありますからね。

残すもの,残されるもの―引継ぎの問題

中谷:それから,デブセン※2にも出てましたが,転職することになった時に,引き継ぎでどれだけのものを残せばいいのかわからないという問題が出てきました。

実際,それまでいくつものプロジェクトを引き継いできた経験では,どれだけドキュメントを残してもらっても,結局読むのはソースでしたね。逆に残す側になった時に,そのころには大量のコードのうち自分が書いた量が一番多くなっていて,「そのドキュメントを書くってうわあどうしよう」となりました。その頃は,まだテストがドキュメントになるという認識もなく,できるだけのことはしたつもりですが,やっぱりきっと「あんまり役にたたないなあ」とか思われてるのかもなあ,と申し訳なく感じていました。

高橋:そういう前夜だった中谷さんがこの本に出会って,最初に目を通した時にどう思ったかを聞いてみたいですね。

中谷:出会ったきっかけは,実は「RESTful Web サービス」の読書会です。

高橋さんの※3RESTful読書会に関するブログの記事和田さんのWEwLCに関する記事へのリンクが張ってありました。和田さんの記事はそれ以前に見ていたんですが,そのときは詳細についてはスルーしていました。ただ,高橋さんのリンクをきっかけにもう一度読み直してみたらWEwLCという本が気になって,実際に目次を見て「自分のことが書いてある!」「これは読まねばなるまい」と感じたのが読書会参加の動機です。

高橋:やっぱり目次って重要だなぁ。

※2)
デベロッパーズサミット2009で発表したスライド(Developers' 川柳)
※3)
著者の高橋は,RESTful勉強会を主催している。

著者プロフィール

川西俊之(かわにしとしゆき)

(株)情報工房で通信関係のソフトウェア開発に携わる。ソフトウェアテストに興味を持ち、テスト管理システムTestLinkや,C言語用BDDフレームワークCSpecなどでオープンソースプロジェクトに関わっている。


大中浩行(おおなかひろゆき)

(株)エルテックスで業務システム・ECサイト構築に従事する傍ら,Working Effectively With Legacy Code 読書会,Seasarプロジェクトコミッタ,Jiemamy Project等でOSS/コミュニティ活動に携わっている。


中谷秀洋(なかたにしゅうよう)

サイボウズ・ラボ(株)にてWebアプリの連携や自然言語処理を中心に研究開発を行いながら,英単語タイピングゲームiVocaをサービス提供している。参加した懇親会はいつもなぜかRESTとExcelの話になる。


高橋邦彦(たかはしくにひこ)

新しいフレームワークを作ろうとしていろいろ調べているうちにRESTとTDDの魅力に取り付かれて今に至る。業務ではPHPを用いてWebアプリケーション開発を行っている。


和田卓人(わだたくと)

タワーズ・クエスト(株) プログラマ 兼 取締役社長。2003年頃XPやテスト駆動開発に目覚める。後年「チームかくたに」のコーチとしてXPやTDDをチームで行った経験をもとに,『WEB+DB PRESS Vol.35』と『WEB+DB PRESS Vol.37』でTDDやリファクタリングについての巻頭特集を執筆。現在はSeasar.orgのコミッタとしての活動もしつつ,社長として会社を回している。

バックナンバー

レガシーコードを語ろう

  • 第1回 レガシーコード前夜

コメント

コメントの記入