読者です 読者をやめる 読者になる 読者になる

冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

TDDやってみてコメントが減った話

この記事はTDD Advent Calendar jp: 2011 : ATNDのためのエントリです。前日は @masaru_b_cl さんのDartUnitができるまで | be freeです。真面目でもなく緩くもない中途半端な記事です。ただ、TDDを練習していく中で、個人的に面白い気づきだったので、少し取り上げてみたいと思います。

注意事項
個人の経験感想に基づくものです。あなたがそもそも同じようなコードを書いてきたのでなければこの考察はなんのお役にもたてません。ご了承ください。

コメント、書いてますか?

TDD以前、私が書いていたソースは以下のような感じでした。

private String hogeMethod(String param) {
// 初期処理
initLogic();

// 主処理
mainLogic();

// 後処理
endLogic();
}

オーバーでも何でもないです。ほんとにこういうコメントの残し方をしていました。コメントの量は比較的多いかと思います。その当時の書き方は以下の通りです。

  1. メソッドインターフェイスメソッド名を決める
  2. 処理手順をコメントで書く(未実装分についてはTODOにしておくことも)
  3. コメント部分で簡単そうな箇所から実装開始
  4. 確認したい所は動かしてみる
  5. メソッドが長くなってきたら分割する

なるべく実装している最中に他のドキュメントを参照しなくて良いようにという自分なりの工夫です。後からコメントを消す場合もありますが、ほとんどのコメントはソースの中に残っています。

現状のコメント量

今年公開したエントリの中で、TDDの練習をしながら書いたソースをふりかえってみます。

private String replaceWikiMarkupString(String text) {
String retText = text;

Matcher m = HEADER_PATTERN.matcher(text);
if(m.find()) {
String start = m.group(1);
String end = m.group(2);

int level = start.length();
if(level <= HEADER_MAX_NUMBER && level == end.length()) {
// マッチした=の数が同じなら変換する
retText = TextMarkupConverter.generateHtmlHeaderString(start, "H" + level, text);
}
}

for(TagPattern tagPattern : patternList) {
m = tagPattern.matcher.matcher(retText);
if(m.find()) {
retText = TextMarkupConverter.generateHtmlString(m.group(1), m.group(2), tagPattern.tagName, retText);
}
}

if(text.equals(retText)) {
return retText;
} else {
return replaceWikiMarkupString(retText);
}
}

ご覧の通り、コメントはメソッドヘッダ位しかありません。必要なレベルのソースでもないという言い方もできると思いますが。

コメントはなんのため?

本来の目的は可読性のためかと思いますが、上述の通り、私の場合は事前設計のドキュメントとしてコメントを書いていたことがわかります。
この書き方だと先のソースのようにコメントの量が多くなりがちになってしまうことです。ある程度大きな流れで記述はするのですが、リファクタリングした結果として1ステップ1コメントという事態もあり得ます。こうやって残っていくコメントは明らかに無駄で、ソースの可読性を下げてしまいます。
残ったコメントの管理をきちんとできれば良いのですが、時間が無ければ対応がを後回しにしてしまいます。

まとめ

TDDでは事前にtodoリストを作成して、そのリストを元にテストコードを書き、それから実装に移ります。私がTDD以前にコメントで書いていたコーディングに対するガイドと同じ役割をtodoリストとコードが担っていると想像できます。
ということは、TDDで行っていることが、今までのプログラミング手順と目的ベースでマッピングしていたということでしょう。先述の通り、私はコメントを解決しなければならない問題の細分化と実装のためのガイドラインに使っていました。TDDでは、todoリストで細分化を行い、テストコードを先に書くことで実装のためのガイドラインを作ります。つまり、今までのようなコメントは必要なくなったということだと思います。
ニッチな話題すぎて、他の皆さんに当てはまるかどうかはわかりませんが、個人的に面白い発見だったので取り上げてみることにしました。まあ、とりあえず皆TDDやってみるといいよ。tddbc岡山も開催に向けて動いてるんで、よろしくお願いします、ということで。

12/18は、id:megascus さんの id:megascus:20111217:1324135865 「アジャイルにTDDしようとしてペアプロして失敗した話」です。