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