看了一篇关于优秀成员的共同特征的文章，文章是基于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、空实现需要注明空实现就是实现。