1997/02/12
コードベースに残された最古のコメント。
まぎれもないレガシープロジェクト。仕様書の類いは無い。
このプロジェクトにアサインしてから実施したいくつかのノウハウを紹介する。
リセットボタンを用意する
開発環境は以下。
- Windows10
- VisualStudio2015 （統合開発環境）
- TeamFoundationServer （ソース管理）
- Visual C++
TeamFoundationServer（以下、TFS）でバージョン管理をはじめるところがスタート地点。「なにも加えず、なにも除かれていない状態」を初期バージョンとしてチェックインする。
これ以降の変更でどんな過ちがあっても、リセットボタンを押せる。
「削除」からはじめよ
- 新機能の追加
- 機能の拡張
- デザインの改良
バックログに積まれたタスクはだいたいがAddかUpdateに分類されるが、大事なのはDelete。徹底して削る。
- 動作要件が更新されたことでサポート外の環境はできていないか
- 使用されていない機能（リソース）は無いか
ソリューション、プロジェクト、ファイル、コード、それぞれの単位で視点を変えながら削っていく。Delete作業時は、Add,Updateのことを考えてはいけない。
チェックインの粒度
小さいほどよい。
- 不要になったファイル A.cpp,A.h を削除
- B.cpp からinclude文を削除
というケースもあるので、影響範囲を考慮しつつ作業する。
2つのコンテキストを一度に作業するとリセットせざるを得ない状況がツラいので「粒度は小さく」が原則。
チェックイン前のリビルド
IDEにはコンパイル時間の短縮を目的としたプログラムオブジェクトのキャッシュ機能が備わっている。VisualStudioもこの機構のおかげで再コンパイル時間が短縮されるのだが、削除したヘッダーをincludeしているファイルが再コンパイルされずビルドがとおってしまうケースがある。
チェックイン前にはリビルドを実施し、キャッシュを無効化した状態でビルドが通ることを確認する。
リファクタリング
fst、rmv、filenm、memorierror、r
一時変数、メソッド、クラス、定数、名前空間。
配列を回したいだけならfor(int i=0;i<MAX;i++)でいい。使い捨て感があって逆にいい。
上述しているrは何を指していたか。
RECT r;
view1.GetClientRect(&r);
// view1の矩形に対する処理
view2.GetClientRect(&r);
// view2の矩形に対する処理
使いまわすから名無しのr？
当時は1997年、でもいまは2016年。これを見過ごしてはいけない。小さな一歩が大きな前進。肝に銘じよう。小さな負債はウシジマくん。これも銘じよう。
リファクタリングを一言で説明するなら、「挙動は変えず保守性、可読性を高める作業」
重要なのは、コードブロックが小さく、意味が理解できるのであればrでもOKだということ。長ったらしい名前をつけることがリファクタリングの本質ではない。
自分的リファクタリングの優先順位
- constの追加
- ネストの排除
- スコープの短縮
- 名前の最適化
constの追加は、もっとも間違いが小さく、得られる効果が大きいことを実感している。不変という記号は最高の可読性を担保してくれる。
仕様化テスト：コメントを書く時間でテストを書く
コメントを安易に書き込んではいけない。
コメントというものは、書き込んだ時点から古くなる一方、コードがアップデートされ整合性がとれなくてもエラーも吐かない、役立たずに成り果てる可能性があるからだ。私はこれを「緑の穀潰し」（コメントは緑色にハイライトされる）と呼び、忌み嫌っている。
じゃあどうする。テストプロジェクトをソリューションに追加した。仕様が明確になっていないファイルを放り込んでテストで囲んだ。ファイル間の依存が強すぎてプロジェクトに追加するのが困難なケースもあった。そんなときはコードの断片だけを切り取ってテストで囲んだ。やらないよりはやったほうがマシ。その断片だけでも動作が明確になったのなら++。
仕様化テストのいいところは、プロダクションコードと直結していることだ。クラスの振る舞いが変わればテストが赤くなる。クラスの不具合か、テストの修正が必要なのか。小さな検問をパスするたびにプロダクションコードは洗練されていく。素晴らしい！
動いているコードに手を加えることに対する拒否感に対するマインド
私はしばしば、「動いているものを変えないように」と諭されることがあります。もしかすると無鉄砲に無秩序に--ときには破壊的に！--変化をもたらしていた時期もあったかもしれません。
でもこのプログラムを一番よく理解しているのは誰であるべきでしょうか。
将来、コードを保守していく自分たちです。
そこには「祈り」や「推測」は持ち込んではいけない。「責任感」と「当事者意識」をもって取り組むことが大事なのではと思います。
いくつかのレガシープロジェクトと対峙た経験から得た最大のものは「やりきる覚悟」でした。「やりきる覚悟」さえあれば、失敗はもはや成功と同意。みなさん、本日もお疲れ様です。