软件开发“自我毁灭”的七宗罪

软件开发是一门具有挑战性的学科，它建立在数以百万计的参数、变量、库以及更多必须绝对正确的因素之上。即便是一个字符不合适，整个堆栈也会随之瓦解。

多年来，软件开发团队已经想出了一些完成工作的规则。从复杂的方法论到新兴的学科和哲学，软件开发的规则手册使每个人都能够协作，并以有效的方式到达终点。然而，即便如此，仍然存在失败模式：有时是这些方法被误用了，或是好的想法过于偏向理论化；有时开发者只是忘记了他们应该做什么，或是故意为之。

软件开发中的这些错误几乎可以破坏任何项目。因此，如果想要确保您的团队能够构建伟大的项目，那么是时候停下来考虑一下以下错误行为了。

1、选择错误的方法   

所有的软件开发方法都有狂热的拥趸，他们热衷于那些定义自己最喜欢的团队组织方式的规则。但问题往往是如何为您的团队选择合适的工具。

一个很大的错误是从高层强加这些规则。如果程序员是另一种方法的忠实信徒，那么当他们被迫使用另一种方法时，他们通常会抱怨和发牢骚。另一个错误是让程序员自由地选择他们最喜欢的方法，然而这可能并不是对整个团队最好的方法。

选择正确的方法并不能解决所有的问题，但是它可以减少组织工作流程时产生的摩擦。团队将了解他们的角色，以及他们将如何在其中编写代码。

2、忽略可扩展性   

一些软件开发问题可以稍后修复，但这绝不包括构建一个能够有效扩展以处理数百万或数十亿个事件的应用程序。当应用程序最终全面运行时，创建没有瓶颈的有效代码需要足够的深谋远虑和高层领导的支持。这不是以后用一些有针对性的编码和虚拟管道就能解决的问题。

算法和数据结构需要从一开始就进行规划。这意味着架构师和管理层需要仔细考虑将为每个用户存储和处理的数据。当 100 万或 10 亿用户出现时，信息洪流会淹没哪一层？我们该如何提前为这些时刻做好计划呢？

有时候，这种架构上的深谋远虑意味着扼杀一些伟大的想法。有时，管理层需要权衡大规模交付功能的收益和成本。有些数据分析在大范围内并不适用。一些公式随着用户的增加呈指数级增长。计算使硬件不堪重负，并阻塞了通信。

开发者并不总是想要考虑大局。他们很容易就会一头扎进去开始创作。但是聪明的开发团队和管理者会花时间预测这些问题，因为如果他们不这样做，就会面临失败的结局。

3、沉迷最新趋势   

众所周知，软件开发人员很容易被新奇的想法所吸引。也许它是一种提供更复杂查询的新型数据库；也许它是一种新的编程语言，可以修复旧语言造成的所有错误。

有时候这些想法是有价值的。然而，很多时候，由于每个人都试图学习新技术，最终会减慢开发速度。有时候，新想法中会存在隐藏的缺陷，只有在项目必须交付之前，每个人都投入到工作中之后，这些缺陷才会显现出来。

谨慎往往是采用新技术的最佳准则。这也是一些规模最大、历史最悠久的公司仍在继续运行由 COBOL 编写的软件的原因所在。趋势变化无常，但运行代码中的工作逻辑不会过时。

4、保留过多的数据   

程序员是天生的囤积狂，他们喜欢储存信息以备不时之需，而此举可能会导致安全漏洞或侵犯用户隐私。

对于出生日期或其他详细个人信息，问题可能更大。一些领域（如财务记录或健康记录）受到严格监管，更容易违反规定。

好的软件架构需要提前计划，以尽量减少存储的数据量。它可以保护每个人，并节省存储费用，甚至可以通过减少移动数据量来加快系统速度。

5、外包错误的工作 

关于究竟是自行构建还是购买软件的争论由来已久，目前尚无明确定论。然而，软件开发人员的选择往往很糟糕。也许有一个价格合理的完美解决方案，但他们却不舍得把自己的定制堆栈与内部团队闲置一边。相反的情况也会发生。一些管理者购买了外部供应商的产品线，结果却眼睁睁地看着供应商在锁定完成后大幅提高价格。

不幸的是，对于软件开发团队及其管理者来说，决定使用哪种外部工具是一个持续的挑战。利用合适的外部资源是天才之举，但选择了错误的供应商则是通往高价监狱的门票。

6、忽略测试   

高效的软件开发人员及其管理者都知道，测试是一个持续的挑战，就像编写递归代码或设计优雅的数据结构一样，是工作的一部分。测试过程应该从一开始就包含在内，因为单元测试和集成测试对于确保代码在整个开发过程中保持可行性至关重要。

测试对于处理大规模负载也很重要。当我们是唯一的用户时，编写在桌面上运行顺畅的代码十分容易。如果应用程序拥有数百、数千甚至数十万用户，则需要确保代码是高效的，且部署能够处理大规模负载。

许多团队会引入质量保证测试人员，以发现并纠正程序员所犯的错误。比如说，他们知道如何将一个参数设置为 0，只是为了看看它是否会导致除 0 错误（divide-by-zero error）。当用例变得如此复杂，以至于任何一个人都很难想到所有的变化并编写干净的代码来预测它们时，这种对测试的持续关注是必不可少的。

7、低估了计划的力量   

大多数代码在构建前期都需要进行一定的计划。但大多数程序员通常只是想直接进入并开始编写代码。

资深程序员的经验告诉我们，最好的步骤是停下来，计划，测试计划，然后再完善计划。写计划可能看起来很乏味，但当你进行抽象思考时，尝试新想法的速度可能会快 10 倍。

计划还意味着包括来自其他团队和涉众的输入。他们将是将来使用代码的人，因此花时间讨论项目并了解他们的需求，将在之后避免大量的挫折。这是避免上述列出的许多错误的最好方法。