发展历程
- 代码不只是要执行。 代码也是跨团队交流的一种方式，一种向他人描述问题解决方案的方式。 可读代码不是一个好习惯，它是编写代码的基础。 这涉及到清楚地分解代码，选择不言自明的变量名以及插入注释以描述任何隐式的内容。
- 不要问您的请求请求可以为您的下一个促销做些什么，不要问您的请求请求可以为您的用户和社区做些什么。 不惜一切代价避免“显着贡献”。 如果不能明显增加产品用途，请不要添加任何功能。
- 味道也适用于代码。 品味是通过满足简单性的要求而达到的约束满足过程。 保持对简单性的偏见。
- 可以说“不”-只是因为有人要求功能并不意味着您应该这样做。 每个功能的成本都超出了最初的实施：维护成本，文档成本和用户的认知成本。 总是问：我们真的应该这样做吗？ 通常，答案是完全没有。
- 当您对支持新用例的请求说“是”时，请记住，从字面上添加用户请求的内容通常不是最佳选择。 用户专注于他们自己的特定用例，并且您必须以整个项目的整体性和原则性愿景来应对。 通常，正确的答案是扩展现有功能。
- 投资进行持续集成，并争取实现完整的单元测试范围。 确保您处在可以自信编码的环境中； 如果不是这种情况，请从专注于构建正确的基础架构开始。
- 可以不提前计划所有事情。 试试看，看看结果如何。 尽早还原错误的选择。 确保创建一个可能的环境。
- 好的软件可以使困难的事情变得容易。 仅仅因为问题乍看起来很难，并不意味着解决方案就必须很复杂或很难使用。 工程师经常会使用反射解决方案，这些解决方案会引入不希望的复杂性（ 让我们使用ML！让我们构建一个应用程序！让我们添加区块链！ ）。 在编写任何代码之前，请确保所选择的解决方案不能更简单。 从第一原则着手处理一切。
- 避免隐式规则。 您发现自己制定的隐式规则应始终明确并与他人共享或自动化。 每当您发现自己想出一个重复的，准算法的工作流程时，都应设法将其形式化为一个成文的流程，以便其他团队成员从中受益。 此外，您应设法在软件中使此类工作流程的任何部分自动化（例如，正确性检查）。
- 在设计过程中应考虑您选择的总体影响，而不仅仅是您要关注的部分，例如收入或增长。 除了您要监视的指标之外，您的软件对用户，世界有什么总体影响？ 是否有不希望的副作用超过价值主张？ 在保留软件实用性的同时，您可以采取哪些措施解决这些问题？
道德设计。 将您的价值观融入您的创作中。
关于API设计
- 您的API有用户，因此具有用户体验。 在您做出的每个决定中，始终牢记用户的注意。 对您的用户（无论是初学者还是经验丰富的开发人员）都具有同理心。
- 在使用您的API的过程中，始终寻求最大程度地减少施加给用户的认知负担。 使可以自动化的东西自动化，最大程度地减少用户需要采取的行动和选择，不要暴露不重要的选项，设计出反映简单一致的心理模型的简单一致的工作流程。
- 简单的事情应该简单，复杂的事情应该可能。 不要为了利基用例而增加最小用例的认知负担。
- 如果工作流的认知负荷足够低，则用户应该可以在执行一次或两次后从内存中浏览它（而无需查找教程或文档）。
- 寻求具有与领域专家和从业者的思维模式相匹配的API。 那些具有域经验但对您的API没有经验的人应该能够使用最少的文档来直观地理解您的API，主要是通过查看几个代码示例并查看可用的对象及其签名是什么。
- 参数的含义应该是可以理解的，而无需任何有关基础实现的上下文。 用户必须指定的参数应与用户对问题的思维模型有关，而不与代码中的实现细节有关。 API只是解决的问题，而不是软件在后台的工作方式。
- 最强大的思维模型是模块化和分层的：从高层次上来说很简单，但在需要细节时却很精确。 同样，好的API是模块化和分层的：易于实现，但又表现力强。 在较少的对象上具有复杂的签名，而在较简单的签名上具有更多的对象之间，需要取得平衡。 一个好的API具有合理数量的对象和合理简单的签名。
- 您的API不可避免地反映了您的实现选择，尤其是您选择的数据结构。 为了获得直观的API，您必须选择自然适合手边领域的数据结构-匹配领域专家的思维模型。
- 故意设计端到端工作流，而不是一组原子功能。 大多数开发人员通过询问： 应该提供哪些功能来进行 API设计。 让我们为其提供配置选项。 而是问： 该工具的用例是什么？ 对于每个用例，最佳的用户操作顺序是什么？ 可以支持此工作流程的最简单的API是什么？ API中的原子选项应满足高层工作流程中出现的明确需求-不应“因为有人可能需要”而将其添加。
- 错误消息以及通常在与API交互过程中提供给用户的任何反馈都是API的一部分。 交互性和反馈是用户体验不可或缺的部分。 故意设计API的错误消息。
- 因为代码是通信，所以命名很重要-无论是命名项目还是变量。 名称反映您对问题的看法。 避免使用过于笼统的名称（ x，变量，参数 ），避免使用OverlyLongAndSpecificNamingPatterns ，避免使用会产生不必要摩擦的术语（ master，slave ），并确保您的命名选择一致。 命名一致性既意味着内部命名一致性（在其他地方也不要称其为“ dim”，在其他地方称为“轴”），也要与问题域的既定惯例保持一致。 在确定名称之前，请确保查找域专家（或其他API）使用的现有名称。
- 文档是API用户体验的核心。 它不是附加组件。 投资于高质量的文档； 与投资更多功能相比，您会看到更高的回报。
- 显示，不告诉您：您的文档不应讨论该软件的工作方式，而应显示其使用方法。 显示端到端工作流程的代码示例； 显示API的每个常见用例和关键功能的代码示例。
生产力归结为高速决策和行动偏见。
关于软件职业
- 职业进步不是您要管理多少人，而是您将产生多少影响：有工作和没有工作的世界之间的差异。
- 软件开发是团队合作； 它既关乎关系，也关乎技术能力。 成为一个好的队友。 在您前进的过程中，请与他人保持联系。
- 技术永远不会中立。 如果您的工作对世界有任何影响，那么这种影响就有道德上的方向。 我们在软件产品中做出的看似无害的技术选择可调节技术的获取条件，其使用动机，谁将受益，谁将遭受痛苦。 技术选择也是道德选择。 因此，对于您希望选择支持的值，请始终保持谨慎和明确。 道德设计。 将您的价值观融入您的创作中。 没想到， 我只是在建立能力。 本身就是中立的。 这并不是因为您构建它的方式决定了它的使用方式。
- 自我指导（对您的工作和情况的掌控）是生活满意度的关键。 确保您对周围的人给予足够的自我指导，并确保您的职业选择为您带来更大的代理权。
- 建立世界所需要的-不仅仅是您所希望的。 技术人员经常过着稀少的生活，专注于满足自己特定需求的产品。 寻求机会扩大您的生活经验，这将使您更好地了解世界的需求。
- 在做出长期影响时做出任何选择时，请将您的价值观置于短期的自我利益之上，并传递诸如贪婪或恐惧之类的情绪。 知道您的价值观是什么，让它们引导您。
- 当我们发现自己处于冲突中时，最好停下来承认我们的共同价值观和共同目标，并提醒自己，几乎可以肯定，我们站在同一边。
- 生产力归结为高速决策和行动偏见。 这需要a ）良好的直觉，来自经验，以便在给出部分信息的情况下做出大体正确的决定， b ）敏锐地意识到何时应谨慎行事并等待更多的信息，因为错误决定的代价会更大。比延误的成本。 在不同的环境中，最佳速度/质量决策权衡可能会有很大差异。
- 更快地制定决策意味着您在职业生涯中将做出更多决策，这将使您对可用选项的正确性有更强的直觉。 经验是生产力的关键，而更高的生产力将为您提供更多的经验：良性循环。
- 在意识到自己缺乏直觉的情况下，请遵循抽象原则。 建立整个职业生涯中久经考验的原则的清单。 原则是形式化的直觉，其适用于比原始模式识别更广泛的情况（这需要直接和广泛的类似情况经验）。
