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

レガシーソフトウェア改善ガイドを読みました。英語では “Re-Enginnering Legacy Software” なので、”改善ガイド”とするには少し内容とタイトルに乖離があるかもしれないですね。

この書籍は、最近のアーキテクチャ(モノリシック/SOA/Microservices)や言語特性の変化、CI/CD環境など含め最近の流れを踏襲した上でレガシーソフトウェアを継続してより改善できる形にするためのtipsが書かれています。そのため、開発環境/スタイル/設計などを含んだ全体的な改善の話が書かれていました。レガシーコード改善ガイドをベースとすると、テストできない、継続して機能を壊さず改善することが困難なソフトウェアがレガシーなものになります。

ソフトウェア開発においてしばしば言われるように、コードがレガシーとなる原因の多くは人に関係します。それは例えばサービス開発におけるサービスの成長フェーズに対するビジネスの要求に応えるためのものだったりとします。そのため、レガシーに見えるものも実はサービス開発を試行錯誤しながら行い、成長した結果と言える面もあるかと思います。(ここは組織の力に依存しそうですが)

この書籍の中で、コード品質の指標として欠陥密度に対する言及があります。それがCoverityによる2012年のLinuxカーネルの静的解析において、コード1000行あたりの欠陥密度(defect density)が0.66/klocであるというところでした。これは純粋に興味深い内容でした。OSSとして多くの意見が入る可能性の高い成果物が、高品質なコードであると示される珍しいものではないでしょうか。そしてそれを支える為に重視しているものがコードレビュー。これにより、低品質なコードの混入を防ぐ、知識の共有とそれらのサポートといった保守も含めた知見を共有しているとあります。

開発の中では心理的な障壁は最善の仕事を効率よく行うことを妨げます。この中に”恐れ”があります。この恐れは未知なものに対峙するときに顕著になため、未知な領域(コード)に足を踏み入れながら、未知を克服していくことが必要となってきます。このような未知を克服しながら進むことを”調査的リファクタリング”(exploratory refactoring)と呼んでいました。

Exploratory Testingが探索的テストと呼ばれる一方、こちらは調査的と表現しているのですが英語をベースとするとどちらも似たようなことをしながら”中身を理解し明らかにしていく”ことを達成しようとしているのですね。

ちなみに、これらを補助するためのツールなども書かれています。

理想のシステムは、コードの品質を開発者の努力なしに自動的に監視し、その情報をチームメンバ全員が利用できるようにするもの。意識しない、努力しないというのは大事で、それが系として組み込まれている状態を指します。やはり意識によって改善するには人は確率的に誤りをおかしすぎてしまいますからね。

そういえばミカドメソッドの話が出てました。これは修正したい対象の周辺をグラフに落としていって、見通しをよくした上で優先順位を定めて取り組むというものです。言及されるとは思いませんでした。

あとはmutableなものをimmutableにしていくところも言及されていました。これは最近の関数型言語に対する風潮もありますね。これは複雑奇怪なビジネスロジックをテスト可能にし、確認可能な状態で単純化することに貢献する説明の箇所で出てきています。

当然、テストの自動化にも言及していました。単体テストを自動化することに対しては誰もが納得することだろうという前提のもと。私もここ数年でモバイルアプリの領域でやってきたことなのですが、 とくに自動化を必要とするのがUIテストの領域 と書かれています。ここがちゃんとできているところはおそらくできていないところに比べて多くの利益を享受しています。不具合の見つからないごく一部の自動化されたUIテストではなく、不具合をちゃんと見つけてくれる多数の自動化されたUIテスト。個人的に、それは特にGUIが差別的な要素になる可能性の大きな特にモバイルアプリの領域では差が出てくるところだと考えています。(ここら辺は今度機会があるのでそこで話すかもしれません)

英語ではこれらのように書かれています。

– Unit tests are not a silver bullet.
– One area that cries out for automation is UI testing.

(4.3.2. Regression testing without unit tests)

他に面白かったところは、Webアプリのアーキテクチャの話でモノリス/SOA/Microservicesなどを比較しているところでした。特に、組織面での利点まで言及していたところが個人的には好印象でした。アーキテクチャはやはり組織に影響を及ぼしあうので。その中で、やはり情報伝達はモノリスがオーバーヘッドが小さく、個々の独立性が高まると従来の情報伝達はオーバーヘッドが大きくなるところが印象的。(いっていること自体は至極真っ当)

まとめ

主な対象はWebサーバアプリでしたが、これはモバイルアプリにも多く転用できるものでした。実際、私がモバイルの領域でやっていたものはこの書籍における改善案の方針として言及されているものが多かったです。

refactoring/rewriteしながら継続して価値を出しているサービスをより継続して開発し続けることができるように取り組んでいきたいですね。

Advertisements

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s