mike-neckのブログ

Java or Groovy or Swift or Golang

クリーンアーキテクチャーの読書メモ(3)

f:id:mike_neck:20190312230053p:plain

第二部 プログラミングパラダイム

§3 パラダイムの概要

§4 構造化プログラミング

  • Edsger Wybe Dijkstra
  • アルゴリズムの証明
    • プログラマーがプログラムを書けていない問題を、数学の証明を適用することでサポートすることを目指した
    • goto 文を濫用すると分割統治法が破綻することを発見(うまく使えば破綻しない)
    • プログラミングの最小単位である順次/選択/反復という最小セットと同じ構造になるようモジュールにわけることでプログラムが証明可能であると発見した
  • 有害宣言
  • 構造化プログラミング
    • モジュールを証明可能な単位に再帰的に分割する
    • 大きな問題は上位レベルの機能に分割、上位レベルの機能は下位レベルの機能へ無限に分割
  • 証明するという目標は達成できなかった
  • 科学の証明
  • テスト
    • ソフトウェア開発は科学の証明と同じ
      • 構造化プログラミングではプログラムを分割して、証明可能な小さな機能にする
      • 証明可能な小さなプログラムが正しくないことをテストで証明する
    • (制限)正しくないことの証明は証明可能なプログラムにしか適用できない/証明不可能なプログラムはいくらテストしても正しいとみなせない
  • ソフトウェアアーキテクトはビジネスをテスト可能なサービス/コンポーネント/モジュールに分割するため、構造化プログラミングのような制約を課している

swift-nio-ssl に出したサンプルコードのPRがマージされました

すごい時間かかりましたが、Apple の swift-nio-ssl に出したサンプルコードのPRがマージされました。

github.com

時間かかったのは、僕がどうやら指摘されてた修正をすっかり忘れていたからっぽいです…

現場からは以上です。

クリーンアーキテクチャーの読書メモ(2)

表題の通り

f:id:mike_neck:20190312230053p:plain

§2 2つの価値

  • プログラマーステークホルダーに提供する2つの価値
    • 振る舞い
    • 構造
  • 振る舞い
    • 多くのプログラマーが価値だと思いこんでいるもの
    • 機能仕様書とか要求文書とか
  • 構造 = アーキテクチャ
    • 振る舞い = ソフトウェアを簡単に変更できる手段
    • システムが複雑になってシステムの形状が要件の形状に合わなくなっていく
  • 価値
    • 完璧な動作で変更が現実的でない(難易度的に/コスト的に)ソフトウェア = 価値がない
    • 間違っている動作だが変更が容易なソフトウェア = 価値がある
  • アーキテクチャーの戦い

クリーンアーキテクチャーの読書メモ(1)

以前からちょっとずつ読んでいたけど、そのまとめメモ

このメモもちょっとずつ更新予定

f:id:mike_neck:20190312230053p:plain


Clean Architecture

第一部

イントロダクション

  • 正しいソフトウェア
    • 少ない人数でソフトウェアを動かせる
    • 少ない人数で保守・開発できる

§1 設計とアーキテクチャ

  • 設計とアーキテクチャの違い
    • ない。同じ
    • アーキテクチャは上位、設計は下位と考えられがちだが、上位の構造、下位の詳細ともに全体の設計の一部であり、意思決定の連続
  • 決定の目的
    • ソフトウェア/システムを少ない人数で構築・保守する
  • ケーススタディ
    • リリースと共に生産性が低下/コストが上昇
  • 原因
    • コードが崩壊・汚い
  • あとでクリーンにする
    • あとでクリーンになんかしない
  • 結論 : 崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い
  • 早く進むための唯一の方法は、うまく進むこと