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