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

JavaScriptをがんばるブログ

×技術ブログ ○技術日記

レガシーコードをPullRequest → コードレビューする意味ってあるのかな

git ソフトウェア開発

PullRequestに表示されているDiff以外の部分を見ないとどう動いているのか理解出来ず良し悪しを判断出来ないし、
既によくない部分が大量にある状況でコードレベルの是非を指摘する気にならない。

コードレベルで改善が難しいプロジェクトは素直に以下のフローで良いんじゃないのかな。

  • 修正依頼 → 依頼者に動作確認 → OK → マージ

変更に対する観点が仕様通り動くか?しかないのだから。

僕程度のスキルでは改善案なんて浮かぶはずも無く無力感を感じてしまうし、
最初からコードレビューなんか期待していなくて動作確認が主のPullRequestも多い。(動作確認は依頼者にやって貰うべきだと思う)

「クソコードの保守」に見切りを付けて転職する人の話も割と聞くし、
人材の流出がレガシーコードが抱える大きなリスクなのかもしれない。

人に言葉で伝えるのは難しい、手に負えない事も分かっているとなれば、そりゃあ辞めようってなりますよね。

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

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

ソフトウェアにしっかりとテストを書いた結果、どのような心境に至ったか

Ruby on Rails テスト

とても小さくてしょぼい機能しか無いけど、
趣味で作っているRuby on rails製サイトの主要機能に対しテストを充実させた結果、精神衛生的にとても良い気分になったのでカキコ。

github.com

  • トップベージ表示
  • RSSフィード排出
  • 記事詳細ページ表示
  • ログイン → 記事作成
  • markdown→html変換ヘルパー
  • はてなブログカードヘルパー
  • Modelのオブジェクトの妥当性(バリデーション)

上記重要度の高い振る舞いをテストでカバー。
(ツールでコードカバレッジを算出した訳ではない)

結果、シンプルに「システムがちゃんと動いている」信頼感を得る事が出来た。

テストは合計で27assertionと少なめだが、
闇雲にカバレッジを上げたりテストを書いたという事実を作るためのテストは無く、
1つ1つがソフトウェアの動作が正しい事を保証する事に寄与する実効性の高い内容となっている。

この感覚は主要機能をテストでカバーするまで得られなかったし、人力のテストをいくら頑張っても得られた事はない。

おかげでリファクタリングや改修をアグレッシブに行えるし、
レガシーコード改善ガイドレガシーコードとはテストが無いコードのことだという主張にとても共感出来る心境だ。

もう一つ新たに気付いたのは、
一部分だけテストがある状態と、テストが主要機能を一通りカバーしている状態とでは全く感覚が異なるということだ。

後者では上に書いた通り「システムがちゃんと動いている」実感が得られるのだが、前者ではbundle exec rake testコマンドが通ったな、ぐらいの印象しか持てなかった。

個人的にテストとは重要な部分を網羅した途端、急激に信頼度が増加する特性があるのだなぁと感じた。

健全にビジネスを回す為にはこの信頼感が必要不可欠だと強く実感したので、職場のコードにこそテストが完備されるべきだ。