レガシーコード改善とテスト駆動の違い

皆様、レガシーコードとの戦いは順調ですか?(笑)
世にはびこるレガシーコードがある限り、我々の仕事は終わりません。
レガシーコード改善はTDDと少し違うのかなぁ?という自分の中の思いが生まれてきたので、ここに記しておきます。

TDD

テストコードの作成 (red)

イメージした仕様のテストを書く。

プロダクトコードの作成 (green)

テストが通るようにテストを書く

リファクタリング (red -> green -> red -> green…)

コードが綺麗になるように変えていく

レガシーコード改善

仕様の把握 ※特にインプットとアウトプットの洗い出し

単体テストのTDDの場合、小さな部分の動きをテストで固定していきます。所謂単体レベル。
しかし、レガシーコードは単体レベルで書き換えられるようになっていないことが多いです。
まずそのコードが依存している部分で、全体の仕様を洗い出すことが必要です。
特に抑えるべきは、インプットとアウトプットを洗い出しです。
おそらくこれが一番時間がかかる大変な作業です。

fixtureの作成

洗いだしたfixtureを作成していきます。fixtureというのは、データベースの値に限りません。ファイルを作成するのであれば、ファイルも、ブラウザに出力するのであれば、ブラウザへの出力の値もです。
本来であれば、1つの関数やクラスに閉じているはずの条件分岐を全体で洗い出す必要があります。

e2eテストの作成

エンドツーエンドのテストの作成。
input fixtureを使って、output状態が保証されることを示すテストを書きます。
私はこのタイミングでモックはできるだけ使わないようにしています。
モックをしてしまうと、モックを外したときに動作が変わってしまう恐れがあります。モックをしてテストが通ってしまうくらいなら、テストが落ちてくれる方が安心です。

e2eテスト結果から仕様漏れを洗い出す

e2eテストの結果はコードカバレッジとして出力します。しかしながら、単体レベルの動作でないわけです。ループ文が何十にも通ることで、カバレッジ率が高くでてしまったりすることもあるかと思います。コードカバレッジはあくまで参考程度にしかなりません。
コードカバレッジで明らかに漏れているインプットがあれば、仕様に追加していきます。

仕様漏れの追加 -> e2eテスト -> 仕様漏れの追加 -> テスト …

上記の作業を繰り返します。

 リファクタリング

e2eテストが落ちないことを確認しながら、小さな動作の塊にテストを書き、関数やクラスに切り出していきます
TDDのリファクタリングと変わりませんが、テストコードを増やしリファクタリングしていく。ここの中身はTDDと何も変わらない。
しかしながら、ここでバグや仕様漏れを大量に発見することになるはずです。その度に仕様を追加して、リファクタ前のコードでe2eテストをする必要があります。

レガシーコード改善とTDDの違い

レガシーコード改善の方がはるかに重いですが、基本的な考え方はどちらもTDDにもとづいているなぁと振り返りまとめなおして感じました。

レガシーコードとはテストがないコードのことを言うと言われています。
しかしながら、現実的な問題から全てのコードにテストがあるプロジェクトは少ないのではないでしょうか。
レガシーコードが問題になるのは、仕様が一見しにくいほど、複雑な処理を行っているにも関わらず、クラスや関数が適切な形で分割されていないからでしょう。
そして、レガシーコードの真の仕様はテストに記載されていないため、実機のみが知るという状況になっているかと思います。
その状況を改善するためには、仮説の仕様からテストを実装していき、その他の仕様を洗い出していく必要があるかと思います。これは大変な作業なので、可能な限り小さな単位のテスト(単体テスト)をTDDで行い。仕様変更に強いコードを作成していく必要があるのだと思います。
それではhappyコーディングライフを!


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


テスト駆動開発入門

一つのプロジェクトに複数言語が入り乱れる話

という流れを何度かみたことあるけど、 結局のところ適切な場所で適切な言語を決定した根拠を持っておかないとですね。

ワーキングメモリって流行ってるのんやね。

ワーキングメモリってのが流行ってる臭い。

ワーキングメモリを鍛えて脳の働きを強化するための4つの方法 http://namaraii.com/archives/4845

要は、人間の処理能力を高めることで、ミスを減らして確実に作業をするということ。

そして、これらは人によって個人差はあるものの、訓練によって鍛えることができるというのがわかってきたそうです。

まぁ、この本を読んだら、ワーキングメモリってのが、どういうことかとかが書いてあって、どのようにして鍛えるかということも書いてありました。

私が思うに、同時進行でいろいろな物事を考えて、瞬時に判断を下す能力は非常に必要だなと思います。

ただ、プログラマという仕事をしていると、何事も熟慮してプロセスを組み立てる癖がどうしてもついていて、

仕事の中で、このワーキングメモリを訓練するのに、どうすればいいかなぁってことを最近考えていました。

この本を読んで答えは出ました。

要は瞬間的に判断を求められることを仕事以外で日常に設けるということです。

日常的にいろいろなタスクが降り注いでくると思いますが、そのストレスフルな状況に少しだけでも、身を置くことをすれば改善の兆しもあるのかな

なんて思っています。

空雨傘の話 ー マッキンゼーとスタートアップの違い

今日は突然の雨でしたね。

僕も帰りがけに雨に振られました。

僕は家を出るときに雨が降っていない限り、傘を持っていかないので、いつも雨に振られます。

後先のことを考えられないバカな人間なのかもしらませんが、とある10人くらいのスタートアップ企業で働いていたとき、メンバー全員が僕と同じ行動をとっていたことに驚きました。

(しかも、雨が降るかもしれないと思ってても、傘を持ってこない人たちばかりでした)

空を見て、雨が降りそうだから、傘を持って出る

マッキンゼーではそうかも知れませんがスタートアップでは、そんな行動力では通用しません。

できるだけ早く出社することの方が大事なのです。笑


勝間和代のビジネス頭を創る7つのフレームワーク力 ビジネス思考法の基本と実践

大久保の代表入りについて思ったこと

大久保じゃなかったら細貝だったのかなぁ?
いや、わからないけど。

俺はこういうサプライズができる日本代表になったことが嬉しい。

ジーコ時代の巻とかさ、全然サプライズじゃなかったやん。

いや、フォワードもう一枚誰か欲しいよな。

ここで、中山!とか佐藤寿人!とかなってたら、サプライズやったけどさ。

でしかも、大久保ってただ調子いいだけじゃなくて、代表経験も豊富やん。

本当に前回大会の中村俊輔以上の精神的支柱になる確率あるじゃないですか。

しかもフォワードやし、スーパーサブとして、最適。

チーム力でどうこう行かなくなったときに、ロングボール追いかける仕事。

前線で声出すフォワード。いやー、ありですよ。ほんといいと思います。

ただ、大久保なしで全然戦えるのよね。

システムが使えるうちは大迫か柿谷か斎藤か前線で、やれるやん。

あー、これだけ戦力そろってるやん!

でも、コロンビア強そうやわー。

あー、勝ちたい!勝ちたい!

勝ちたいわ!!