38件程序员应该知道的事儿

01 对待技术债务要谨慎

我们很容易说服自己，当前变更引入的一点点技术债并不算什么大问题。就跟破窗效应一样，只要放开了口子，系统会腐化的很快。变坏容易，变好很难。

02 分析需求背后的意义

我们首次遇到的用户需求可能只是用户/产品从自己角度想到的一个方案，可能并不是最佳的。可以通过分析用户需求的真正意义，定位真正的问题，尝试提出比用户的建议更好、成本更低的方案。

03 美在于简单

思从深而行从简

04 少即是多

系统设计应该保留可扩展性，扩展性更多的是在接口扩展性设计/外部依赖的可扩展性等设计层面，这些一般都不需要太早的代码实现。

05 时刻想着删减代码

代码是负债，而不是资产

当然，删减代码并不会被纳入 OKR 目标中，但正如运动能够减脂增肌一样，这就是对程序员而言难而正确的事。

06 故障终究会发生

所以我们不得不承认：系统中必然存在不同形式的故障隐患，无论如何都无法彻底消灭。只有承认这一点，我们才能对特定的故障设计对策

07 不要忽略那个错误

错误才是常态，不要忽略任何错误，因为一切都正常实在是小概率事件。

 

08 问题要追踪到根本原因

多问“为什么”？直到查明真正的原因。

09 营地法则：要让离开时的营地比进入时干净

做的事情可大可小，但是要变好。

 

10 多问自己：用户会怎么做？

敬畏外网用户的反馈，一条外网反馈意味着1000个用户遇到了问题。不要无视他们，他们使用并乐于反馈问题，我们要珍惜并积极响应。每一次用户反馈问题的解决，都是提升用户满意度的最有效举措。

11 设计两次

软件设计是一件很难的事情，没有人第一次就做对，所以：尝试设计两次。

12 对代码审查好一点

码审查不仅仅是更正代码错误，其目的还是共享知识、建立统一的代码指导标准

 

13 良好的命名就是最佳的文档

编程无非就是在对26个字母排列组合，如何能让别人读懂你的代码，除去更大范围的模式设计之外，在一个屏幕可见范围内，良好的变量和函数命名是最有助于让读者看懂你代码的实现。

14 要写注释

不要写在做什么，而要写为什么

15 早部署，常部署

早部署、早交付、常部署、常交付，越早部署就越能发现问题，不要堆到最后一把梭哈。

16 不要怕搞砸

不要犹豫，如果你觉得系统需要优化，不管大小，请勇敢前行。 

17 决定重构之前，先想想这能不能比原来好一倍

简单来看，程序员分为两类：

• 喜欢渐进的思考，总是基于现有方案来思考每一个问题，通过调整现有方案来解决新的问题

• 总喜欢用一个系统解决所有问题，而不只是当前这个问题，因此，只要有机会，他们就想从头设计方案

 

18 不要重复你自己

重复就是浪费

将重复的过程调用自动化

 

19 没有高手神话，请把问题描述清楚

总之一句话：会问问题。

20 学习新语言

学了新的语言，才能够使用别人能听懂的语言沟通，这样提出的问题才能得到更好的解答

21加班加点，事倍功半

放下鼠标，离开键盘，去走一走，让大脑做一些与创造性相关的事情，听听音乐，休息一下。只有当你离开电脑之后，你才会发现你解决问题的第一次尝试并不是解决问题的最佳方案。这也是设计两次的最佳时机。

22 数据是核心

1. 系统设计时优先考虑数据模型的设计
2. 上手新服务时优先查看数据存储的实现。这时候如果是非结构化存储，会有理解成本。

23 根据投资回报率(ROI)进行决策

系统的升级改造，主要是时间投入和预计收益是否能适当。即使一个系统架构不佳，但是修改频率很低，那么就可以先放置在那里，不去管他。先把时间投入其他重要事情上，如果没有其他事情可做，那另当别论。

24 拉伸关键维度，发现设计中的不足

我们暂且简称其为无限法，即尝试系统中的关键维度扩展到无限大的时候，会发生什么。

 

这就涉及到对好代码(好设计)的标准，就是：是否能轻而易举的修改它。主要有两点：

• 可读性：首先要读懂，才能谈修改。

• 可扩展性：能够轻易找到修改点，快速做出修改。并且基于开闭原则，只增加而不修改原有逻辑才能避免引入错误。

25 编码标准的自动化

 

越早发现 bug，修复成本越低。因此我们希望在编码阶段就能发现 bug，发现 bug 的方式就是自动化测试，可能是单测，也可能是接口测试。

26 靠谱和信用是我们的资产

 

27 应该了解设计模式的原则

这些原则耳熟能详，但是是否做到了呢。过上几个月问一下自己。

• SOLID 原则：单一职责、开闭原则、里氏替换、接口隔离、依赖倒置。

• KISS 原则：Keep it Simple and Stupid、Keep it Short and Simple、 Keep it Simple and Straightforward。

• DRY: Dont Repeat Yourself。

• LoD 原则: 最少依赖。

28 应该了解设计模式的原则

创建、结构、行为

• 模块原则：使用简洁的接口拼合简单的部件，每个模块做好一件事儿。

• 清晰原则：清晰胜于机巧，代码首先是给人看的，其次才是给机器执行。

• 组合原则：设计时考虑拼接组合，类似于 把每个程序都写成过滤器：和 shell 管道一样，一个函数的输出可以作为另一个函数的输入。能组合就不要耦合。

• 分离原则：策略同机制分离，接口同引擎分离。

• 简洁原则：设计要简洁，复杂度能低则低。

• 吝啬原则：除非确无它法，不要编写庞大的程序。避免不必要的代码和逻辑，保持精简。

• 透明性原则：设计要可见，以便审查和调试。

• 健壮原则：健壮源于透明与简洁。

• 表示原则：把知识叠入数据以求逻辑质朴而健壮。代码的复杂度应该在数据中，而不是代码中。

• 通俗原则：接口设计避免标新立异。“+”应该永远表示加法，而不是除法。

• 缄默原则：如果程序没什么好说的，就保持沉默。

• 补救原则：出现异常时，马上退出并给出足量错误信息。

• 经济原则：宁花机器一分，不花程序员一秒。

• 生成原则：避免手撕, 尽量编写程序去生成程序。 

• 优化原则：雕琢前先要有原型，跑之前先学会走。

• 扩展原则：设计着眼未来，未来总比预想来得快。

29 在责备别人之前先检查自己的代码

开发人员通常难以相信自己的代码会出错，绝不可能出错，即使出错了，也必定是编译器出问题了。

 

如果我们使用的工具/库/框架是被广泛使用的，那就几乎没有理由怀疑它会出错。如果发生了不符合预期的表现，那就首先怀疑自己的代码：用桩代码进行调用调试，围绕可疑代码编写测试用例，检查版本库版本号，检查配置是否生效等等。

 

如果其他人报告说有问题，而你无法复现的时候，那就走过去看看他们到底是怎么使用的。他们可能进行了你未曾预料的操作，或者采用了不同的操作次序。排除掉一切不可能之后，剩下的即使多么不可能，即使你的代码看起来没问题，也只能是真相。

30 在责备别人之前先检查自己的代码

 

31 最好的注释是软件设计架构文档

 

好好写代码注释，说明你是一个不错的程序员。能够好好写架构设计文档，把各个模块交代清楚，同时代码内也能好好写注释，那应该可以“配享太庙”。

32 越早写单元测试越好

 

问题越早被发现，解决的成本越低。单元测试是最早能发现 bug 的手段，同时测试带来的边际成本是很低的，只要写一次，就可以永远为你保驾护航。

33 没有什么能够阻止项目成为屎山

我们能够做到的就是减缓复杂度增长的速率，通过 《整洁的代码》、《整洁的架构》和持续的《重构》，达成写更好的代码的目的。

 

34 要不断学习，有针对性的勤加练习

学习那些能改变你的东西，学习那些能改变你行为的东西。不要在自己已经是专家的领域重复练习，去完成那些超出你当前能力的任务，尽力去做，在任务中和任务后分析你的表现情况，改正错误。

35 了解你的局限性

这些都是你的局限，除了知道你能做什么以外，还应该了解你的局限。这样你才能在排期协调、系统容量预估、大事件扩容、数据量增多导致的查询性能下降等方面做得更好。

 

36 使接口易于正确使用，难于错误使用

接口的存在是为了方便使用者，而不是接口实现者

 

37 简化根本复杂性，消除偶发复杂性

我们应该合理划分职责，进而能够编写高扇入、低扇出的类。（高扇入表示被很多类依赖，低扇出表示不依赖太多其他类；和高内聚/低耦合是一回事儿）。

 

 

38 编写代码就像余生都要对他负责一样

 

https://mp.weixin.qq.com/s/tz6V7AIBcxQcuwvp_pRgCQ