前回からの続きになります。前回は、単純さ
そして、特定の問題を回避することによって、本当に重要な問題に集中することができるようになります。
削除した行の計測
どのようなコードにおいても、何かしらの機能を追加するということは、そこに潜在的なバグを含む可能性があります。機能を追加するとなったときは、一度懐疑的になり、今のコードで無駄なコードや障害を生む可能性があるコードを削除するべきです。
最小限のAPI
わかりやすい最小限のAPIを書くことは、ソフトウェアが単純であるためには欠かせない要素です。
APIが小さく単純であることは、特定の問題が十分に理解されている証明になります。
モジュラー性
モジュラー性を保つことは、システムの一部を独立して変更するためには欠かせません。コードやバイナリ、その設定を疎結合にすることで、開発のアジリティと安定性を同時に高まります。
また、APIの変更のやり方自体にモジュール性の考えを使うこともできます。
APIを一つ変更しただけでシステム全体の再ビルドが必要な状態は望ましくありません。APIにバージョンを与えることで、自分のシステムに依存しているバージョンを使うことができます。これによりシステムは安定に稼働することができます。APIのリリースはバージョンごとに異なっていても良く、またプロダクション環境への機能追加も一度に行う必要がなくなります。
リリースの単純さ
リリースは単一のリリースを繰り返す方が優れています。
それは、仮に複数の変更を含んだリリースを行うと、もし問題が生じたときに影響範囲を特定することが難しくなるからです。
そのため、小さい単位でリリースすることにより、それがパフォーマンスにどのような影響をあたえたのかの理解がしやすくなります。
まとめ
- 複雑はバグを生む可能性がある。
- 必要な複雑さに焦点を当てる。不必要な複雑さは回避する。
- 単純さを保つ。そのためにやり割り範囲を明確にしたものを疎結合する。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 103-105