すべては複雑性 - a philosophy of software design を読んで

a philosophy of software design という本を読んで、自分なりに理解した点を人に説明することによって理解を更に高めるのが目的の記事です。間違って理解している点などあると思いますので、指摘いただけると喜びます。

Chapter 1 Introduction (It's All About Complexity)について説明いています。

すべては複雑性

ソフトウェアには、現実における物理的な制約などがないので、理解してイメージできるものというのは基本的に実現できます。なので、一番の制約となるのは、作っているソフトウェアが頭で理解できるか、という点なんですよね。

そして、そんなソフトウェアの理解を難しくさせるのが複雑性です。ソフトウェアは開発が進むにつれて複雑性が増えていきます。プログラムが大きくなればなるほど、開発者が増えれば増えるほど複雑性のマネジメントが難しくります。

どんなに頑張っても複雑性は増える方向に行くんですが、それを少なくするためのアプローチについてこの本では扱っていて、大きくわけて２つあります。

１つ目は、コードを単純にわかりやすくすることで、複雑性をさげるというアプローチです。
２つ目は、カプセル化で、これによって複雑性が開発者にさらされることなく開発ができるので、複雑性を下げているのと同じことになります。

ウォーターフォール開発と複雑性

ソフトウェアは、ハードウェアなどの物理的なシステムよりも複雑で、大規模のソフトウェアにおいて、開発前にすべてを可視化し設計することは不可能です。

ウォーターフォール開発では、開発前にすべてを設計しようとしますが、すべてを把握するのが不可能なので、設計における不備が確実に生じます。この不備を開発者達が全体のデザインに対して、ツギハギのようにつじつまを合わせて開発していくことによって、複雑性が一気に増大するという問題があります。

アジャイル開発と複雑性

上記の問題から、最近ではアジャイル開発という手法が取られるんですよね。この開発手法では、すべての機能について設計するのではなく、まず小さな単位のソフトウェアに関しての設計を行って、実装していきます。

そして最初の設計の問題点が明らかになるので、設計と実装を修正します。そしてまた小さい単位の機能に関して設計を行って実装します。この作業を反復していくことによって、設計の問題を修正しながら、ソフトウェアを大きくしていくことができます。

このような段階的なアプローチを取るということは、ソフトウェアの設計には終わりがなく、継続的に再設計をするということです。最初に行った設計がベストなことはほとんどないんですよね。

なので、ソフトウェア開発者としては、常に設計を改善していくチャンスがないか探っていくことが重要で、そのような時間を意識的に確保する必要があります。

この本では

この本では、そんな複雑性という観点から、どのようにソフトウェアを設計ていくのかという点について書いてあります。

特に大きく2つのゴール設定をしていて、

1. 複雑性とは一体何を意味するのか、そしてなぜそれが重要で、不要な複雑性というのをどう認識すればよいのか、について書くこと
2. その複雑性を最小にするにはどんなテクニックが使えるか、について書くこと
   としています。

ソフトウェアの複雑性を下げるための簡単なレシピ、のようなものは存在しないので、そのかわりに、もっと抽象的な概念を使って説明しています。

例えば、「クラスは深い方が良い(classes should be deep)」「エラーが存在しないように定義する(define errors out of exsitence)」などがあります。この辺はまだ読んでないので、いまいち抽象的な表現の意味するところが分かっていません。後に続く記事で解説できたら良いなと思います！