为什么写了多年代码，还是没形成自己的工程思维？

【引】如果认为“善战者无赫赫之功”是错的，如果项目的风平浪静全部被归为没有难度，如果只有不断救火的人才能得到赏识，如果只有在鸡飞狗跳的环境中才能得到成长的话， 就不要看本文了。

成长的关键不是关于多年的经验，不是关于懂得更多的语言，也不是关于编写更好的代码。程序员越成熟，就越冷静。我在很多人身上看到了这一点，最终开始在自己身上也看到了这一点。当有系统出问题时，自己不再惊慌失措，也不必为每一个error而紧张，更不是盲目地匆忙解决问题。

这需要心态的转变，需要心智模型的支撑，老码农整理了工作中常用的10个心智模型，希望对大家有帮助。

图片

1. 问题澄清

如果一个程序员认为自己的工作只是编写代码，然后进行测试和部署，那可能不会问什么问题。而成熟的标志在于首先需要问正确的问题。一旦这样做了，弄清楚如何编写代码就变容易了。

如果习惯于每当收到新的通知时就立即开始编写代码，无论是 bug 修复还是功能更新，就无法停下来思考更大的问题，或者代码的哪些部分可能会受到影响。在影响分析上花费更多的时间比在编写代码上绞尽脑汁要重要得多。影响分析不仅仅意味着代码分析，它还意味着分析业务 / 功能 / 操作的影响。编写代码实际上是最底层的任务。

2.根因分析

每个工程师对关闭大量的 bug 都感觉良好，仿佛给他们一种成就感。实际上，并不要急于修复这个 bug，更应该关注的是为什么。

这是一个反复出现的问题吗？ 有什么模式吗？检查监控工具、仪表板和日志。他们花更多的时间考虑副作用，而不仅仅是解决问题，不喜欢在没有找到根本原因的情况下结束一天的工作。

到目前为止，许多人可能已经明白了为什么 RCA (根本原因分析) 对于是如此重要。不只是解决问题，还要确保同样的问题不会再次发生。

当我们谈论的时候，为那些讨厌混乱并且喜欢 “重构” 的开发人员建一个 “极简主义清单”。

3. 持续改进

代码运行并不意味着作业已经完成，在很长一段时间里，人们认为程序员的工作很简单： 做出改变，测试它，提高公关，部署，然后继续前进。只要代码功能正确，没有破坏任何东西，就认为它是成功的。

读读自己的代码，问问自己ーー这是否可以通过任何方式改进？让代码比你能够找到的更好。 因为六个月后，当回到自己的代码时，要么会感谢自己编写了干净、可维护的逻辑，要么会讨厌自己留下这么一团糟的代码。

4. 文档协作

有人可能认为证明自己技能的最好方法就是自己解决问题。如果可以修复一个 bug 或实现一个功能特性而不需要寻求帮助，就认为这是一个胜利。但是，软件工程是一项团队活动。

我们不仅仅是解决问题，还创建其他人可以理解、维护和构建的解决方案。如果你是唯一了解解决方案的人，那么这就不是真正的解决方案ーー这是一个未来的问题。解决这个问题，需要编写清晰的文档，在小组讨论中分享知识。

“我们怎样才能让整个团队都适应这种情况呢？”

因为归根结底，衡量一个工程师不仅要看他能做什么，还要看如何为他人授权。

图片

5. 夯实基础

有人人好的工程师不是那些知道得最多的人，而是那些学得最快的人。一名更好的工程师意味着尽可能快地学习更多的语言、框架和工具，只是为了保持领先。每一项新技术都像是一场竞赛ーー React、 Kubernetes、 GraphQL、 AWS... ... 人们不停地从一个教程跳到另一个教程。

成长的标志是把注意力集中在基本原理上，算法，系统设计和解决问题的方法。记的东西并不多，而是知道如何快速找到答案.技术会改变，但核心原理不会改变.

“重要的不是你知道多少，而是在你需要的时候，你能以多快的速度学到你需要的东西。”没有什么比赛，也没有过比赛。唯一需要竞争的人就是你自己。把注意力集中在每天在基础上做得更好一点，那么其他的一切都会开始步入正轨。

6. 能够担责

如果看到一个问题，并认为‘应该有人来解决这个问题’，那么那个人就是你自己。不能习惯于等待，等待任务，等待批准，等待有人告诉我该做什么。

不是忽略问题，不仅仅是报告问题。而不是等待指示。这是一种所有权心态。停止等待，负起责任，开始拥有。当前前提是授权是否充分。

7. 设计先行

不要急于写代码，不急于求成。

在实施之前概述、讨论和验证想法，在how之前问why，先设计后构建。解决问题，而不仅仅是写代码，编写代码并不困难，重要的是编写正确的代码。

先分析问题，再编码。

8. 业务价值

很多人只关注完成任务，编写代码，推动继续前进。于是，很快就成了项目经理的得力助手。

能否看到更大的图景？ 这个功能如何帮助用户？ 是否提高了收入、保留率或效率？ 这是解决实际问题的最好方法吗？

代码不仅仅是代码，它还驱动着业务价值，要理解这一点。了解软件的业务方面，能见度要高。

图片

9. 防患未然

程序员通常以响应模式是等待 bug 出现，然后立即进行修复。

但是，我们可以不等着事情发生变化，而是未雨绸缪。这个系统可能出现什么问题？

故障点在哪里？

怎样才能确保这不会成为紧急情况？

面向失败而设计，假设事情会在某个时候出错ーー服务器会崩溃，依赖关系会失败，用户会犯错误。不要抱最好的预期，而是设计有弹性的系统，例如网络故障的重试和回退，防止连锁故障的断路器，速率限制和流量处理峰，设立监测和警报。

不要在出现问题时才检查日志，设置实时监控 (Grafana、 Prometheus、 Datadog 等) ，以便在用户注意到问题之前发现问题。例入，随着时间的推移，数据库查询变得越来越慢，我们要很早就注意到这一点，并在生产环境崩溃之前对其进行优化。

不要手动检查问题，而是编写自动化测试和 CI/CD 流水线，强制执行 linting 和静态分析，以便在代码合并之前就捕捉到坏的模式。不仅是解决问题，而是阻止问题发生。

10. 自动化工具

如果工程师经常手工重复同样的任务，那是不明白时间的价值。我们可以消除不必要的工作，节省时间，减少错误。记录解决方案，让其他人不必重新发明轮子，使团队能够更快地行动。

编写清晰的文档，以便下一个人能更快上岗。维护 README 文件、 API 规范和故障排除指南。建立自助服务工具，例如构建内部仪表板、脚本或机器人，以便团队能够自我服务。

下次手动做某事时，问问自己：

• 可以自动化吗？
• 可以记录下来，这样其他人就不用问了吗？
• 能否构建一个工具，使整个团队更容易做到这一点？

做一个容易相处的人，使合作变得毫不费力，沟通变得清晰，解决问题变得更加顺畅。

让我们成为那个理想的伙伴吧——

• 很好地记录事情，并帮助他人成长。
• 代码是干净的，可读的，可维护的。
• 把反馈当作提高的机会。
• 尊重不同观点，考虑其他解决方案。
• 负起责任，专注于解决问题，而不是指责。
• 通过简洁有效的更新使人们了解最新情况