9/6 NSEGの「オブジェクト指向設計実践ガイド」読書会の第1回に参加しました。参加者8名でした。
第1章は導入部って感じで具体的なことはあまり書かれていなかったのですが、胃が痛くなるようないい話が満載でした。
設計がないと、管理されていない依存関係が大混乱を引き起こします。
単純であるべき変更がアプリケーション内部を次々と伝わり、あらゆるところでコードを破壊するのです。そして、広範囲の書き直しが必要になります。テストは四方から板挟みになり、やがて開発を助けてくれるというよりも、開発を妨げているように感じてくるでしょう。
うう…あるあるだ…。
アプリケーションはどれもがコードの集まりです。つまり、コードの構成こそが「設計」であると言えます。
設計とは、同じように訓練された作業員が同一の製品をつくる組み立てラインではなく、アトリエなのです。 志を同じくした芸術家たちが、特別なアプリケーションを創り上げる仕事場です。ですから、設計は芸術と言えます。コード構成の芸術なのです。
動かせるソフトウェアに先立って全体の設計をつくったところで、それが正しいことはありません。それがどんなものであってもです。ですから、仕様どおりにアプリケーションを書いたところで、顧客のニーズを満たすアプリケーションができないことは決まりきっています
もう、すごい当たり前のことなんだけど、プログラマーな人以外はわかってくれなそう。
同じことを何度も繰り返しながら異なる結果を期待することが狂気であるならば、アジャイル宣言によって、私たちは全体として正気を取り戻しました。アジャイルが有効である理由は、ソフトウェアがかたちになる「前」に確かさを手に入れることはできないと認めたからです。
認めてほしい…。
その昔、プログラマーは生産したコードの行数で判断されることもありました。このメトリクスが導入された経緯は明らかでしょう。プログラミングを、同じように訓練された作業員がまったく同じ製品を組み立てる工程だと考えている上司がいたとします。その人たちが、個々の生産性はそれぞれの成果物の量で単純に測れると思い込むのは容易にあり得ることです。
その昔じゃなくて今でも普通にありそう。
というわけで第2章以降も期待です。
次回は9/20です(私はRubyKaigiのために欠席ですが…)。
この書籍(に限らず技術評論社の書籍全般)を電子書籍で購入する場合は https://gihyo.jp/dp がおすすめです。 ひとつ購入すればPDFとEPUBの両方が入手できて、DRMフリーです。
もちろんAmazon Kindle版もあります。
