ΠΘVΘΠΙΠΞ

ΠΘVΘΠΙΠΞ

Building a new internet together.

ソフトウェアバグはどこから来るのか?

私のキャリアのある時点で、トラックが取るルートを決定するソフトウェアシステムに携わる特権を得ました。プログラミングは常に楽しく創造的でしたが、これが初めて危険で怖いと感じた瞬間でもありました。トラックルーティングシステムのバグは、現実世界の物体が不適切に動作することを意味しました。スケジュールが遅れ、費用がかかり、顧客が怒ることになります。また、他のソフトウェアシステムとは異なり、再起動や再デプロイでは問題が解決されませんでした - 車両はすでに世界に出ており、クライアントに約束したスケジュールのためにルートを再起動することはできませんでした。

その結果、私たちは安全性と品質を非常に真剣に受け止めました。非常に強力なテストのバッテリーがあり、コードはシニアエンジニアによって綿密にレビューされ、QA チームもいましたが、それでもバグが発生しないわけではありませんでした。

バグ!= プログラミングエラー#

ソフトウェアエンジニアとして、私たちはプログラミングエラー(例:ヌルポインタ、配列の長さを超えたアイテムへのアクセスなど)が、私たちが注意を払うべき主要なバグであると考えるように訓練されています。私たちもこの種のバグを作りましたが、私が非常に早く学んだのは、これらを防ぐことが重要である一方で、本当に大きなバグはめったにクラッシュを引き起こさないということでした。むしろ、それらは私たちのルーティングの決定に関係していました。ヌルポインタはエラートラッキングツールによって捕捉され、修正は数分で再デプロイできます。ルーティングエラーは、ルートのパフォーマンスを慎重に分析した後でしか捕捉できず、しばしばルートの収益性を何週間も研究した後に発見されます。

バグは発生する#

ソフトウェアシステムが特定の複雑さの閾値に達すると、偶然にバグを導入することなく作業するのが難しくなります。これが起こる理由の一部は、システムの動作を特定することが不可能になるからです。もはや、システムがどのように動作すべきかを一人の頭の中に収める「仕様」は存在しません。代わりに、システムに依存する複数の当事者が異なる正しさの定義を持つことになります。

中には、システムの複雑さのレベルがそのようなポイントに達しないようにする技術があると主張する人もいるかもしれませんが、時にはすでに複雑さの閾値を超えたシステムが与えられることもあります。この記事は、これらのタイプのシステムについて扱っています。

理解できない仕様のシステムを安全に開発するには?#

あなたが大規模なソフトウェアシステムに取り組んでいて、「正しい動作」が何を意味するかを決定できる人がいない場合、どのように安全にシステムを修正できますか?実は、これを達成するためのシンプルで効果的な技術があり、私はこれを「3 つの変更」と呼んでいます。

3 つの変更#

コードベースに加える変更は、削除、追加、動作の変異の 3 つのグループに分けることができます。削除はシステムから動作を取り除きます(例:コードの削除)。追加はシステムに新しい動作を追加します(例:新機能の追加)、最後に動作の変異はシステムの動作を変更します。

動作 削除のためのテスト戦略#

削除を行うと、可能性は 2 つだけです。どちらかは、他のどこかで使用されている動作を削除しているか、どこでも使用されていない動作を削除しているかです。

最初の可能性はバグを生み出し、2 番目は本質的にデッドコードを削除していることになります。したがって、削除の正当性を確認することは、削除しているコードが他の誰かやシステムの他の部分で使用されていないことを確認することに等しいです。型チェッカーはここでほとんどの労力を行うため、実際には動作の純粋な削除は一般的にバグを生じる可能性が低いです。

動作追加のためのテスト戦略#

システムに動作を追加することは、しばしば「機能作業」と呼ばれ、1 つの素晴らしい特性があります。通常、新しい動作は、個人または密接に協力しているチームによって導入され、ほとんどの場合、新しい動作が正しいことを定義する仕様や方法があります。

これは素晴らしいことです。なぜなら、追加の正当性を確認することは、新しい動作が仕様に準拠していることを確認することに等しいからです。

新しい動作は通常、段階的にリリースされることも可能です(例:フィーチャーフラグを使用)ので、バグの影響をさらに減らすことができます。

動作変異のためのテスト戦略#

システムの動作を変更することは、3 つの変更タイプの中で最もリスクが高いです。システムを安全に変更する唯一の方法は、まず多くの可能な入力の下での動作、システムがどのような状態にあるか、そしてどのように失敗するかを十分に理解することです。

まとめ#

  • システムの動作を変異させるのは、システムの動作を本当に理解している場合を除いて行わないでください。
  • 新しい動作が既存の動作とは独立して簡単に追加できるようにシステムを設計してください。
  • 必要に応じてコードを簡単に削除できるようにシステムを設計してください。@tef は、削除しやすいコードを書く方法という投稿をしています。

ソフトウェアシステムを安全に変更するには?#

  • 3 種類の変更 あなたがソフトウェアシステムに加えるすべての変更は、以下の 3 つのバケットの 1 つ以上に分類できます
  • 動作の追加
  • 動作の変異
  • 動作の削除

bug-table.png

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。