关于程序员:程序员自省清单

4次阅读

共计 1918 个字符，预计需要花费 5 分钟才能阅读完成。

文章首发公众号：CoderMrWu，每周分享优质技术文章和教训，欢送大家关注，独特交换。

最近特地喜爱看传记教训类的文章，因为能够从中找到一些本人正在经验或行将经验的问题的答案。以史为鉴，就是这个意思。下边是一个程序员自我揭示的清单，摘了些本人觉着比拟有价值的整顿翻译分享给大家。英文好的能够去看原文：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 是的外围，高质量的文档，会使用户有高质量回馈。你的文档，不应该探讨软件的工作形式，而应该是应用办法。更多的实例代码会使文档更敌对、实用。