第４章 構造化プログラミング 証明 有害宣言 機能分割 正式に証明できない 救済のための科学 テスト 内容 構造化プログラミングとは、goto文を有害なものとしてなくし、その代わりに if/then/else や do/while/until などの「順次」「分岐」「反復」の制御を実現したプログラミングのこと。 構造化プログラミングは、Edger Wyde Dijikstra（読めない）が、数学の証明とプログラミングを結びつけることによってプログラムが正しいことを証明できるようにしようとして提唱したもの。goto文をなくすことによって機能を正しく小さく分割できるようになった。それによって問題が小さく分解され、正しいプログラムの証明ができるようになってきたかのように見えた。しかし、結局は数学的証明はできなかった。 わかったことは、プログラミングは数学的な証明はできないこと。プログラミングは正しいことを証明する数学ではなく、正しくないことを証明する科学（反証可能）であること。科学は、どんなに実証しても常に「正しくないこと」の可能性が常に残っているが、それが目的のために十分正しいと判断されれば使われるもの。これは、バグによって正しくないことの証明はできるが、それを修正したとしてもなんらかの「正しくないこと」の可能性が常に残っていることを意味する。テストでは「正しくない」ことを「証明できなければ」、目的のために十分正しいとみなすという理屈で正しさを担保する。 アーキテクチャは正しく機能分割されていることがベストプラクティスと考えられている。なので、構造化プログラミングの観点でアーキテクチャにとって重要なのは、反証可能な単位で正しく機能分割しプログラムを作成することである。 学びを活かすアイディア・行動 特になし

3 パラダイムの概要 構造化プログラミング オブジェクト指向プログラミング 関数型プログラミング 考えるべきこと 内容 プログラミングには、構造化プログラミング、オブジェクト指向プログラミング、関数型プログラミングの３つのパラダイムがあり、これらは良いアーキテクチャを作るための３つの関心事に関連しているため、概要を紹介する。 アーキテクチャの３つの関心事と３つのパラダイムの関連 コンポーネントの分離： オブジェクト指向プログラミング データ管理： 関数型プログラミング 機能： 構造化プログラミング ３つのパラダイムの要約 構造化プログラミング直接的な制御の移行に規律を課すものである。goto文の代わりに if/then/else や do/while/until に置き換えられた。 オブジェクト指向プログラミング間接的な制御の移行に規律を課すものである。参照を階層的に制御できることを発見し、各階層のローカル変数やインスタンスなどの概念が生まれ、ポリモーフィズムの発見にもつながった。 関数型プログラミング代入に規律を課すものである。ラムダ計算という不変性を概念にした計算により、代入文がない。 これら３つのパラダイムはできることが増やしたのではなく、「すべきでないこと」を伝えている。それは、「goto文」「関数ポインタ」「代入」の３つ。これら３つのすべきでないことを、規律を課すことによってできなくした。 学びを活かすアイディア・行動 今の所特になし

2. ２つの価値のお話 内容 ソフトウェアの２つの価値ソフトウェアには２つの価値があり、１つは「振る舞い」（機能）で、１つは「構造」（アーキテクチャ）である。 この２つのどちらもかけてはならないが、開発者もマネージャーもアーキテクチャより振る舞いに価値があるという認識を持っていることがある。これは間違った態度。 アーキテクチャの価値はソフトウェアが「ソフト」（簡単に変更できるかどうか）であるかどうかで決まる。 この価値の重要性を、極端な例で比べてみる。 完全に動くが、全く変更できないため、将来的には価値がなくなる 今は動かないが、簡単に変更できるため、将来的にも価値がある この例だと極端で、全く変更できないソフトウェアなど存在しない。しかし、コスト面で事実上、全く変更できないといってよいものは多々ある。つまり、低コストで変更ができることは価値がある。 ２つの価値を緊急重要のマトリクスで考える「振る舞い」と「アーキテクチャ」をアイゼンハワー大統領の緊急重要のマトリクスにあてはめて考えてみる。 緊急、且つ重要 重要だが、緊急でない 緊急だが、重要でない 緊急でも重要でもない 振る舞いの領域は１と３で、アーキテクチャの領域は１と２である。エンジニアたちの中でも、振る舞いの３を１に格上げしてしまい、アーキテクチャをおろそかにしてしまうことがある。 しかし、ソフトウェアエンジニアは、これを適切に判断しアーキテクチャがおろそかになりそうであれば、それを防ぐことも仕事だ。ソフトウェアエンジニアもステークホルダーの一部ということを忘れてはならない。 学びを活かすアイディア・行動 今の所とくになし

設計とアーキテクチャ 目的は？ ソフトウェアアーキテクチャの目的は以下であると説明。 ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守する人材を最小限に抑えること システムは拡張・変更のコストを抑える重要な鍵はアーキテクチャにある。保守・運用コストがかかりすぎてしまう原因は、汚いコードにあり、そうなってしまうのはアーキテクチャが良くないからだ。 本書は柔軟なソフトウェアを作るためのアーキテクチャを設計するための原則を紹介する。 アーキテクチャとは？設計とは？ アーキテクチャとは、大枠から細部に至るまでの構造で、大枠と詳細との厳密な境界の明確な基準はない。設計とは、大枠から細部に至るまでの決定の連続のことで、こちらも大枠と詳細の境界の明確な基準はない。 一般的には、アーキテクチャとは上位レベルの構造を指し、下位レベルの詳細と切り離して捉えられていたり、設計は細部の決定をすることと捉えられていることがあるが、それは開発手法やフェーズを踏まえた場合に発生している考え方であって、実際はそれが一般的な基準となる考え方になるわけではない。 ケーススタディ 人材をリリースごとに増やす。図1-1 人が増えているにも関わらず、リリースが進むごとに生産性が下がっていく。図1-2。図1-4。 しかし、人は増えているからリリースが進むごとにコード行あたりのコストも爆増し、開発者に払う給料も爆増。図1-3、図1-5 何が間違ったのか？ 開発者は、後でクリーンにできると自信過剰になり、市場に出すことを急いだ。しかし、実際には後でクリーンにすることはない。市場、競合他社のプレッシャーがあるから。そしてコードはどんどん汚くなり、生産性は落ちていく。 あとでクリーンにできるから先に出すという考え方は、汚いコードは長期的には生産性が下がるが、短期的には上がるという考え方が起因している。しかし、この考え方は間違っていて、実際には短期的にも長期的にも遅いのが正しい。（TDDで進めたプロダクトとそうでないプロダクトで検証。）だから、あとでクリーンできるという考え方は根本から変えないといけない。 うさぎとかめは良い教訓を教えてくれる。 遅くとも着実なものが競争に勝つ 競争は短期的ではない。強いものが勝つわけでもない。 急げば急ぐほど遅くなる 学びを活かすアイディア・行動 今の所特になし