ソフトウェアのトレードオフ

ソフトウェアのトレードオフ

すべての設計上の選択は、他の選択肢への扉を閉ざすことになります。ソフトウェアはトレードオフによって成り立っています。これらの選択は、意図的に行う必要があります。そうしなければ、意図せず（偶然に）選択することになってしまいます。

直面する一般的なトレードオフ：

• 機能性 vs パフォーマンス クリーンなコードは実行速度が遅くなりがちです。高速なコードは読みづらくなりがちです。1日1回実行されるバッチ処理には読みやすいコードを使い、リクエストごとに数千回実行されるパスには最適化されたコードを使用しましょう。

• 柔軟性 vs シンプルさ 複雑な抽象化はコードの理解を困難にします。動作する最もシンプルなコードを書きましょう。後で拡張できるように構築してください。

• スケーラビリティ vs コスト 膨大なトラフィックを想定した設計は、今すぐにより多くのコストがかかります。成長率を測定することが判断の助けになります。毎月20%成長しているなら、将来を見据えた計画を立てましょう。資本が少ない場合は、コストを抑えましょう。

• セキュリティ vs ユーザビリティ 極端なセキュリティはユーザー体験を損なう可能性があります。かつて、管理ツールにハードウェアトークンの使用を強制したことがありました。その結果、ログイン成功率は98%から84%に低下しました。緊急時にエンジニアがロックアウトされる事態も発生しました。そこでモバイルのプッシュ通知に切り替えたところ、成功率は96%まで回復しました。目指すべきは「最大限のセキュリティ」ではなく「妥当なセキュリティ」です。

より良い意思決定を行う方法：

• 目標を明確にする。
• 推測ではなくデータで測定する。
• シンプルな解決策から始める。
• 確証がある場合にのみ最適化する。
• なぜその選択をしたのかを記録する。

かつて、数マイクロ秒を節約するためにJSONシリアライザを最適化しようとしたことがありました。その結果、300MBも増大するメモリリークが発生しました。プロファイラを使用したところ、真のボトルネックはネットワークI/Oであることが判明しました。コードを書き換える前に、必ずプロファイラを使用してください。

技術的負債は実在します。今日の近道は、明日のコストになります。乱雑なサービスを引き継いだ際、私たちは大規模なリライトは行いませんでした。代わりに、小さく継続的な変更を行いました。テストカバレッジを30%から78%に引き上げたことで、バグ修正の時間は4日から1.2日に短縮されました。

トレードオフは永続的なものではありません。自身の決定を再検討してください。最適化が依然として重要かどうかを確認しましょう。意図的に選択を行うことで、あらゆる面で中途半端なシステムになるのを防ぐことができます。

Source: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Optional learning community: https://t.me/GyaanSetuAi