最近特别喜欢看传记经验类的文章，因为可以从中找到一些自己正在经历或即将经历的问题的答案。以史为鉴，就是这个意思。下边是一个程序员自我提醒的清单，摘了些自己觉着比较有价值的整理翻译分享给大家。英文好的可以去看原文：Notes to Myself on Software Engineering (opens new window)

关于程序开发

• 代码不只是要执行。代码也是跨团队交流的一种手段，是一种向他人描述问题解决方案的方式。可读代码不仅仅是一种良好的编码习惯，它应该是编写代码的基础要求。这其中包括清楚的分解代码、选择意义明确的变量名和对任何隐式代码添加注释等。

• 不要问你提交的程序能为你下次的营销活动带来什么，要问你的程序能为你的用户群体带来什么，要避免以“显式的贡献（conspicuous contribution）”为目标。如果不能满足你产品最初的设计目标，宁愿不添加任何新功能。

• 品味这个词同样可以拿来形容代码。通过对满足对简单性的要求来满足自己的品味，这个是一个约束满足问题（constraint-satisfaction process）。保持对简单性的偏执追求。

• 有时候，某人要求一个功能时，并不意味着你一定要去做这个功能，你完全可以说“不”。有很多超出最初设计预算（维护成本、文档成本和用户的认知成本）的功能，这时候你要问“我们真的需要这样做吗？”，答案往往是“完全没有必要”。

• 当你打算支持一个新的用例（use case）请求时，记住不要仅仅从表面上去实现用例功能。用户的请求，往往都是站在他们自己的特殊个人的角度。你应该整个项目构架和未来规划上考虑。一般，正确的做法是扩展该功能，而不是简单修改。

• 把更多的精力投入到持续集成，争取更多的单元测试覆盖率，确保自己在一个有安全感的编码环境中。

• 可以不提前计划所有事情，根据事情的进展看结果。但是要及时纠正错误的事情，让自己处在一个正确的轨道上。

• 好的软件，可以使困难的事情变得简单。事情一开始看起来很难，并不意味着它的解决方案就很难或很复杂。工程师经常会使用反射解决方案，这种往往会使问题复杂化（添加ML、构建新的APP、添加区块链）。在编写任何代码时，确保使用了最简单的方案。要用最根本、最简单的方式来处理问题。

• 在软件设计过程中，你应该考虑软件的整体影响，而不仅仅是某个功能模块。除了监控相关指标外，你的软件对用户，乃至社会有什么影响？有没有你不希望看到的负面影响？这些你是否可以采取一定措施来解决掉？

Design for ethics. Bake your values into your creations.

关于API设计

• 你的API也是有用户的，即也有用户体验一说。所以，在你做任何决定时，都要考虑到你的用户。要站在用户的角度，不管他们是菜鸟还是经验丰富的老手。

• 在用户使用你的API时，尽可能降低用户的认知难度。隐藏复杂不重要的部分，减少用户的使用成本。设计遵从简单一致思维模式和工作流程。

• 参数的含义应该是在不了解上下文的时候就能很好的理解的。参数应该和用户对问题的思维模型有关，而不应该与代码的实现细节有关。API应该与解决的问题有关，而不应该与后台的工作方式有关。

• 好的思维模型是模块化和分层的：从高层上来说很简单，但是细节也很精准。同样，好的API也是模块化和分层的：易于实现，但表现力又强。

• 你的API的实现是你的一个实现选择，特别是数据结构，你应该选择和自然领域专家思维模型贴近的直观结构。

• 设计API时，应该是一组原子功能。确保以最简单的方式满足上层用例工作流，而不是因为“可能用到”而添加不必要的功能。

• 错误消息，是API与用户交互的一个反馈，交互性和反馈是必不可少的。

• 文档是用户体验API是的核心，高质量的文档，会使用户有高质量回馈。你的文档，不应该讨论软件的工作方式，而应该是使用方法。更多的实例代码会使文档更友好、实用。

Productivity boils down to high-velocity decision-making and a bias for action.

关于职业生涯

• 职业生涯的进步是不你管理多少人，而是你有多少影响力；

• 软件开发是一个团队合作的工作；社交能力和技术能力一样重要。成为一个好的队友，和其他人保持良好的联系。

• 技术永远不会中立，在做选择的时候，有受益者，也会有受害者。将你的价值观融入到设计中，保持谨慎和明确。

• 自省，是生活满意度的关键。确保你对你的工作和生活的完全掌握。