1.优化vs可读性。去特么的优化
尽量写易于阅读的代码并且能被其他开发者所理解。因为花在阅读难以理解的代码的时间和资源远远多于优化代码所带来的好处。如果你需要优化，你可以将其独立为一个模块并且通过依赖注入的方法将其注入，进行百分百的覆盖测试并且一年之内不会去更改它。
2. 架构优先
写代码没有架构和实现你的理想而没有计划是一样可笑的。在编写你的第一行代码前，思考一下它将做什么，怎么做，需要用到什么，各个模块和服务之间如何交互，他们将会呈现出何种架构，怎样进行测试和调试和如何更新。
3.测试覆盖
测试是一件好事，但是对一个项目而言并不总是可以承受和有意义的。
你需要测试的时候：
-当你写至少一月以内不会发生变化的模块和微服务的时候。
-当你写开源代码的时候
-当你写的代码涉及金融行业的时候
不需要测试的时候：
-当你身处一个创业公司的时候。
-当你的团队很小的时候并且代码变更频繁。
4. 保持简单和傻瓜的
不要写复杂的代码。越简单的代码，bug可能越少，用于调试的时间也就越少。代码只需要完成其功能就好而不是附带许多的抽象和其他oop的东西（这位大佬很鄙视oop啊，暂且不敢苟同）
5.注释
注释暗示着坏代码的存在。代码应该不需要一行注释就能理解。
6. 强耦合vs低耦合
尽量使用微服务的架构。一体化的软件的运行速度快于微服务的软件，但也仅限于一个服务器的时候。微服务可以让你在多台服务器上部署也可以在一台机器上部署成为可能。
7.代码审查
代码审查可好可坏。
8. 重构是不壳能重构的啦
在我的从业生涯中，已经听到“不要担心，我们会来重构的”很多次啦。后面就演变成成啦技术债或者删掉代码重头写起。
所以不要留下技术债务除非你有资金重写你的软件。
9.疲惫或者心情不好的时候不宜写代码
当一个程序员疲惫的时候会比在精力旺盛的时候多产出2~5倍的bug。所以干的多并不是什么好事。这就是为什么越来越多的国家考虑六小时工作制并且有些国家已经开始实施啦（额，外国的月亮比较圆么？）
10. 不要一下写完-而是不断迭代开发
在写代码前，分析和预计一下客户真正需要的东西，然后挑出你在短时间内能够高质量完成的的最有价值的功能进行开发。
11. 自动化 vs 手动
长期看，自动化是一件百分百成功的事情。所以你如果有条件马上将一些重复的事情进行自动化。
12. 走出去，培养一些爱好
13.空闲时间学习新东西
当人们停止学习的时候也是其开始走下坡路的时候。
翻译自：13 Simple Rules for Good Coding (from my 15 years of experience)
