# 一、程序员良好习惯
# 1.1 细节决定成败
1、保持对代码细节的偏执观念。“当所有人都真的在给你找麻烦的时候，偏执就是一个好主意。”——伍迪-艾伦。
站在纯技术的角度来讲，这一条完全赞同，但站在更上层的角度来看，某些偏执还是需要为更高优先级的事项让步。
2、软件工程=科学+艺术，要追求写出优雅的代码。
3、MR 要自己先 review, 不要浪费 reviewer 的时间。
# 1.2 设计先行
1、控制软件的熵（混乱程度）增。
项目的设计、重构、管理、规范、范式等，大多数都是为了这一目标。不然就是在一坨*上，再加一坨，或在上面雕花，最终让项目变得不可控。
2、项目中使用统一的术语。DDD在这一方面做到了极致。
# 1.3 测试先行
1、编写自动测试来极早发现问题，尽量保证简单且质量高。
编写测试时，使得我们以从外部视角看待代码，这让我们看起来是代码的客户，而不是代码的作者。如果感觉难受，那么很可能是因为在代码设计的时候，并没有把“容易测试”考虑进去，可测试性不强。
2、尽早测试, 经常测试, 自动测试。
3、自动化测试要快。
# 1.4 领域驱动编程
1、不要面向需求编程，而应该面向业务模型编程。
# 1.5 解耦
1、我们可以使用框架，但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它进入内圈。——《整洁架构之道》
2、“解耦”、“插件化”就是 Golang 语言的关键词。Less is more, more means nothing。
3、Unix 编程哲学告诉我们: 如果有一些参数是可变的，我们应该使用配置，而不是把参数写死在代码里。但在Golang时代，下载的文件中几乎找不到任何配置文件，新时代的两个道理：（1）配置即隐性耦合。配合和相隔十万八千里的代码产生了耦合。（2）代码有很强的自解释能力，工程师们更愿意阅读可读性强的代码，而不是编写得很烂的配置文档。
# 1.6 封装
1、不要出现特定 IP，或者把什么可变的东西写死
2、定义变量时，使用定语, 不要 1、2、3、4来命名。
3、封装不一定是好的组织形式，不要过度封装。
4、当自己的代码可能会给别人带来困扰的地方，都应该显式地去处理。比如，在Golang中可以通过下划线（_）来忽略一个结果，当忽略一个error返回时，别人却无法判定你是否对error处理进行了深思熟虑。
# 1.7 合理注释
1、合理注释一些并不”通俗“的逻辑和数值（神秘字符串）。
关于注释，请慷慨一些，说不定几个月之后，It is your turn to eat your own dog food。
2、代办的事项要用TODO标识出来，极有可能就是你自己接着开发。
3、空实现需要注明空实现就是实现。
# 1.8 异常处理
1、要把错误（error/Exception）包装一下返回上层，而不是直接抛弃。
2、历史有问题的代码, 发现了问题要及时 push 相关人主动解决
3、如果打了错误日志，有效信息必须充足，且不过多。讲不清楚的日志等于没有。