软件工程师自我提醒的清单

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

关于程序开发

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

  • 不要问你提交的程序能为你下次的营销活动带来什么,要问你的程序能为你的用户群体带来什么,要避免以“显式的贡献(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.

关于职业生涯

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

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

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

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