maya's blog

About programming, aws and ubuntu

Clean Architecture 第1章まで 読書メモ

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Robrt C. Martin, 角征典, 高木正弘 著

ISBN-13: 978-4048930659

第Ⅰ部 イントロダクション

  • 一度だけ動くシステムをプログラミングするのは簡単だが、プログラムを正しくするのは難しい
  • ソフトウェアを正しくすれば開発や保守に必要な人材はわずかで済む
    • 簡単で迅速な変更
    • 欠陥数の減少
    • 労力の最小化
    • 機能性と柔軟性の最大化
  • システムの設計とアーキテクチャのおかげで、開発や保守が楽になっているという筆者の経験
  • だが、(読者に向かって)これまで反対の経験がほとんどではないか?
    • どれだけ小さな変更でも大きなリスクを伴い、数週間掛かることはないか?
    • ひどいコードや腐った設計に邪魔されたことはないか?
    • システム設計がチームの士気、顧客の信頼、マネージャの忍耐に悪影響を及ぼしたことはないか?
    • ソフトウェアの腐った構造により、チームや部署、企業が潰れるのを見たことがあるか?
    • プログラミングの地獄へいったことがあるか?

第1章 設計とアーキテクチャ

大雑把にいうと、クリーンなコードを書くことの根拠や、そうすることで何が嬉しいのか理由づけを説明している章

  • 設計とアーキテクチャに違いはない

  • 最上位レベルから最下位レベルまでの決定の連続

    • (最上位レベル)家の形、外観、正面図、空間や部屋のレイアウト
    • (最下位レベル)排気口、ライトのスイッチ、ライトの配置
  • 優れたソフトウェアの設計(上記で言えば最上位から最下位レベルへの決定)の目的とは?

    • ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えること
    • リリース毎に労力が増えるならば、その設計は優れていない
  • 優れていないシステム設計が現場にあるとどうなるのか?

    • リリース毎に開発者が増えるが、製品のコード数は漸近線止まり
    • リリース毎にコード行あたりのコストが2次関数的に増加
    • リリース毎に生産性が低下
    • リリース毎に開発者の給与が増加
    • (というのをグラフを用いて説明)
  • 結局イソップ童話の「ウサギとカメ」と一緒だよね

    • 後先考えずリリース優先で、汚いコードを書き続けていると、後々ひどい目にあうよね
  • 優れた、クリーンな、うまく設計されたコードが重要であること

  • リリース後にクリーンにすることはない、なぜなら次のリリースの圧力があるから

  • 崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い

  • 早く進む唯一の方法は、うまく進むことである
  • 自信過剰による再設計は、元のプロジェクトと同じように崩壊する

    • 開発者はスクラッチからシステム全愛を再設計することが答えだと考えているが、それもまたうさぎのやり方と同じ
  • ソフトウェアアーキテクチャと真剣に向き合うには、優れたソフトウェアアーキテクチャとは何かを知る必要がある

  • 労力の最小化と生産性の最大化を実現する設計とアーキテクチャを構築するには、そこに到達するためのシステムアーキテクチャの属性を把握する必要がある