重新定义软件工程

任何一个senior的工程师都经历过junior的过程，所谓经验，都是内化的直觉，所谓原则，都是外化的经验。本文原文发布在Medium上，汇集了关于软件工程的经验和原则：开发过程、API设计和职业发展。正是读及文章最后一个原则促使我整理了本文，写给自己的同时，也相信本文可以重新定义学校课程中的软件工程，重新定义其他迫急解惑的心智模型。

开发过程

1. 代码不仅仅是用来执行的。代码是跨团队沟通的一种方式，也是向其他人描述问题解决方案的一种方式。代码的易读性并不是”有了更好“，而是代码的基本组成部分。这包括清晰地分解代码，选择自解释的变量名，并插入注释来描述任何隐含的内容。
2. 不要问你的 pull request 对下一次升职有什么好处，而要问你的 pull request对用户和社区有什么好处。不要为“显山露水”而努力。如果没有明显地完善产品，就不要添加任何功能。
3. 品味（Taste）也适用于代码。品味是一个约束满足的过程，这个约束就是对简单的渴望。保持对简单的偏爱。
4. 说“不”是可以的——仅仅因为别人请求某个功能并不意味着你应该去实现某个功能。每个功能都有超出最初实现的成本：维护成本、文档成本和用户认知成本。经常问一下：我们真的应该这样做吗？通常，答案是否定的。
5. 当你对支持新功能的请求说yes时，请记住，按用户请求的字面意思添加新功能通常不是最佳选择。用户专注于他们自己的特定功能，而你必须从整个项目的视角来考虑。通常，正确的答案是扩展现有的功能。
6. 投资于持续集成，并致力于单元测试的全面覆盖。确保所处的环境能让你充满信心地编写代码。如果情况不是这样，那么就先集中精力建立正确的基础设施。
7. 不要提前计划所有事情。快速试错，及时纠偏——确保你创造了一个这样的环境。
8. 软件是让困难的事情变得更容易。问题很难，并不意味着解决方案也很难。大多时候，工程师从解决方案出发思考问题，这样会引入不必要的复杂性（比如，让我们使用机器学习！让我们构建一个应用程序！让我们添加区块链吧！这些时候，可能有一种更简单但可能不太明显的替代方案）。在写代码之前，请确保没有更简单的解决方案。这是最基本的原则。
9. 避免隐式规则。你在开发中发现的隐式规则应该总是暴露出去，与他人分享或做成自动化。无论任何时候，当你发现了一个重复出现的准算法工作流程时，都应该设法将其正式化为一个文档，以便其他团队成员能够从经验中受益。此外，你应该自动化工作流程中的任何可以自动化的部分(例如，正确性检查)。
10. 在设计过程中，决策的总体影响应该被考虑进去，而不仅仅是你关注的部分——比如收入或增长。除了正在监视的度量之外，软件对用户和世界的总体影响是什么？是否有超出价值观的副作用？你如何解决这些问题，同时保持软件的有用性?

API设计

1. 你的API有用户，因此它有用户体验。在你做的每一个决定中，都要把用户放在心里。和你的用户共情，无论他们是初学者还是有经验的开发人员。
2. API的使用，要尽量减少用户的认知负担。自动化那些可以自动化的，最小化用户需要的操作和选择，隐藏那些不重要的选项，设计简单一致的工作流程来反映简单一致的心智模型。
3. 简单的事情应该保持简单，复杂的事情应该尽可能简单。不要为了小众功能而增加常用功能的认知负荷，即使是最低限度的。
4. 如果工作流程的认知负荷足够低，那么用户在完成一两次之后，就可以记住（不需要查找教程或文档）。
5. 寻求与领域专家或从业者的心智模型相匹配的API。有领域经验但没有API经验的人应该能够使用最少的文档直观地理解你的API（比如，查看几个代码示例，可用对象以及它们的签名）。
6. 参数的含义应该是可以理解的，而不需要任何关于底层实现的上下文。参数应该与用户理解问题的心智模型相关，而不是与代码中的实现细节相关。API只关心它解决的问题，而不是软件在后台如何工作。
7. 最强大的心智模型是模块化和层次化的：在高层次上简单，但在细节上精确。同样，一个好的API是模块化和层次化的：容易实现，但又富有表现力。在具有较少对象上的复杂签名和具有简单签名的较多对象之间需要权衡。好的API具有合适数量的对象，并且具有相当简单的签名。
8. API不可避免地反映了你的实现选择，特别是对数据结构的选择。要实现直观的API，你必须选择自然地适合当前领域的数据结构——即匹配领域专家的心智模型。
9. 有意识地设计端到端工作流程，而不是一组原子功能。大多数开发人员这样问：需要哪些功能？然后为这些功能设计配置选项。相反，应该问：这个工具的功能是什么？对于每个功能，用户操作的最佳顺序是什么？支持这个工作流程的最简单的API是什么？你的API中的原子选项应该能够满足工作流程中出现的明确需求——它们不应该被添加进来，而是”因为有人需要它”。
10. 错误消息以及API提供给用户的任何反馈通常都是API的一部分。交互性和反馈是用户体验的重要组成部分。谨慎设计API的错误消息。
11. 因为代码即通信，所以命名很重要——无论是项目还是变量。名字反映了你对问题的看法。避免过于通用的名称（比如，x、变量、参数），避免过于冗长和特定的命名模式，避免可能造成不必要混淆的术语（比如，主节点、从节点），并确保在命名选择上保持一致。命名一致性包括内部命名一致性（不要把其他地方称为“axis”的东西称为“dim”）和与问题领域的既定约定保持一致。在确定名称之前，请查阅领域专家使用的现有名称（或其他API）。
12. 文档是API用户体验的核心。文档不是一个附加组件。投资高质量的文档，你将看到比投资功能更高的回报。
13. 文档不应该讲解软件如何工作，它应该展示如何使用软件。展示端到端工作流程的代码示例，为每一个常见功能和API的关键功能展示代码示例。

职业发展

1. 职业生涯的进步不在于管理多少人，而在于产生多大影响：这个世界因你的工作有多大不同。
2. 软件开发是团队过程：不仅关乎技术能力，也关乎人际关系。做一个好队友。当你走自己的路时，要和别人保持联系。
3. 技术从来都不是中立的。如果你的工作对世界有任何影响，那么这种影响是有道德方向的。我们在软件产品中做出的看似无伤大雅的技术选择调节了技术的使用条件、使用动机、谁将受益、谁将受害。技术选择也是伦理选择。因此，对于你选择的技术，一定要深思熟虑其支持的价值观。为道德而设计。将你的价值观融入到你的创造中。永远不要这么想：我只是培养自己的技术能力，技术本身是中性的。并不是因为你构建它的方式决定了它将如何被使用。
4. 自我引导（Self-direction）——控制你的工作和环境——是生活满意度的关键。确保你给你周围的人足够的自我引导，确保你的职业选择给你带来更大的自主权。
5. 创造世界需要的东西——而不是你需要的东西。技术人员往往过着一种清高的生活，专注于满足自己特定需求的产品。寻找机会来扩展你的生活经验，这将使你更好地了解这个世界需要什么。
6. 在做任何有长期影响的选择时，选择你的价值观，而不是短期的私利和短暂的情绪——比如贪婪或恐惧。认识自己的价值观是什么，让它们指引你。
7. 当发现团队陷入冲突时，最好停下来共识团队共同的价值观和目标，并提醒团队，我们是在同一战线上的。
8. 生产力可以归结为快速决策和快速行动。这需要：a).良好的直觉，这来自于经验，以便在获得部分信息的情况下做出总体正确的决策；b).敏锐地意识到何时应该采取行动，何时应该谨慎等待更多信息，因为错误决策的代价将大于延迟的代价。在不同的环境中，关于速度和质量的最优决策权衡可能会有很大的差异。
9. 更快地做决定意味着在你的职业生涯中你会做出更多的决定，这会让你对选择的正确性有更强的直觉。经验是生产力的关键，而更高的生产力将为你提供更多的经验：一个正向反馈。
10. 在意识到自己缺乏直觉的情况下，遵循一些抽象的原则。在你的职业生涯中建立一个经过检验的原则清单。原则是形式化的直觉，这种直觉可以泛化到比原始场景更广泛的场景。

Eating Your Own Dog Food

“dogfooding”的概念源于20世纪80年代演员Lorne Greene把自己代言的狗粮喂给了自己狗。因此，人们使用自己正在生产的产品的想法被称为“吃自己的狗粮”，随着苹果、微软等公司的推动，软件行业采用这个短语来表示公司使用自己的产品。

支持“dogfooding”的理由是表明公司对自己的产品有信心，并且内部的广泛使用会更早发现bug。还有一个理由是让开发产品的人更熟悉产品，并在内部建立反馈机制。

反对“dogfooding”的理由是吃自己的狗粮无法理解和欣赏其他公司工具的优点。批评者也说，一些自豪地吹捧吃自己狗粮的公司同时表现出令人惊讶的傲慢程度和相应程度的无知。

总的来说，开源社区似乎实践了一种较弱的“dogfooding”形式。你对狗粮有什么看法？你们公司吃自己的狗粮吗？你觉得它有益吗？