优秀程序员的22个优秀习惯

看了一篇关于优秀成员的共同特征的文章，文章是基于Golang编程的总结和分析，但大多数理念在编程领域都具有普适性，这里总结分析给大家。

1、保持对代码细节的偏执观念。“当所有人都真的在给你找麻烦的时候，偏执就是一个好主意。”——伍迪-艾伦。

站在纯技术的角度来讲，这一条完全赞同，但站在更上层的角度来看，某些偏执还是需要为更高优先级的事项让步。

2、控制软件的熵（混乱程度）增。

项目的设计、重构、管理、规范、范式等，大多数都是为了这一目标。不然就是在一坨*上，再加一坨，或在上面雕花，最终让项目变得不可控。

3、编写自动测试来极早发现问题，尽量保证简单且质量高。

编写测试时，使得我们以从外部视角看待代码，这让我们看起来是代码的客户，而不是代码的作者。如果感觉难受，那么很可能是因为在代码设计的时候，并没有把“容易测试”考虑进去，可测试性不强。

4、尽早测试, 经常测试, 自动测试

5、项目中使用统一的术语。DDD在这一方面做到了极致。

6、不要面向需求编程，而应该面向业务模型编程。

7、软件工程=科学+艺术，要追求写出优雅的代码。

8、我们可以使用框架，但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它进入内圈。 ——《整洁架构之道》

9、 “解耦”、“插件化”就是 Golang 语言的关键词。Less is more, more means nothing。

10、Unix 编程哲学告诉我们: 如果有一些参数是可变的，我们应该使用配置，而不是把参数写死在代码里。但在Golang时代，下载的文件中几乎找不到任何配置文件，新时代的两个道理：（1）配置即隐性耦合。配合和相隔十万八千里的代码产生了耦合。 （2）代码有很强的自解释能力，工程师们更愿意阅读可读性强的代码，而不是编写得很烂的配置文档。

11、封装不一定是好的组织形式，不要过度封装。

12、当自己的代码可能会给别人带来困扰的地方，都应该显式地去处理。比如，在Golang中可以通过下划线（_）来忽略一个结果，当忽略一个error返回时，别人却无法判定你是否对error处理进行了深思熟虑。

13、合理注释一些并不”通俗“的逻辑和数值（神秘字符串）。 关于注释，请慷慨一些，说不定几个月之后，It is your turn to eat your own dog food。

14、代办的事项要用TODO标识出来，极有可能就是你自己接着开发。

15、要把错误（error/Exception）包装一下返回上层，而不是直接抛弃。

16、自动化测试要快

17、历史有问题的代码, 发现了问题要及时 push 相关人主动解决

18、如果打了错误日志，有效信息必须充足，且不过多。讲不清楚的日志等于没有。

19、MR 要自己先 review, 不要浪费 reviewer 的时间。

20、不要出现特定 IP，或者把什么可变的东西写死

21、定义变量时，使用定语, 不要 1、2、3、4来命名。

22、空实现需要注明空实现就是实现。