掌握软件工程的艺术

软件工程最佳实践：思维模型

让我们从几个简单的事实开始。首先：软件工程很困难。其次：软件工程也是一种艺术形式，经常感觉像是一个人的任务。虽然独自解决编程问题往往感觉是"更容易"的方式，但这并不总是"最好"的方式——特别是从长远来看。

大家好。我叫Shan Huang，是Forma Cloud的创始人兼首席执行官。在我的职业生涯中，我一直深度参与软件工程。从我早期作为个人贡献者的日子，到我最近担任负责领导大型团队和项目的经理和高管的角色，我从各个角度都见过软件开发过程。我利用这些经验创建了软件工程思维模型（或"SEMM"）。SEMM将可能非常混乱的操作变成有组织、精简和高效的东西。思维模型由软件工程最佳实践组成，确保我们的代码库能够达到最佳状态——不仅是现在，而是从长远来看。

自成立以来，Forma Cloud一直利用SEMM。我们的领导层和软件工程师都接受了SEMM，我们的结果不言而喻。似乎严格的软件工程模型意味着更慢的开发过程，但实际上恰恰相反。在Forma Cloud使用SEMM已经产生了更易理解的代码库，最重要的是，错误大大减少。综合起来，这在我们的软件工程项目中节省了大量时间。

我想在这篇文章中与您分享我的软件工程思维模型。不过，在我深入SEMM的细节之前，让我们讨论一下编程团队在'旧'软件工程模型下运作时可能遇到的一些问题。

软件工程不仅仅是解决今天的问题

很多程序员面临的问题之一是快速行动的压力。很容易陷入短期思维。任其发展，软件开发过程往往最终变成这样：

• 识别问题。
• 解决该问题。
• 转到下一个问题并重复。

这无疑是一种非常令人满意的做法——毕竟，您正在解决问题并记录代码行。麻烦的是，如果这些问题是孤立解决的，它们可能只是部分修复。这在大型和/或混乱的代码库中尤其如此——您可能认为您正在解决一个问题，但那个'问题'可能只是因为逻辑上需要存在来解决其他问题。

这里有一个例子来说明这一点。

软件工程警示故事：当随机睡眠定时器实际上并不随机时

注意：以下是基于我在行业中先前观察的真实故事。为了匿名目的，一些细节已被省略或简化。

几年前，X公司运行一个基于数字用户ID和私人PIN管理客户数据的程序。有一天，一名软件工程师正在查看代码库，试图提高产品效率，注意到有一行代码只是让程序睡眠一秒钟。每次处理用户ID和PIN时，整个后端都会睡眠。没有注释解释这一点，对工程师来说这没有任何合理意义。工程师假设这是开发故障排除的遗留，不再需要。所以，遵循上面的三步模型（发现问题，修复问题，重复），工程师删除了导致程序睡眠的行。似乎没有其他问题出现，所以工程师继续前进。

问题是：那一秒的睡眠实际上确实有目的。当创建ID和PIN组合时，它使用时间戳作为变量来帮助随机化。睡眠是为了确保没有用户ID/PIN组合在相同的时间戳创建。通过删除使后端睡眠的行，工程师无意中创建了一种情况，可以猜测连续用户ID的PIN。不幸的是，对于X公司来说，这个问题如此微妙，以至于他们花了很长时间才注意到它正在发生。不幸的是，黑客更快地弄清楚了这一点。这最终让X公司在长期内付出了很多代价——财务上以及声誉上。

这个问题的发生是因为X公司没有一个确保每个人都在一起工作的软件工程程序。虽然这种情况可能对X公司来说是独特的，但围绕软件开发缺乏严格性太常见了。这正是我开发我们所有工程师都遵循的严格思维模型的原因——这里没有人希望Forma Cloud像X公司一样。

通过软件工程师思维模型释放潜力并加速团队成长

Forma Cloud的软件工程模型

Forma Cloud使用我正式化的10步软件工程思维模型，而不是我们上面谈到的非正式3步模型。以下是步骤：

• 理解并确认问题和解决方案
• 创建包含需求和回退计划的设计文档
• 与团队讨论和批准
• 实际编码（在开发环境中）
• 内部演示和批准
• 开发维护功能（配置/警报/指标）
• 创建或修改文档
• 签字会议并将代码推广到生产环境
• 宣布并获得认可
• 定义任何长尾或下一步任务

虽然SEMM有一个顺序，但它不必完全是一种自上而下的方法，其中每个编程任务都必须执行每个步骤。Forma Cloud员工理解这些都是需要考虑的重要方面，但根据手头的问题，他们可以根据需要跳过步骤（或回到之前的步骤）。虽然这些步骤都很重要，但它们并不像听起来那样耗时。

SEMM所做的是让软件工程师作为团队有意识地完成项目，而不是作为不知道其他贡献者在做什么的个人。工程师和经理都熟练掌握SEMM，所以他们可以就工程师正在做的工作说同样的语言。这赋予工程师在他们正在做的事情上的灵活性，并给经理们信任这些工程师理解从Forma Cloud的角度来看什么是好质量的代码。这允许团队有灵活性理解什么是理想的，以及根据现实调整的灵活性。

在Forma Cloud实施软件工程思维模型

让我们更详细地看看SEMM的各个部分。

许多程序员将编码视为专门的第四步工作——毕竟，坐下来编写代码是有趣的部分。但是当我们走过这些步骤时，想想X公司的问题。如果X公司像Forma Cloud一样谨慎，他们在生产中永远不会有那个问题。

前三个步骤（理解、设计和讨论解决方案）都是关于沟通的。如果程序员识别出一个问题（或被分配解决一个问题），他们的第一步是确认究竟什么是问题，并描述他们将如何解决它。这与木工中的老"测量两次，切割一次"心态非常一致——我们在任何手指触及键盘之前谈论问题并确定我们将如何修复它的范围。这有两个优势。首先，它确保我们不会无意中以破坏其他东西的方式修复某些东西。

其次，其他团队成员可能以前解决过类似的问题，并有一种可能更快修复问题的新颖方法。如果X公司只做了这三个步骤，他们永远不会有他们遇到的问题。

第四至第八步（编写代码、测试/监控、文档和推广）是我们之前3步过程的更长方式。我们在沙盒环境中构建代码并观察变化。我们分享我们的工作，让其他人尝试找到问题。只有在完整的批准轮次后，任何东西才会被推广到生产环境。

第九步（获得认可）很重要，经常被忽视。这个软件开发过程的很多内容都是关于沟通的，所以这一步有助于向公司的每个人——不仅仅是软件工程师——社交化变更。但这一步也是关于承认辛勤工作。当代码被推广到生产环境时，我们与整个公司分享该信息，并给予应得的认可。

在最后一步（定义长尾/下一步）中，我们展望未来。当问题得到解决时，我们仍有工作要做。在大型复杂程序和代码库中，变更本质上是渐进的。所以，第十步允许我们看看接下来需要发生什么。这可能是清理步骤，或者可能是我们在下一个功能上重新开始的过程中的点。

结论

在Forma Cloud，我们为我们的软件工程感到非常自豪。我开发SEMM是为了帮助最大化我们团队创造伟大产品的能力，并且很高兴看到它如此成功。有效的团队合作和沟通对这一努力至关重要。SEMM确保每个人都清楚理解他们的个人角色和责任以及其他人的角色和责任。团队合作、文档记录和严格遵守注释有助于理解我们现在和未来很长时间内编写的代码。对协作的依赖也帮助我们消除延迟、返工，最重要的是，错误。团队成员相互支持，在我们产品的各个方面提供宝贵的见解和指导。