ソフトウェア開発
ソフトウェアの難しさは規模から来る。多くの技法は一度に考える範囲を狭めるためにある。
動くものを作り、動き続けるようにするための知識。
構成#
| 領域 | 内容 |
|---|---|
| アプリ開発 | 種類を問わず共通する土台 |
| Swift・SwiftUI・iOS | Apple プラットフォーム |
| Web・ネットワーク | ブラウザと通信 |
| データベース | 状態の永続化 |
| ソフトウェア設計 | 構造の作り方 |
| インフラ | 動かす場所 |
共通する視点#
ソフトウェアの難しさは規模から来る。 1000 行なら全部覚えていられるが、 10 万行では覚えていられない。
そのため多くの技法が 「一度に考える範囲を狭める」ことを目的にしている。
- モジュール分割、カプセル化 — 中を知らなくても使える
- 型システム — 機械が整合性を保証する
- テスト — 変更しても壊れていないことを確かめる
- 不変性 — 変わらないものは追跡しなくてよい
Brooks の言う「本質的な複雑さ」と「偶有的な複雑さ」の区別が 今も有効で、道具の改善が効くのは後者だけ。
参考文献#
- Frederick P. Brooks, Jr. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer 20(4), 1987. https://doi.org/10.1109/MC.1987.1663532
- Robert C. Martin. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall, 2017.
- Martin Kleppmann. Designing Data-Intensive Applications. O’Reilly, 2017.
この階層のノート
アプリ開発 9 / 9 プラットフォームを問わない共通要素。複雑さの大半は状態から来る。 Swift 14 / 14 Apple の言語。値型中心・プロトコル指向・型による安全性が設計の軸。 SwiftUI 14 / 14 宣言的UIフレームワーク。画面を状態の関数として表すので、更新し忘れが起きない。 iOS 8 / 8 Apple のモバイル OS 固有の事情。制約が多いのは電池・安全性・一貫性のため。 Web 14 / 14 URL・HTTP・HTML の3つで成立する分散情報空間。単純さと寛容さが普及を支えた。 ネットワーク 8 / 8 層に分けることで、各層を独立に入れ替えられるようにした設計。 データベース 10 / 10 永続化と効率的な問い合わせ。最も価値があるのは障害時に壊れないこと。 ソフトウェア設計 10 / 10 変更しやすさのために構造を選ぶこと。層を増やすこと自体は価値ではない。 インフラ 12 / 12 書いたものを動かし続ける仕組み。抽象度が上がるほど管理は減り、依存は増える。