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