読んだ : Infrastructure As Code
インフラやっていくぞー、という気持ちで去年の中ごろに読んだ。
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
- 作者: Kief Morris,宮下剛輔,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/03/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
本書では最初 (第 1 部) に 「なぜ Infrastructure as Code が必要なのか」 「Infrastructure as Code とは何なのか、何を目指しているのか」 といった説明から始まり、Infrastructure as Code に関わるサービスやツールの紹介がなされる。 そして 2 部では、1 部で紹介されたツールなどを使ったサーバーの追加や変更といったインフラストラクチャの運用のパターンが紹介される。 最後の 3 部はプラクティスで、ソフトウェア工学のプラクティスを応用することや Infrastructure as Code のための組織といった部分の話がなされる。
自分は、Infrastructure as Code とはインフラ構成管理をコード化することで手順を再現できるようにしたり、バージョン管理できるようにしたり、自動化できるようにすること、というぐらいの理解しかない状態で読み始めたのだが、本書で説明される Infrastructure as Code はソフトウェア工学のプラクティスを応用するなど、もともと自分が想定していたものよりもさらに進んだものだった。 また、本書は 「なぜこういう考え方をするのか」 という思想的な部分も丁寧に説明しており、納得しやすい。 学びの多い良い本であった。
特に気になった内容のメモや感想
- Infrastructure as Code の原則
- 簡単に再現できるシステム
- 使い捨てにできるシステム
- 統一的なシステム
- 反復できるシステム
- 絶えず変化する設計
- Infrastructure as Code の原則
- 定義ファイルの利用
- 自己記述システムとプロセス
- あらゆるものをバージョン管理
- 継続的テストシステム、プロセス
- 一斉変更ではなく小刻みな変更
- 継続的にサービスを利用可能状態に保つ
- 「アンチフラジャイル」 という概念 : ストレスを受けたときに通常よりも強くなるシステム (インシデント発生時の対応として改良することをデフォルトの対応とする)
- 「スタック」 の概念 : 一つの単位として定義・変更される、インフラストラクチャ要素の集合
- スタックの単位で構造化していく : 単純な構成だとスタックへの分割の恩恵はないが、リソースの共有などをする場合には意味がある
- スタック間の情報のやり取りに構成レジストリが役に立つ
- システムの品質について、機能的な正しさの問題だと思われてしまうことが多いが、実際には変化を許すかどうかを決める鍵を握っている
- 高品質システムは従来よりも簡単かつ安全に変更できる
- 継続的なブランチのテストは継続的インテグレーションではない
- 継続的インテグレーションとは、すべての作業がトランクで行われて、すべてのコミットがテストされることが保証される。 完全にチェックされた変更だけが本番システムに適用されることを保証するためには継続的デリバリーパイプラインを使う。
- 思想としてはよいと思うが実践的にはレビュー等どうするのだ?? という気がする。 (機能を完全に実装する前の小さい変更の状態でブランチをマージしていく、ぐらいが実践的な気がする。)
- 変更パイプライン : ソフトウェアのデプロイパイプラインに相当するもの (ソフトウェアのデプロイとは違うことを区別するために著者はこう呼んでいる)
- 継続的デリバリーは継続的デプロイではない : 継続的デリバリー (CD) とは、すべての変更をすぐに本番に送り込める状態に高めること。 デプロイ判断を下したら後はツールがデプロイしていく (システムの稼働が技術的な判断になるのではなくビジネス上の判断になる)
- インフラストラクチャの変更のテストでもソフトウェアのテストと同じく、低水準のものを多く、高水準のものを少なくする (テストピラミッド)
- これに限らず、テストのプラクティスは結構ソフトウェアのテストと似ている部分が多いなーと感じた
- リリースとデプロイを切り離すというプラクティス
- 機能トグルとかゼロダウンタイム交換パターンとか
- コンシューマ主導のコントラクト (CDC) テスト
- コンシューマが提供するテストをプロバイダ側のパイプライン上で動かす
- ソフトウェア開発のクライアントとサーバー間でも使えそう
- ワークフローにガバナンスを組み込む
- 承認などのフローも自動化してログの保持などをすることで、手での承認よりも良いものになる
- ゼロダウンタイム変更のパターン
- 企業が変化するニーズに対して信頼できる高品質のサービスで応えていくための組織面での原則
- サービスの設計、実装、改良に対して継続的にアプローチしていくこと
- 継続的にサービスをデリバリー、改良する権限をチームに与えること
- 継続的にスピーディに変更をデリバリーしつつ、高い品質とコンプライアンスを保証すること
- 効果測定。 目標と状況に基づいて役に立つものを選択
- ユーザーに力を与える組織
- プラクティス
- 職能分割モデルには落とし穴がある
- 設計の細分化 : 設計と仕様が中央で作られて、実装のために様々なチームに分配される。 チームからは全体像が見えない
- 厳格な日程管理 : 各チームが複数プロジェクトに関わることになるので、日程管理が重要になってくる
- 長いリードタイム : チーム間の作業の一つ一つがオーバーヘッドを生む
監訳の宮下さんのまえがきにある 『新しい技術用語が出てくると、関連するツールやプロセスが注目され、それらを導入すれば課題は解決する、と思われがちである。 しかし、大切なのはその言葉の背後にある思想や哲学を理解し、適切に運用する人』 というのが良い#書籍 #InfrastructureAsCode
— Nobuoka Yu (@nobuoka) August 10, 2018
『多くの人々は、プラグマティズム (すなわち、仕事を終わらせること) と技術品質 (すなわち、作りの正しさ) をトレードオフと見ているが、これは誤った二分法だ』
— Nobuoka Yu (@nobuoka) August 31, 2018
基本的に設計をちゃんとしないからといって開発速度が上がるということは無いんだよね#書籍 #InfrastructureAsCode
ウケた
『同僚の Chris Bird はこれを “DevOops” と名付けた。 多くのマシンを 1 度にまとめて自動的に構成/設定できるようになると、多くのマシンを 1 度にまとめて壊すこともできるようになるのである』
— Nobuoka Yu (@nobuoka) September 10, 2018
ウケる#書籍 #InfrastructureAsCode
読んだ : よくわかる Auto Layout — iOS レスポンシブデザインをマスター
同僚の iOS エンジニア氏に 「Auto Layout についてちゃんと学んでおくといいですよ」 って言われたので読んだ。
よくわかるAuto Layout iOSレスポンシブデザインをマスター
- 作者: 川邉雄介,所友太
- 出版社/メーカー: リックテレコム
- 発売日: 2016/06/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
著者によると下記のように書かれていて、わりと iOS アプリ開発の初心者向けっぽい。 まさに iOS アプリ開発初心者である自分にとって学びの多い良い本だった。
「よくわかるAuto Layout」はAuto Layoutとサイズクラスについて解説している書籍です。レイアウトの基礎を包括的に紹介し、後半では業務でよく使うパターンをまとめています。アマゾンの紹介文によると対象者は、
過去一度はXcodeを用いてアプリを作ったことがあるが、Auto Layoutとサイズクラスを用いたAdaptive Layoutと言われると、つい尻込みしてしまうアプリ開発者にぴったりの一冊です。
という感じになっています。基本的には、iOSアプリ開発初心者に向けて書いているので、"黒帯エンジニア"みたいな人には向きません。
「よくわかるAuto Layout」を執筆した話 - Jeffsuke is not a pen.
2016 年の本なので最新情報がない点だけは注意が必要そう。 (とはいえ Auto Layout の基礎を学ぶ上では問題なさそう。)
学んだこと
大量の学びがあった。
1 章 : Adaptive Layout をはじめる
- 「Adaptivity」 というのは web でいうところのレスポンシブデザインみたいな感じ。 様々なサイズの画面などに適合するように UI デザインする
- iOS 8 からトレイト (trait) という概念が導入された。 画面サイズなどの環境情報を抽象的なオブジェクトとして扱う概念
- そのひとつにサイズクラス (size class) がある。 サイズクラスでは幅や高さを
Compact
とRegular
に分類 - トレイトの導入前は、画面サイズを
UIScreen.mainScreen().bounds.size.width
みたいにとったり、端末種別をUIUserInterfaceIdiom
でとったりしてた (と書かれているが、現在ではUIUserInterfaceIdiom
もトレイトの一種になってるっぽい)
- そのひとつにサイズクラス (size class) がある。 サイズクラスでは幅や高さを
2 章 : Auto Layout の基本概念
- Auto Layout エンジンは制約式の連立方程式を解いてレイアウトを決定する
- Auto Layout エンジンによる計算においては、各コンポーネントのフレームではなく外接矩形 (Alignment Rectangle) が用いられる
- 制約式は
Item1.Attribute1 = Multiplier * Item2.Attribute2 + Constant
の形。NSLayoutConstraint
で表現される- Constant (制約定数) は制約生成後にも変更可能で、画面回転等に対応しやすい
- 等号だけでなく不等号も可能
- 制約には優先度がある
- 参考 : Auto Layout Guide: Anatomy of a Constraint
- Intrinsic Content Size は、view が保持する内容の固有のサイズ。 他の制約がない場合にはこのサイズが使われたりする
- Content Hugging Priority と Content Compression Resistance Priority で伸び縮みの優先度が決められる
- Auto Layout 以前には Autoresizing が使われていた。 Auto Layout にも影響する (
NSAutoresizingMaskLayoutConstraint
という制約になる)。 View をコードで生成するとデフォルトでは Autoresizing が Auto Layout の制約に変換されるので注意。 (UIView.translatesAutoresizingMaskIntoConstraints
で変換されないように設定できる)
3 章 : UIViewController とレイアウトをサポートするクラス
- 表示の階層構造 : スクリーン (
UIScreen
)、アプリのウィンドウ (UIWindow
)、ビューコントローラ、ビューコントローラが持つビュー - アプリ起動時のルートビューコントローラの設定方法はストーリーボードを使うかどうかで異なる
- レイアウトのライフサイクルは、制約の更新、フレームの更新、レンダリングの 3 ステップ
- フレームとは??
- View controller のライフサイクル : 読み込み、表示、レイアウト、非表示
UIWindow
はウィンドウ。 キーボードとかもウィンドウ- アプリ内部でウィンドウの配列も取れる。
windowLevel
で重なり順 - ウィンドウサイズとスクリーンサイズは区別すること
4 章 : Storyboard と Auto Layout
- アプリ起動時のストーリーボードをプログラムで指定もできる。 A/B テストとか。 AppDelegate で
- ストーリーボードごとに Auto Layout の有効無効の設定ができる
- 複数ビューに Spacing to nearest neighbor もできる
- Equal Width などで 2 つのビューにサイズの制約をつけてそれ以外の幅の制約がない場合は大きい方の Intrinsic content size が使われる (Content Hugging Priority と Content Compression Resistance Priority だと後者のほうが通常は優先)
- Align Panel でビュー間の並び方を決定。 定数も指定可能
- Stack ボタン、本書の例とは変わってそう?
- IB (Interface Builder) でビューを Control ドラッグすることでも制約追加できる。 Document Outline Control 上でも
- IB でのビューのマージン表示 : Editor > Canvas > Show Layout Rectangles
- IB 上で追加した制約は
IBOutlet
で参照できる - 制約に Identifier をつけることができて、エラーメッセージなどがわかりやすくなったりコードから参照できるようになったり
- xib で独自ビューを作れる
- iOS 8 以降の端末のみサポートであれば Xcode 7 で導入された Storyboard Reference で分割できる。 さもなければコードで分割
- Bundle の概念とは? → アプリやフレームワーク、その他の種々のコンテンツなどを表すものらしい。
5 章 : コードと Auto Layout
- 制約 (
NSLayoutConstraint
) をコード上で生成する方法は 3 つ。 普通にインスタンス化するのと、VFL (Visual Format Language) を用いる方法と、NSLayoutAnchor
ファクトリークラスを用いる方法 - VFL はアスキーアートみたいなやつ。 デバッグ中のエラーメッセージにも出てくるので一応形式は知っておくとよいとのこと
NSLayoutAnchor
がおすすめ。 iOS 9.0 以降- 制約を作ったあとは有効化が必要。 iOS 7 以前のサポートが必要ならビューに追加する。 iOS 8 以降だけでいいなら制約の有効化を行う。 複数制約を有効化するための便利メソッドもある (
NSLayoutConstraint.activateConstrains
) - 制約の削除や編集もできる。 編集で制約定数を変更するほうが制約の削除と追加よりコストが低いらしい
- iOS 9.0 以降では
UILayoutGuide
で空間を表現できる。 Android のSpace
っぽいけど、Space
と違って view ではないらしい。 Xcode 7.3 時点では IB 上で生成できない (まじか)
6 章 : 実装基本パターン
- 親ビューに対する割合で幅や高さを指定できる。 Multiplier で。
- Android でいうところの
Space
みたいなものはUIView
を透明にする (または上に書いたUILayoutGuide
)- 透明にするほうがパフォーマンス悪いから背景色決まってるなら背景色指定の方が良いらしい
- View を削除したり、一時的に非表示にして後から戻すというような処理 (本書ではトルツメ) は難しい
- View を削除するとその view に関連する制約も削除されるため
UIScrollView
の内容サイズも Auto Layout で指定する (さもなければコードで指定する必要がある)- 上述のとおり、AutoresizingMask が制約に変換されないようにした方が (暗黙的に制約が追加されて混乱する、ということがないので) 良い場合が多いが、xib ファイルにレイアウトがカプセル化された view を
UITableCellView
に追加する場合などは Autoresizing を有効にしておくと便利っぽい (そうすると親 view のサイズに自動的に合うようになるので) UIStackView
は、view を縦か横に一列に並べる view。 制約を自分で追加せずとも自動で Auto Layout してくれるので便利 (Android でいうところのLinearLayout
っぽい感じ)
7 章 : 実装応用パターン集
UITableView
のセルの高さを指定する方法は 3 つ。 固定の高さを与える方法と、セルごとに計算する方法と、Self-Sizing Cells を使う方法 (iOS 8 以降)。- オフスクリーンでのレイアウトの際に
UILabel
のサイズを見るにはpreferredMaxLayoutWidth
を設定する必要がある - テーブルのスクロール領域全体の高さ計算が最初に実行されるので、セル数が多い場合はパフォーマンスに問題が起こりうる。 iOS 7 以降だと
estimatedRowHeight
で対処できる - Dynamic Type、ユーザー設定に合わせてフォントのサイズを変更する仕組み
- フォントサイズを指定するのではなくテキストスタイルを設定する。
UIContentSizeCategoryDidChangeNotification
の通知への対応も必要- iOS 10 からは一部 view については自動で追従してくれるようになったっぽい : iOSのDynamic Typeについて - Qiita
- 参考 : Scaling Fonts Automatically | Apple Developer Documentation
- キーボード表示時に表示中の内容がキーボードに隠れないようにするには独自処理が必要
- 画面回転への対応は、iOS 8.0 以降とそれより前で方法が異なる
- 回転時のレイアウト変更は制約の有効化と無効化でやるのが (制約の追加と削除よりも) パフォーマンス的には良い
UIViewControllerTransitionCoordinator.animateAlongsideTransition
に制約の変更を記述することで、画面回転のアニメーションと同期して動くようになるらしい
8 章 : Auto Layout をデバッグする
- デバッグに用いることができる Auto Layout の情報は : IB キャンバスおよび Document Outline Control 上と Issue Navigator 上と実行時のコンソール (この章では主にコンソールの話)
- 曖昧なレイアウトかどうかは
hasAmbiguousLayout
で確認できる。exerciseAmbiguityInLayout
でランダムにフレームを変更できる - ドキュメント化されていない便利なメソッドもある
- 制約の衝突はコンソールログを確認。
UIViewAlertForUnsatisfiableConstraints
のシンボリックブレークポイントでも捉えられる - 制約に Identifier を追加するのと、軸やビューごとに制約を確認する
- ビューデバッガーが Xcode 6 で追加されてる。 制約の表示もできる
9 章 : サイズクラスとトレイトコレクション
- トレイトコレクション。 ミュータブルなので最適な値を持つ?? みたいなことが書かれていたがミュータブルという表現がよくわからない。 (例えばアプリのウィンドウがスクリーンよりも小さい場合に、
UIScreen
が持つトレイトコレクションのサイズクラスは Regular だけどUIWindow
が持つトレイトコレクションのサイズクラスは Compact になる、みたいなことかなーと思っている。 が、あってるかどうかは不明) - 画面回転
- IB においてサイズクラスに応じたレイアウトが可能
感想
Auto Layout はもちろんのこと、view の階層構造や view のレンダリングのライフサイクル周りなどについても学ぶことができて、非常に良い本だった。
初心者ながらに 「iOS の view 周りについて必読の一冊なのではないか」 と思った。
関連
- Building Adaptive User Interfaces - Apple Developer : Apple の Adaptive UI のための情報集。
読んだ : これからつくる iPhone アプリ開発入門 — Swift ではじめるプログラミングの第一歩
何故か iOS アプリ開発に関わることになったので iOS アプリ開発について学んでいる。
とりあえず
の 2 つを読んで基礎の基礎だけおさえたところで本書を読んだ。
これからつくる iPhoneアプリ開発入門 ?Swiftではじめるプログラミングの第一歩?
- 作者: 藤治仁,徳弘佑衣,小林加奈子,小林由憲
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2016/10/26
- メディア: Kindle版
- この商品を含むブログを見る
新たに学んだこと
Foundation フレームワーク周り
Timer
クラス でタイマー処理できるUserDefaults
クラス でデータの永続化。UserDefaults.standard
で標準のインスタンスを取得URLSession
クラス で HTTP 通信。 .dataTask でタスク登録JSONSerialization
クラス で JSON の処理
UIKit フレームワーク周り
UIAlertController
クラス でアラート表示。 選択肢もUIImagePickerController
クラス で画像ソースとしてカメラ利用可否確認- カメラ利用にはアクセス許可が必要。 フォトライブラリへのアクセスにも許可が必要
UIActivityViewController
クラス でデータ共有
その他フレームワーク周り
本書で出てきたフレームワーク。
- AVFoundation フレームワーク で音楽再生等できる
- MapKit フレームワーク で地図を扱える
- Core Location フレームワーク の
CLGeocoder
クラスで経度緯度と住所の変換が可能 - Core Image フレームワーク という画像処理フレームワークがある
- SafariServices フレームワーク の
SFSafariViewController
クラス で web view 実現
Swift 言語周り
fileprivate
修飾子とかinternal
修飾子とかでアクセス制御できる。
その他 iOS アプリ周り
- 重なっている view の z 軸方向の重なり順を Interface Builder (IB) 上で変更するにはドキュメントアウトライン上での前後の位置を変えればよい
- オブジェクトを選択して、メニューの Editor > Arrange > Send to Front などで変更することも可能
- Xcode でパラメータ情報を見るにはカーソルを当てて Option キー
- App Transport Security で通信のセキュリティ周りが規定される
NSAppTransportSecurity
キー- 参考 : Cocoa Keys
- iOS 10 でデフォルト設定が変わったらしい
関連して調べたこと
そもそもフレームワークとは?
共有リソース *1 を保持する構造化されたディレクトリ (バンドル) のことらしい。
A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package. Multiple applications can use all of these resources simultaneously. The system loads them into memory as needed and shares the one copy of the resource among all applications whenever possible.
What are Frameworks?
A framework is a bundle (a structured directory) that contains a dynamic shared library along with associated resources, such as nib files, image files, and header files. When you develop an application, your project links to one or more frameworks. For example, iPhone application projects link by default to the Foundation, UIKit, and Core Graphics frameworks.
Framework
感想
かなり丁寧に Xcode 上での操作手順などの説明が書かれていて、iOS 開発以外も含めてプログラミング自体の初心者向けという感じ。 とりあえず最初の一歩としては良さそう。 開発経験者でも、iOS が初めてなら本書をばーっと読んで一通り学ぶという使い方はできそう。 (とはいえ古いので今だと他に良い本もありそう。)
一方でソースコードに微妙なところがあったり *2、デリゲートの説明とかクロージャの説明とかが微妙だったりするのは気になった。
*1:ダイナミックシェアードライブラリや nib ファイル、画像ファイル、ローカライズされた文字列やヘッダファイル、リファレンスドキュメントなど。
*2:「AVAudioPlayerの使い方」 のソースコードはまさに本書のもので、AVAudioPlayer の初期化処理がちょっと謎な気がする。
読んだ : JUnit 実践入門 〜 体系的に学ぶユニットテストの技法
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)
- 作者: 渡辺修司
- 出版社/メーカー: 技術評論社
- 発売日: 2012/11/21
- メディア: 単行本(ソフトカバー)
- 購入: 14人 クリック: 273回
- この商品を含むブログ (69件) を見る
既に JUnit 5 が出ているし今更感はある (本書は JUnit 4 を題材にしている) けど、テストの全体的な話も学べるかなって思って読んだ。 JUnit 4 の話もありつつテスト全般に関する知見も書かれているので、(類書も少ないので) 読む機会がある人はさらっと読んでみるといいかもしれない。
新しく学んだこと
テスト全般
- テストフィクスチャ (test fixtures) : テストの対象やテストの入力値や検証用の値、外部リソースなどの実行環境やテストの実行前に必要なオブジェクトの操作などのこと。
- 狭義にはテストデータだけを指して 「テストフィクスチャ」 と呼ぶこともあるらしい。
- 振舞駆動開発 (behavior driven development; BDD) : ソフトウェアの相互作用に着目してソフトウェアがどのように振る舞うかを定義することを起点とした開発技法
JUnit 4 について
Theories
ランナーでパラメータ化テストができる。- Cucumber / cucumber-junit で振舞駆動開発を実現できる。
読んだ : Clean Architecture 達人に学ぶソフトウェアの構造と設計 (Robert C. Martin 著)
Robert Cecil Martin 氏、いわゆるアンクル・ボブ (ボブおじさん; Uncle Bob) による Clean Architecture についての書籍。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
- 作者: Robert C.Martin,角征典,高木正弘
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/07/27
- メディア: 単行本
- この商品を含むブログを見る
アンクル・ボブの Clean Architecture といえば、下記記事を読んだことがある人も多いだろう。
ここ数年の Android アプリ開発界隈でも Clean Architecture はよく話題に上がっているように思う。 私自身も web 上で Clean Architecture について調べて学んだりしてきた。
しかし、web 上の情報を追いかけるだけだと、レイヤ分けや依存関係のルールはわかっても、より本質的な思想の部分まではなかなか理解できなかった。 例えば、「クリーンアーキテクチャにおいてサーバーとクライアントの構成にする場合にどういう扱いにするのが妥当なのか?」 というのは長年考えてきてなかなか自分の中で納得した答えは出せなかったもののひとつである。
本書を読むことで、Clean Architecture の本質的な思想についても深く理解できた。 また、そもそもの 「アーキテクチャとは何か?」 といった部分まで考えることができた。 ソフトウェアアーキテクチャについてより深い洞察を得たい人におすすめの一冊である。
本書の流れ
本書は、「設計とアーキテクチャは地続きのものであり、本質的な違いはない」 というところから始まる。 そして、構造化プログラミングや関数型プログラミングといったコーディングのパラダイムが説明される。 その後に設計の原則 (SOLID 原則)、コンポーネントの原則 (REP、CCP、CRP) についての説明がある。 ここまでが本書の前半である。
本書の後半では、前半の話を踏まえて、アーキテクチャの説明に入っていく。 アーキテクチャの話だけ読みたい人もいるだろうが、個人的には SOLID 原則や REP、CCP、CRP といった部分についても改めて学ぶことができて非常に良かった。
学びや感想
設計とアーキテクチャ、その目的について
1 章で、「設計とアーキテクチャについて、本質的には違いはない」 ということが言われる。 通常、アーキテクチャは下位レベルの詳細とは切り離された文脈で使用され、設計は下位レベルの構造や意思決定を意味しているが、実際のところ下位レベルの詳細と上位レベルの構造が全体の設計の一部になる。 そうした連続した構造がシステムの形状を定義するので、設計とアーキテクチャを明確に区別することはできない。 上位レベルから下位レベルまで決定の連続であり、その目的は下記の通りである。
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
ソフトウェアの振る舞いが正しいものであることを重視し、アーキテクチャを軽視すると、開発を続けていくうちに生産性がどんどん低くなっていく。 「振る舞いが正しいこと」 と 「変更しやすいこと (良いアーキテクチャ・設計であること)」 のどちらが重要であるかという質問に対して、ビジネスマネージャは、「振る舞いが正しいこと」 であると答えることが多く、開発者もそれに賛同することが多い。 しかし、下記のように考えると、より重要なものは 「アーキテクチャ」 である。
- 振る舞いが正しく、変更しづらい (アーキテクチャ・設計が良くない) プログラムは、今は正しくとも将来的な要件の変更に追従できなくなり、やがて役に立たなくなる。
- 振る舞いが誤っており、変更しやすい (アーキテクチャ・設計が良い) プログラムは、今の正しくない振る舞いを正しく修正することも容易であり、将来的な要件の変更にも追従しやすく、長く価値を保つ。
開発者以外に対してアーキテクチャ・設計の重要性を説明することは非常に難しいと思っていたが、上記の観点で説明すると結構説明しやすい気がした。
優れたソフトウェア開発チームは、真正面から闘争に立ち向かう。 ステークホルダーたちと対等に、ひるむことなく口論する。 ソフトウェア開発者もステークホルダーであることは忘れてはいけない。 保護すべきソフトウェアに対する責任がある。 それが、あなたの役割であり、義務である。 それが、あなたが雇われている大きな理由だ。
『開発者はスクラッチからシステム全体を再設計することが答えだと考えているかもしれないが、それもまたウサギのやり方だ。 崩壊をもたらした自信過剰が、今度は競走をやり直せばもっとうまく構築できるという話に変わっている。 現実はそれほどうまくはいかない。』 せやぞ#書籍 #CleanArchitecture
— Nobuoka Yu (@nobuoka) 2018年10月15日
ソフトウェアの 1 つ目の価値は 『ふるまい』 で、2 つ目の価値は 『アーキテクチャ』。 ふるまいは緊急ではあるが重要ではない。 アーキテクチャは緊急ではないが重要。 後者の方が優先度は高いが、前者の方が優先度が高いと勘違いしてしまうことが多い。 なるほど。#書籍 #CleanArchitecture
— Nobuoka Yu (@nobuoka) 2018年10月15日
テストと反証可能性について
Dijkstra は 「テストはバグが存在しないことではなく、バグが存在することを示すものである」 と述べた。 つまり、テストによってプログラムが正しくないことは証明できるが、プログラムが正しいことは証明できないのである。 テストに十分な労力をかけていれば、そのプログラムは目的のために十分に真であるとみなせる。
この事実は、驚くべきことを示している。ソフトウェア開発は、数学的な構成要素を操作しているかのように思えるかもしれないが、実際には数学的な試みではない。 むしろソフトウェア開発は科学のようなものである。 どれだけ最善を尽くしても正しくないことを証明できないことによって、その正しさを明らかにしているのである。
数学的なアプローチか科学的なアプローチか、という観点は持っていなかったので、「なるほどー」 と思った。
最小の機能から最大のコンポーネントまで、あらゆるレベルにおいて、ソフトウェアは科学のように、反証可能性によって動かされている。ソフトウェアアーキテクトは、簡単に反証できる(テスト可能な)モジュール、コンポーネント、サービスを定義しようとする。そのために、さらに上位のレベルにおいて、構造化プログラミングのような制限を課している。
だからこそ、小さな粒度から大きな粒度まで、あらゆるレベルで反証可能な形で部品化することが重要。 TDD の利点って、この 「反証可能な形で部品化する」 ということをサポートしてくれるからなんだろうな。 『TDD で綺麗な設計に近づける』 と漠然と思っていたけど、すごく納得した
— Nobuoka Yu (@nobuoka) 2018年10月15日
単一責任の原則
SOLID 原則の一つである単一責任の原則 (SRP) について、「たった一つのことだけ行うべき」 だと思っていたけど、正しくは 「モジュールが責務を負うべきアクター (ソフトウェアの変更を望む人たちのグループ) がひとつだけになるようにすべき」 ということだった。 アクターをどう定義するかが難しい気もするけど、アクターの定義をどうするかを含めてしっかり考えていく必要があるんだろうなぁと思う。
複数のアクターが使用するコードが存在すると、あるアクターのための変更が他のアクターに想定外の影響を及ぼしてしまう、ということ。 SRP を完全に理解した。
— Nobuoka Yu (@nobuoka) 2018年10月15日
コンポーネントの原則
再利用・リリース等価の原則 (REP)、閉鎖性共通の原則 (CCP)、全再利用の原則 (CRP)、初めて聞いたな。 コンポーネントの凝集性に関する原則。 再利用性、保守性、それからコンポーネントの変更による他コンポーネントへの影響を小さく保つことの 3 つのバランスをどうとるか#書籍 #CleanArchitecture
— Nobuoka Yu (@nobuoka) 2018年10月16日
『安定度・抽象度等価の原則 (SAP) : コンポーネントの抽象度は、その安定度と同程度でなければいけない。』
— Nobuoka Yu (@nobuoka) 2018年10月16日
抽象的で安定しているか、具体的で不安定かのどちらかがよい。 コンポーネント版の DIP のためにこれが必要。#書籍 #CleanArchitecture
アーキテクチャについて
アーキテクチャについては、下記の内容が非常に刺さったり共感するものだった。
- アーキテクチャはユースケースを叫ぶものでなければならない。 どういう技術を採用するかということに意識がいきがちだけど、重要なのはユースケースであって、どういう技術を採用するかではない。
- アーキテクトとしては詳細の決定はできるだけ遅らせるようにすること。 DB に何を採用するのかとか、通信プロトコルに何を採用するのかなど、そういったものは技術的な実装詳細であり、優れたアーキテクチャはそれらの決定を遅らせられるものである。
- 入出力はテストしづらい部分なので、依存関係の一番外側に持ってくること。
- フレームワークへの依存は避けるべき。 フレームワークは実装詳細であり、アーキテクチャとして重要なものではない。
つまり、冒頭で述べた私のこれまでの疑問の話で言うと、(クライアントとサーバーの両方で一つのソフトウェアなのであれば) クライアント・サーバー間の通信なども詳細であり、アーキテクチャとしてはクライアントもサーバーも含めてユースケースを考える、というのが優れたアーキテクトとしての姿勢なのだと感じた。
ツイートメモ
『アーキテクチャの主な目的は (中略) システムのライフタイムコストを最小限に抑え、プログラマの生産性を最大にすることである。』
— Nobuoka Yu (@nobuoka) 2018年10月16日
アーキテクチャと技術的負債は対応関係にありそう。 『エンジニアリング組織論への招待』 でもそう書かれてた気がする#書籍 #CleanArchitecture
『レイヤーやユースケースを切り離す方法はいくつもある。 ソースコード (ソース) レベル、バイナリコード (デプロイ) レベル、実行単位 (サービス) レベルで切り離すことができる。』 『システムの切り離し方式は時間とともに変化する可能性』 選択肢を残すことが大事#書籍 #CleanArchitecture
— Nobuoka Yu (@nobuoka) 2018年10月16日
ここで言われる保守性を高めることこそがアーキテクチャでありアーキテクトの仕事であろうなー。 その仕事には基本設計も含まれるんだけど、詳細設計やコーディングをできない人がアーキテクチャを考えることは難しい。
— Nobuoka Yu (@nobuoka) 2018年10月18日
https://t.co/of3FgtGEV8
もっと戦略的に事業の展開を予測しながらアーキテクチャを考えていくということをしていく必要性を感じているけどその水準に全然達していない
— Nobuoka Yu (@nobuoka) 2018年10月18日
『優れたソフトウェアアーキテクチャがあれば、フレームワーク、データベース、ウェブサーバー、その他の環境の問題やツールの意思決定を延期・留保できる。 フレームワークの選択肢は残されたままだ。』
— Nobuoka Yu (@nobuoka) 2018年10月22日
いいこと言ってる。 アーキテクチャはユースケースをサポートする。 #書籍 #CleanArchitecture
生まれてから一度もフレームワークに依存したいと思ったことはないんだけど、わりとフレームワークに依存してアプリケーションを書きたがる人が多いように思う。
— Nobuoka Yu (@nobuoka) 2018年10月22日
『システムアーキテクチャがユースケースをサポートするものであり、フレームワークから少し距離を置いたものになっていれば (中略) テストを実行するためにウェブサーバーを起動する必要はない。 テストを実行するためにデータベースに接続する必要はない』
— Nobuoka Yu (@nobuoka) 2018年10月22日
早くここにたどり着きたい
Humble Object パターンって初めて聞いた。 (みんなやってることではあるけれど。)
— Nobuoka Yu (@nobuoka) 2018年10月23日
描画処理などのテストしづらい処理をテストしやすい処理を担うクラスとテストしづらい処理を担うクラスに分けて、後者を控えめ (humble) にしておく、というもの。 Presenter と View とか #書籍 #CleanArchitecture
『ORM システムはどこに属するのだろうか? もちろんデータベースのレイヤーだ。実際、ORM はゲートウェイインターフェイスとデータベースの間に Humble Object の境界を作るものである』
— Nobuoka Yu (@nobuoka) 2018年10月23日
JPA とかはこの思想にそぐわなくてあんま好きになれないんだよなー。 #書籍 #CleanArchitecture
『作者にとって、フレームワークとの結合には何のリスクもない。』 『さらに作者は、あなたに対してもフレームワークとの結合を望んでいる。 (中略) 作者にとって、自分の作った基底クラスを大勢のユーザーが継承することほど、自尊心が満たされることはない』
— Nobuoka Yu (@nobuoka) 2018年10月26日
激しい#書籍 #CleanArchitecture
フレームワークなんかと結婚するな!
— Nobuoka Yu (@nobuoka) 2018年10月26日
#書籍 #CleanArchitecture
クラス・インターフェイスごとには同じような依存関係を持たせるにしてもどこでコンポーネントを切るかでいろんなパターンになるという話。 わかりやすい図だ。 #書籍 #CleanArchitecture pic.twitter.com/M9veKX5eZM
— Nobuoka Yu (@nobuoka) 2018年11月3日