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

ソフトウェアの再利用性を支えるものは

 このエントリで書くと言及したことについて書く。

 ソフトウェアを効率的に再利用性するにはどうすれば良いか。

 この問いは、仕様の共有やソースコードの移植なんかが頻繁に行われている背景から、製造業においてかなり切実な扱いを受けてきた印象を受ける。
 特にここ最近は形式手法やUMLといった方法論が普及しつつある世情を受けてか、業界のカンファレンスやセミナーでは毎回のように再利用性の問題が扱われるようになっている。一種のブームを呈しているといっていいかもしれない。

 この再利用性の問題に対してだけれども、自分の属する製造業では、上流工程からの改善しようとする傾向を感じる。
 例えばプロダクトライン開発(SPLD)が一番注目を集めているあたりにそういう傾向を感じる。プロダクトライン開発はマネジメントレベルでソフトウェアの再利用性を管理していく開発手法で、最上流で設計を行う段階からフレームワークや共通モジュールを抽出し、ロングスパンの流用に足る汎用コードを確保したり、重複したコードの実装を削減したりする。マネジメントレベル・上流設計レベルから実装レベルまでを巻き込んで運用する点で、特に設計から製造まで全工程を管理するメーカーとの親和性が高く、人気が高い。
 またそれ以外の選択肢としても、MDDやMBDといった、上流工程からトップダウンで下流の成果物の再利用性を高めようとするアプローチが取りざたされている印象を受ける。


 ただこうした手法により、実用に足る再利用性が得られるかというと、そうでもないと思う。というのも、前にも似たようなことを書いているけど、将来どのように再利用されるかなんて予測は完全にできないし、コードの修正が必要になるリスクをすべて捕捉するなんてことは不可能なので、

再利用性というのは、追い求めれば追い求めるほどソフトウェアを冗長なものにする。完璧な汎用性を持つコードを目指すのは現実的ではない


と言わざるを得ないと、自分は思っている。
 そのため、ある程度プロジェクトごとに実装段階でカスタマイズできる余地を残さないと、良い開発効率と再利用性の両立は実現できないと思う。言い換えれば、ソフトウェアを効率的に再利用するには、上流工程からのアプローチだけでなく、下流工程からのアプローチも必要だ、と感じる。
 カンファレンスや論文などで、

「(SPLDを見習って)ソフトウェアの再利用を推進すればするほど、ソフトウェアの品質が下がった」

などといった報告がなされているのを時々みるけど、そうした状態になっているのも、上流工程からのトップダウンに頼りすぎた結果だと、個人的に感じる。

 では下流工程からのアプローチはどうすれば良いか、という点だけど、これに関しては去年とても核心的な考え方をある本を通して得ることができた。かなり長い前置きになってしまったけれども、その本こそが「Working Effectively With Legacy Code」。
「Working Effectively With Legacy Code」は冒頭で以下のように言い放っている。

「To me, legacy code is simply code without tests.」
(私にとって、レガシーコードとは単にテストが書かれていないコードを指す)

 この文を見た当初は、ユニークな視点を持つ著者だななんて印象で終わっていた。が、後々再利用性の問題を考えているうちに、これがかなり問題の核心を突いた定義だというのが段々と分かってきた。
 この定義は、説明を補足すると以下のようになる。

  • テストがないと挙動の把握が困難になる。
  • テストがないとリファクタリングができない。テストのないコードのカスタマイズはリスキー。

 これを再利用の観点で組み替えると、以下のような主張になるだろう。

  • ドキュメントはコードの再利用性を支えるものとして心もとない。だからコードの生の挙動をテストで示そう
  • 再利用性する際はカスタマイズが必要。だからリファクタリングできるテスト環境を作ろう

 これは全く妥当であり、前述の上流工程をうまく補うアプローチだと思う。というより、上流工程志向のアプローチはモジュールのテストケースやふるまいを抽出するのに適している点で、補うどころか、かなりの相乗効果を発揮させると感じている。
 例えばプロダクトライン開発ならば、単体テストのテストケースをコア・アセットに据えることで、モジュール妥当性が保障されかつ安全にカスタマイズできるソースコードを様々なプロジェクトに提供できるようになると思う。またモジュール妥当性の等価性も評価が楽になることから、コア・アセットのマージや作り直しの手間も大仰なものでなくなると感じる。

 さらに上流工程からのアプローチは規模が必要な分、マネジメント層や上流工程主導で行われることが多いけれど、このWEwLCのアプローチは一介のプログラマやテスターでもはじめられるもの。それはある程度規模を持たせないと利益を得られないプロダクトライン開発と違って、柔軟に、実際に手を動かす作業者の都合に応じて実益を出せることを意味している。自分みたいなプログラマにとってとても都合がいい。

「再利用性が必要ならばテストを書く」

 これは今ではソフトウェア開発での自分の哲学の1つとなっている。そして今のところ、それは哲学として間違っていないと信じている。

 最後に、WEwLCの読書会に関しては、レガシーコードの定義の重大さに(周回遅れだったものの)気づけた結果、最後まで付き合わさせていただくことになった。貴重な知見を得られる機会を提供していただいた点で、読書会開催者の方、会場提供者の方、その他参加者の方々には深く感謝しています。重ねて御礼申し上げます。

Working Effectively With Legacy Code

Working Effectively With Legacy Code