写出好代码系列工程思维

软件开发过程充满了复杂性，前面提到的效率难题、可靠性难题主要是一个项目本身的难题，而软件开发中还有另一个难题是：业务到技术实现。换句话说，就是如何通过组织人进行编码来实现产品和技术的连接。

关于这个难题，结合我的经验来看，我有这样 5 点建议：都是项目、盯紧目标、提前计划、有效沟通和交付结果。在开发工作中，应该怎么理解和应用这 5 点建议呢？下面我们就来分别详细说明下。

1. 都是项目

用项目的视角去处理问题或业务，会有两点好处：一是培养你从整体看问题的习惯；二是通过做计划，提高你的时间管理能力。

我们都知道性能优化在任何一个项目中都非常重要。假设在你的某个项目中，经过你的努力优化，系统响应时间缩短了 60%，TPS 提升了 2 倍。这个结果说明了什么呢？系统响应时间缩短、吞吐量提升是不是就意味着能满足需求呢？

实际上，这就是只看到局部而忘记了整体。的确，性能优化很重要，但是在当前的项目阶段中，性能优化是不是你需要达到的目标？还是说你的目标只是为了优化而优化？

而当你用项目视角去重新看待这个问题时，你就会发现，优化只是一个手段和方法，在合适的阶段引入才是最重要的。比如，你应该提前为项目大促做准备，当大促流量暴增或者某接口超时比例过高时，如果不进行优化，系统可能会存在风险。这样，你不仅会预留一些时间来重新做代码审查，也会看到项目的成败关键并不只是每一次新增功能的完成与否。

2. 盯紧目标

盯紧目标主要体现在两个层面：一是负责到底，二是不断调校。

负责到底是基本要求。无论是写代码，还是做设计，只要是定下一个目标，就应该始终盯紧目标。比如，你最近要写一个文件上传的模块代码，调研了很多上传方法，然后觉得都特别有意思，想要都试验一次，结果你发现用的底层框架并不支持这些方法；于是你转而研究起了框架，又发现这些框架也很有意思，想要做下源码分析，再动手试试……可时间一天一天过去，你却发现文件上传的代码还是没有写完。

不断调校是基于事实的合理改变。有时，在项目的推进过程中，可能需要修改目标。比如说，需要临时修改紧急线上问题，而这对当前的项目可能会造成一些影响，这就需要你敢于基于事实来做合理的评估，而不是固执地认为目标定好以后就不允许修改了。

3. 提前计划

很多开发人员最常犯的一个错误就是：拿到需求直接开始编码，计划便是不用计划，用最快的速度去实现代码即可，而这往往会导致更多问题的出现。在工作中，你也经常会发现很多开发人员都自诩自己很懂得时间管理，但是难度几乎相同的项目，有的人经常延期，而有的人每次都能按时上线。这是为什么呢？一个很重要的原因就是，这些按时交付的人做事往往具备一个共同特质：做事有计划。

做事有计划是说，要在有限的条件下提前做好分析，并在一个相对固定的时间周期内合理安排任务。简单来说，就是要搞清楚熟悉哪些、不熟悉哪些、哪些可控、哪些不可控……这样就能提前规避风险，并从整体上提升交付效率和质量。

4. 有效沟通

如何把复杂的技术问题简单准确地表达出来，让别人听懂并且不产生误解，其实是每个开发人员都会面临的挑战。

比如，下面是一个研发 A 同学在遇到线上技术问题时，在群里面求助的情况。

A 同学：大佬们，新架构上线后，数据库不动了。
A 同学：业务方反馈说店铺活动有问题。
其他同学：各种问题讨论中，上下文信息很多……
A 同学：数据库有问题，报备风险。
B 同学：先把问题描述清楚。

A 同学此时的心理状态：产品都出问题了，大家赶紧来一起看一下，反正不是我的问题，我只是恰好被提及了，我也把日志和截图发群里面了，谁负责的问题谁自己看。

B 同学可能的心理状态：这啥问题啊，还得自己翻聊天记录看，现在没空，也没接到电话，先不处理。

这里恰好反映了两种典型的被动的沟通心态。一种就是 A 同学的只抛问题不找关联人，另一种则是 B 同学的要看问题的轻重缓急再处理。

你可能也发现了，在平时的沟通群里有很多类似这样的对话，几乎都是在做无效沟通，甚至一个问题出现了几个小时，既没有搞清楚问题是什么，也没有找到责任人是谁。

而实际上，当你具备了软件工程思维后，提问方式可以变为：“现在有一个问题需要解决，问题现象是 xxx，业务方的预期是 xxx，实际看到的是 xxx，不符合预期，从日志和报错看可能是 xxx 出问题了。由于 xxx 项目上线时间紧迫，急需解决，在线等。”从定义问题开始，到业务方期望的目标是什么、实际上发生了什么、收集到了哪些信息，再到自己初步分析的思路是什么，最后自己的计划是什么，都清晰而又系统地表达出来了。

这就是一个典型的有效沟通过程。这种解决思路可以大大提升你的沟通效率，直至问题高效解决。

5. 交付结果

在工作中，你可能往往因为编码任务太重，以为代码只要写完，任务就算是做完了，领导或项目组的成员都会自动知道你的项目结果。这其实是对交付结果最大的误解。实际上软件工程早已对此提出了一种解决办法——发布你的产品，用现在流行的话讲，叫具备闭环思维。

你是否遇到过这样的场景：参加一个需求评审，会上大家各抒己见发表意见却没有提出什么结论和待处理项，等到再次评审的时候，却发现问题越来越多，很多讨论过的问题需要从头再开始讨论。

如果我们把上面的需求评审会当成一个项目来看，这就是没有发布产品（也就是得到结论），形成不了闭环，导致项目无法完成，那必然也解决不了问题。

其实，交付结果意味着你需要主动结束项目，包括结束确认、结束反馈、测试验证是否通过等，这和等待项目自动结束是完全不同的一种思考方式。

换句话说，这些年软件工程的知识一直在更新迭代中，其“过程+方法+工具”的本质并没有变，无非是各种方法和工具的推陈出新。

为了更好地应用软件工程方法，你应该牢记下面的公式：

软件开发过程 = 定义与分析 + 设计 + 实现 + 测试 + 交付 + 维护；

软件开发 ≠ 软件编码；

软件工程 = 过程 + 方法 +工具。

实际上，软件工程对过程的改进思维，能够应用于很多方面，包括工作中的代码编写、架构设计、需求分析、制订计划、项目管理等。无论你是一个普通工程师还是项目管理者，都应该学点软件工程方法。

引用

https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6865