构建出色的软件就像下棋一样。 有什么相似之处？ 嗯，就像在体育运动中一样，您必须在每步动作中保持主要目标在您的脑海中，在我们的案例中，是我们编写的代码行。 但是，任何体面的国际象棋棋手都会告诉您，如果您想赢得胜利，知道自己要做的事情是不够的，那么您就必须同样重视自己的胜利尝试。 例如，要设计世界一流的质量软件，程序员必须精通他们的方法。 简而言之，在编写代码之前请三思。 但这只是过程中的重要一步，建立可靠性不仅需要程序员投入很多精力（向Edward De Bono喊叫）。 那么，团队可以采取哪些实际步骤来实现这一目标？ 这是我的两分钱...
为最差的可靠性做好准备
在生活的大多数方面，我们都要做最坏的准备，软件开发也不例外。 考虑到优步和特斯拉的自动驾驶汽车，我很确定它们由最基本形式的软件组成，这些软件是带有一组指令的程序，例如决策构造。 您能想象如果他们的算法仅考虑完美的情况，例如道路上没有交通，没有路线改道，从不耗油不足，始终有停车位等情况，结果将是什么？ 工程团队必须问一个问题：“最糟糕的情况是什么？”，然后从那里开始工作。 如果您想在这个过程中激励您的团队，那么最好不要在演讲中提及墨菲定律。
“任何可能出错的地方都会出错” —墨菲定律
软件规范不仅要包含系统应做的工作，还必须考虑系统在异常情况下的行为。 我认为优秀的工程师应该遵循最佳实践来生产在这种情况下应采取有意义且有用的措施的软件。 如本简短系列文章的第1部分所述，影响可靠性的是软件故障，而不是软件故障。 软件故障的后果取决于故障的性质，因此拥有一份概述可能出错的事情以及在事情发生时可能产生的成本的文档非常重要。
大多数软件系统由其他子系统或子组件组成，并且每个软件系统都应具有可靠性要求。 我了解由于时间因素，此过程可能会变得非常昂贵。 降低成本的一种方法是通过测量这些各种子系统中的故障影响，并使用其来确定每个子系统的可靠性要求。 例如，在基本模块或子系统上设置与在支付交易子系统中相同的最大可靠性级别可能不是明智的选择。
可靠性规范应具有已识别的子系统，每个子系统可能发生的不同软件故障以及对这些故障后果的评估。
为异常处理做最坏的准备
我猜您已经知道异常是什么，但是无论如何我都会继续定义它。 这是在程序执行期间发生意外事件（通常但并非总是错误）的情况。 是否曾经编写过（或编码过）发出API请求的函数，并且没有考虑到发生任何类型的故障？ 异常处理对于诸如此类的事情非常有用。 值得庆幸的是，当今大多数编程语言都具有内置功能来帮助实现这一目标。 根据使用情况，您可以选择使用决策构造（if语句），或者通俗地使用“ Try”和“ Catch”块。 try / catch块是专门为处理异常而设计的，可能更多。
可以简单地在整个节目中编写try / catch块的代码，但这不一定会有所帮助。 您实际上可能在软件中造成效率低下的问题； 我们不想浪费像内存这样的系统资源。 这就是为什么可靠性规范如此重要的原因，它说明了我们如何进行异常编程，系统的哪些部分需要异常以及达到何种程度。 您的软件系统的某些部分可能需要嵌套的try / catch块，而其他部分则不需要。
这就是可靠性规范如此重要的原因，它说明了我们如何进行异常编程。 您的软件系统的某些部分可能需要嵌套的Try / Catch块，而其他部分则不需要。
通过防御性编程为最糟糕的情况做准备
我敢肯定，您之前已经听过这句话，也许这句话变得有些陈词滥调，但是我认为对于开发人员来说，这里有一个教训：
国防部赢得冠军-熊·布莱恩特（阿拉巴马州**足球教练）
这不仅仅是一个可爱的报价。 但是，我们确实要问一个问题，“编程中看起来像什么？”
防御性编程是一种程序开发方法，程序员可以假定防御程序中可能存在未检测到的错误或不一致之处-Ian Sommerville
例如，永远不要信任用户输入。 你不需要我告诉你，对吗？ 如果您有几年（甚至几个月）的发展经验，那么我相信您的经验在这方面是一位很好的老师。 我们必须进行编程，以使我们的系统以严格且防御性的方式处理所有传入的数据。
外部输入并不是我们唯一需要注意的事情。 如果您在团队中工作，最好通过积极的检查来接近其他开发人员的代码以及您自己的代码。 我在上一篇文章中提到的方程式应该成为您的新口头禅：
软件工程不佳===软件质量不佳
程序员有不同的思维方式和逻辑运用方式，这不是一件坏事。 但是，这种逻辑或思维方式可能以不好的方式转化为代码。 因此，最好实施某些样式，模式和组织代码的方式，以帮助防止软件故障以及从中恢复。
防御性编程的目标是防止错误，以使我们开发的软件即使在意外输入和用户动作发生的情况下也能保持较高的质量和性能。
嗯...我什至没有涉及测试。 我想我闻到了第3部分的气味。
话虽如此…
构建可靠的软件是艰苦的工作。 不仅如此，这是一个昂贵的过程，因为要对其进行计划和编程需要花费大量时间。 这不是一个人的工作，因为在质量方面，软件开发生命周期的不同方面必须朝着同一方向发展。 您可能需要在同行开发人员或团队其他成员中打上理想主义者的烙印。 但是我们必须能够看到通过，因为对于那些高度重视手工艺并了解其对最终产品及其用户的影响的人来说，构建可靠的软件是一项任务。
参考文献：
Ian Sommerville的软件工程