ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

「レガシーソフトウェア改善ガイド」を読んだ

はじめに

読みました。

レガシーソフトウェア改善ガイド

レガシーソフトウェア改善ガイド

似たシリーズにレガシーコード改善ガイドがありますが、こちらはコードレベルのリファクタリングが中心のような気がします。(ちゃんと読んでない。)

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

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

なぜ読もうと思ったかというと、今CI専任のプロジェクトにいます。

部内の製品を見てみると、テストコードは「かつて少し書かれた」残骸が残っていて全然機能していない「レガシーコード」が多い。

そしてレガシーコード・ソフトウェアの改善まではミッションではないにしろ、古いコードにテストコードを書く・書かせるというアプローチはしたいと思っています。そのときにレガシーコードをどう立ち上げますか、どう改善しますかというベストプラクティスがあればそのついでに改善提案もできるかもしれない、という興味で手に取りました。

この本の良いところは特にCD(Continuous Deployment)に関しても最新技術(Vagrant、Ansible)を使うと言及しているところが良いですね。

では中身を簡単にさらっていきましょう。

第1部 はじめに

ここではレガシーソフトウェアの定義を確認するとともに、そのために必要なスタート地点である、データ収集というアプローチが大切という話が書かれています。

本書の前提知識の部分ですね。

レガシーコードの定義部分、テストがない、ドキュメントがない、引き継がれまくってる、テストしにくい、環境構築が難しい、などなど「あるある」と感じることが多いのではないでしょうか。

そして最も改善のための高い壁、触れてはいけない、精神的な「恐れ」との立ち向かい方についてが第2章です。特に基盤周り、ツールを使いこなしてあらゆる計測可能な情報を収集するとか、ツールを整えるとか、jenkinsを使ってチームのコミュニケーションハブを作るとかの、準備運動が書かれてます。

第2部 コードベース改良のためのリファクタリング

ここではリファクタリング・リアーキテクティング・ビッグリライトの3段階を説明します。

大きな主張としては絶対に新規作り直しはするな、ということでしょうね。

手がつけられないコードだとしても、「とりあえず動いて」いて、かつ「書き直してきた歴史」があるわけで、今はそれを見えないけど、かつてのバグを超えてきたコードであることは間違いなく、気づかず同じバグを踏んでしまう可能性があります。どんなに時間がかかっても少しずつ手直しするしかない。銀の弾丸はないとはいろんな場所で言われてますもんね。

また、リファクタリングは経営層から承認がおりづらいことについても言及しています。まずは秘密の20%プロジェクトとしてやってしまって、そのあと承認をとるほうが良いですね。組織の承認をもらって正式な仕事にすることを進めています。

コメントアウトはまっさきに削除して良いとか、今通ってないコードはいらないとか、どこを削っていくかの指針を示しています。

また、ユニットテストは大切だが、しばしば無意味なものになることについても慎重に述べています。リファクタリングしてしまえばそのテストは無駄になるかもしれず、またリファクタリングをしないとテストがかけない場合も往々にしてある。さらに、unittestのカバレッジにも敏感になりすぎる必要はない(完璧である必要がない)ということも述べています。

ただ、カバレッジが100%じゃないけど、品質はokですって上長に説明してokもらえるか自信が持てないなと思いました。これ、さらに外側のE2Eテストも自動化しておいて、そちらで基本機能は全てokが出ており、カバレッジ100%にするためにunittestを書くのは無意味かつコストが見合わない、っていう見解になるのかな。

リグレッションを防ぐためにあらゆる層。。。UnitTest、ComponentTest、UIのテスト。。。で自動テストする必要があるっていうことですね。

ちなみにリアーキテクティングはモノシリックなアプリケーションをマイクロサービスの考えで機能ごとに分割することですね。

これにももちろんメリットデメリットあって、分離すればコンポーネント(チーム)ごとに、内部の実装を変更できる、つまりインターフェイスさえ変更がなければ問題ないので他チームと同意する必要がないことがメリットとしてあります。反面インターフェイスの変更がコストになったり、結合テストの難易度があがることがありました。

第3部 リファクタリングの先へ -プロジェクトのワークフローと基盤を改善する-

これまでのリファクタリングやテストの精神的な部分、組織的な部分、メリットデメリットは各所で語られてきました。

最後はワークフローの自動化の大切さについて実例に伴って書かれており、これも「わかる。。。」と思いました。

テスト環境を作る時、「ここのwikiに書いてあるからそれ見ながらやって(ただし情報が古く誰がいつ更新したのかわからない)」みたいな話よくありませんか?

それが全て自動化されて、ここを押せばすぐに環境ができるから仕事(本当にやりたいデバッグや開発)に取り組める世界を作ることに努めなさい、そのためにはあらゆるものを自動化しなさい、という内容です。手順書殺せの僕としてはとても同意。。。

そうやって自動化した上で、簡潔なREADMEをバージョン管理に残しておきなさいという話。

これ、OSSの時代である今時、デプロイ自動化なんて当たり前のように感じますけど、残念ながら社内ではまだまだです。遅れながらも実践して広めていきたいと思います。

おわりに

「そんなことできれば誰も苦労しない」だけどそこらに転がってレガシーコード。もう生まないということが大切だとわかっていても、生まれてしまったものを嘆いても仕方がない。

この世にあるレガシーコードを改善する方法を体系的にまとめた本書には、改善のためにどう取り組めばいいかというエッセンスが詰まっています。

「あらゆるものを自動化」して、それを組織に広めていくことが自分にできる第一歩だと思っているので、2017年の最初の3ヶ月、仕事で取り組んでいき、テスト・CI・CDを実践し、社内に広げていきます。

レガシーコードを目の前にして、なんとかしたいけど、巨大な壁に何をしていいかわからない、というひとにはおすすめです!