このシリーズでは、Google のソフトウェアエンジニアリングの道の要約と読書の感想を更新していきます。
時間と変化#
一度性の計画と 10 年間続くプロジェクトの間には変化が生じます：プロジェクトは絶えず変化する外部要因に対応する必要があります。
初めからアップグレード計画がないプロジェクトでは、この変化は非常に困難になる可能性があります。その理由は 3 つあり、それぞれが他の理由を複雑にします。
- まだ完了していないタスクを実行している可能性があります。より多くの隠れた仮定が成立しています。
- アップグレードを試みるエンジニアは、このようなタスクの経験を持っていない可能性が高いです。
- アップグレードのスケールは通常、通常よりも大きく、数年分のアップグレードを一度に行うことがあります。
"動作することができる" と "メンテナンス可能" の違いについては、より明確に認識する必要があります。
ハイラムの法則 - 十分なユーザーがいる場合、契約の約束は重要ではありません：システムのすべての観測可能な動作は依存されます。#
柔軟性と巧妙さ、欠陥のなさとメンテナンス可能性：これらはプログラム開発スタイルの分類に依存し、コードが脆弱でリリースされていないコンテンツに依存する場合は前者、最適な実装方法に従い将来の計画を立てる場合は後者です。
巧妙さが賞賛される場合、それはプログラム設計です。巧妙さが非難される場合、それはソフトウェアエンジニアリングです。
拡張不可能性と拡張可能性のポリシー - コンパイラのアップグレードを例に挙げます#
コードベースの柔軟性に影響を与える要素
- 専門知識
- 安定性
- 一貫性
- 熟知度
- ポリシー
このタスクのコストが高すぎると考えられる場合、将来的には避けるべきです。その結果、10 年前のコンパイラバージョンを使用し続ける可能性があります。優れた機会を逃したため、計算リソースの増加に 25% のコストがかかる可能性があります。
停滞は選択肢ですが、通常は賢明な選択ではありません。
左シフト#
開発者が問題を早期に発見すると、コストを削減するためにセキュリティの問題を左シフトすることが非常に重要です。
意思決定の投入 - 分散アーキテクチャ#
コードベースが大きくなるにつれて、ビルド時間も長くなります。そのため、ローカルマシンにさらに多くのリソースを投入する必要がありますが、多くの場合、高性能なデスクトップ開発マシンはアイドル状態になるため、これは良い投資方法ではありません。
分散ビルドシステムを開発し、本番環境に展開することで、すべての人のビルド速度が向上します。しかし、時間の経過とともに、分散ビルド自体も複雑になります。
分散ビルドシステムによって節約されるコストが "ビルドとメンテナンス" の負のコストを上回る場合があります。しかし、これらのコストは増加し、すべてのコストを予測することはできません。
ソフトウェアエンジニアリングとプログラム設計#
プログラム設計はコードを生成する直接の行動です。ソフトウェアエンジニアリングは、戦略、実装方法、ツールのセットです。