这是一位网红科学家给广大程序员精心总结的33条建议:

（一）关于开发流程

（1）代码不仅仅是用来运行的。代码也是一种跨团队交流的方式，一种是向他人描述一个问题解决方案的方式。易读的代码并不是“有则更好、没有也行”的东西，而是编写代码最根本的部分之一。要想确保代码的易读性，就涉及到清晰地分解代码、选择恰当的自解释变量名、通过添加注释来描述所有隐含内容。

（2）不要只想着你的拉请求（pull request）能为你的下一次职场晋升带来什么帮助，而要想着你的拉请求能为你的用户和社区带来什么。如果一项功能对于实现这个产品想要实现的目的没有明显的帮助，就不要添加这个功能。

（3）要保持对简单性的偏爱。

（4）要学会拒绝。并不是说有人要求做某个功能就意味着你就应该这么做。开发每个功能都需要投入一定的成本：维护成本、文档成本和用户认知成本。要时刻问自己这样的问题：我们真的应该这样做吗? 答案通常是否定的。

（5）当你准备答应满足对一个新的使用场景的支持时，要记住，添加用户表面上需要满足的需求通常不是最优选择。用户关注的是他们自己的特定使用场景，你必须从整个项目的角度出发，兼顾产品的整体愿景。通常，正确的做法是基于现有的功能特性进行拓展

（6）投入精力持续集成，以实现完整的单元测试覆盖为目标。确保你处在一个可以信心满满地写代码的环境中；如果不是这样，你首先需要构建一个正确的基础架构。

（7）不一定非要提前规划好一切。先测试一下，看看效果怎样。这样可以尽早避免做出错误的选择。当然，你首先要确保打造了一个能够实现这一点的开发环境。

（8）好的软件能让困难的事情变得简单。一个问题乍一看很困难，并不意味着对应的解决方案必须很复杂或难用。在很多情况下，工程师会习惯性给出的解决方案非常复杂，而实际上是有更简单容易的解决方案的，只是这个简单的解决方案可能没那么显而易见。在编写代码之前，请确保你所选择的解决方案是最简单的解决方案。

（9）避免隐性规则。要将你形成的所有隐性规则都变成显性规则，并与他人共享，或让它自动化。当你发现自己提出了一个反复出现的、准算法工作流时，你应该想办法将这个流程标准化并形成流程文档固定下来，这样其他团队成员也能够从中受益。此外，对于可以自动化的工作流，你应该在软件中尽量让其自动化。

（10）在设计过程中，要将所选择方案的整体影响考虑进去，而不仅仅考虑你关注的那些方面，比如营收或增长。除了你正在监控的指标外，你的软件对用户以及整个世界还会产生哪些影响? 是不是存在一些不好的副作用? 在确保软件可用性的同时，你能做什么来解决这些问题呢?

（二）关于 API 设计

（11）你的 API 是有用户的，因此它也涉及到用户体验。在你做的每一个决策中，都要将用户考虑进去。要站在用户的角度考虑问题，无论用户是小白还是经验丰富的开发人员。

（12）要尽量减少用户在使用产品 API 过程中存在的认知负荷。自动化可以自动化的东西，让用户需要做的操作和选择最少化，不显示不重要的选项，设计能反映简单一致思维模型的简单一致的工作流。

（13）简单的事情要简单处理，复杂的事情尽可能简单化。不要为了少量特殊的使用场景而增加普通使用场景的认知负荷。

（14）如果一个工作流的认知负荷足够低，那么用户在使用一两次后就能够凭记忆完成操作 ，而无需查找教程文档。

（15）努力做出与领域专家和实践者的心智模型相匹配的 API。有领域经验但没有使用过你的API 的人应该通过借助最少的说明文档就能直观地了解你的 API， 比如通常通过查看一些代码示例、看看哪些对象可用以及它们的特征是什么就能很好地了解你的 API。

（16）一个参数的含义应该在不需要任何关于底层实现背景信息的情况下就能很容易理解。必须由用户指定的参数应该与用户关于这个问题的心理模型相关，而不是与代码中的实现细节相关。API 的核心在于它要解决的问题，与软件在后台的工作流程是没有关系的。

（17）最强大的心智模型是模块化、有层次化的：在高层次上很简单，在细节上很精确。同理，一个好的 API 也应该是模块化和层次化的：容易使用、富有表现力。一个好的 API 要有合理数量的对象，并具有简单的特性。

（18）你的 API 是你选择的实现方式的必然反映，特别是你选择的数据结构。要实现一个直观的 API，你必须选择适合相关领域的数据结构，即与领域专家的心智模型相匹配。

（19）要有意识地设计端到端工作流，而非一组原子特性。大多数开发人员在设计 API 时都会问：应该提供哪些功能特性? 让我们为这些功能提供配置选项吧。实际上，开发人员正确的问法应该是：这个工具的使用场景有哪些？ 对于每个使用场景，用户的最佳操作顺序是什么? 能够支持这个工作流的最简单的 API 是什么?

（20）出错消息以及在与 API 交互过程中向用户提供的任何反馈都是 API 的一部分。交互性和反馈是用户体验中不可缺少的一部分。你需要谨慎的设计 API 的出错消息。

（21）因为代码就是交流，因此命名很重要，不管是命名项目还是命名变量都是如此。名称反映了你对一个问题的思考方式。避免使用过于通用的名称，避免使用过于冗长的命名模式，避免使用可能造成不必要误解的术语 ，确保你的命名选择上是前后一致的。命名一致性既意味着内部命名一致性，也意味着与该问题所在领域的既定规范保持一致。在确定名称之前，请确保查找该领域专家已经在使用的名称。

（22）文档是 API 用户体验的关键。它不是一个附加部件。投入精力写出高质量的文档，这能带来的回报比开发更多功能带来的回报更高。

（23）告诉用户不如直接表现给用户：你的文档不应该讨论软件是如何工作的，而是应该直接展示如何使用这个软件。展示端到端工作流的代码示例；为你的API 的每个常见使用场景和关键特性展示代码示例。

（三）关于软件工程师的职业生涯

（24）事业上的进步不在于你管理多少人，而是在于你发挥了多大影响力：一个有你的工作的世界和一个没有你的工作的世界之间有什么差别。

（25）软件开发需要团队协同作战，团队协作关系的好坏与技术能力的高低同样重要。做一个好队友。在你工作的时候，要和团队其他人保持沟通。

（26）技术从来都不是中立的。如果你的工作会对世界产生任何影响的话，那么这种影响是有道德指向的。我们在软件产品中做出的看似无伤大雅的技术选择有可能会影响获得技术的条件、产品使用动机、谁将从中受益、谁将受损。技术选择也是伦理选择。因此，对于你希望自己的选择支持什么样的价值，一定要做到深思熟虑和明确。基于道德伦理进行设计，把你的价值观融入产品中。永远不要这样想：我只是在开发一个技术，这个技术本身是中性的。

（27）自我引导是获得生活满足感的关键。确保你给你周围的人足够的自我引导。

（28）打造世界真正需要的东西，而不仅仅是打造你希望拥有的东西。很多时候，技术人员会专注于开发满足他们自己的特定需求的产品。寻找能够拓宽你生活经验的机会，这能让你更好地看到世界需要什么。

（29）当做会产生长期影响的选择时，将你的价值观置于短期的自我利益和情绪之上，比如贪婪或恐惧。确定你的价值观是什么，让价值观来引导你。

（30）当我们发现自己陷入冲突时，不妨停下来寻找我们共同的价值观和共同的目标，并提醒自己我们是站在同一条战线上。

（31）生产力可以归结为快速决策和偏好行动。这需要：①良好的直觉，这主要来自经验，这样就能在信息不完整的情况下做出正确的决策 ; ②对何时要谨慎前进或再等获得更多信息后再前进有敏锐的意识，因为一个错误的决策代价要高于等待的代价。

（32）更快地做决策意味着你在职业生涯中能做出更多决策，这能让你在判断选项时有更好的直觉。经验是生产力的关键，更高的生产力又能反过来给你带来更丰富的经验：这是一个良性循环。

（33）在你意识到自己直觉不准的情况下，坚持抽象原则。在你的职业生涯中，打造一个经检验被证明可靠的原则清单。原则是定形的直觉，适用的场景非常广泛 。