如果项目从头开始都是自己开发，或者自己主导开发，那代码洁癖是必然的。。
所以我一般不喜欢别人参与进我的代码里，因为他的习惯性随意黏贴，会严重让我不爽
----------------------------------------------------------------
低质量的特征包括但不限于：
- 文件关系混乱
- 注释过期、不明确或者没有
- 文档过期、不明确或者没有
- 架构乱设计
- 过度设计
- 不检查用户输入的错误情况
- 不检查API或者函数返回的errorcode或者exception
- 没有单元测试等自动化测试过程
- 编译起来很难
- 到处复制代码，公用的部分不整理成内部库
反过来 要求就是
- 文件关系清晰明确
- 注释要简明，清晰，更要有效。
- 要有开发文档，全程跟进。
- 合适的架构，合适的设计
- 程序的健壮性
- 测试单元
-----------------------------------------------------------------
好的代码就如同是特种钢，需要经过各种工序的加工，锤炼才能形成。而坏的代码就如同是粗钢，甚至是地条钢。
所以即使暂时写不了高质量的代码，但绝对不能放弃对高质量代码的追求。如果从业3，5年，即使写不了如同特种钢一样的代码，至少也要能写出不锈钢一样的代码吧。
那么什么是好的代码呢？
- Expressiveness(表达性)：好的代码一看就能明白作者的意图，且思路清晰。比如，函数名的选择，代码的组织等。
- Coupling（耦合） 和 cohesion（内聚）的恰当平衡，耦合太多，那么修改的时候牵连太多，无法下手。内聚不够，则代码冗余严重，也不容易修改。
- 消除代码的semll(臭味)，比如过多的临时变量，过长的方法，过大的类等等。
- Generic（通用度），比如能在一定程度上适应用户的变化。
以上是纯就代码而言，如果从应用角度来看，还有很多重要方面。例如：
- 代码和商业逻辑的吻合度，尽量减少用户不需要的代码。比如，可以采用BDD等。
- 代码所映射的商业场景本身的价值，也决定了的代码的价值，如果代码所映射的商业逻辑本身比较小众，代码的价值也不会太高。
---------------------
在评估工作时间的时候一定要切记，不要只说编码时间，这样很不好。最少要分三个部分，设计时间、编码时间、测试时间。它们的时间比例建议是50%、25%,25%。根据不同能力可以进行调整，但是千万不要忽略设计和测试部分。
---------------------
高质量的代码其实是可以帮助你节省时间的。统一的代码规范和变量命名，不仅可以帮到别的程序猿，还可以帮到未来的你，更好地理解你现在写下的代码;经过严密思考而设计出的轻量级代码架构，则可以让你在迭代产品的时候获得更高的效率，更清晰地了解该从何处入手，而不是到数据库里漫天寻找需要替代的地方;而高测试通过率还可以给你充足的自信去调整产品，减少 bug 数量，最小化 QA 时间。
至于“执行质量”，这又是另一个命题。有很多方式可以在不降低产品质量的情况下，使得产品开发过程很紧凑。比如你可以先推迟一些不那么着急的工作，等到整体执行优化、系统稳健性做好的时候，再来做那些被暂时搁置的事情。
具体的做法就是，先把最终想要的产品效果定好，然后往其中填充内容不断修改，至于一些无关的细节可以最后再来优化。举例来说，刚开始开发产品时，可以用 RPC 来简化应用开发的流程，绕过复杂的协议传输问题，先在产品应用层面上快速迭代，随后再替换掉 RPC，加入重试、错误控制、安全检验等代码，或者干脆替换掉传输协议。
写 Mediun 代码的时候，我们就是先实现效果，再调整细化部分的，最后删掉了很多无法整合进原先设定好的框架中的功能，大约是六万行代码左右。
所以如果我们起初没有小心处理代码质量的问题，最终一定会被查找各种很细微的问题困扰。如果我们没有完全聚焦在效果实现上，就一定会拖拖拉拉延后项目进度。但如你所见，很幸运我们前期工作做得充分，所以现在产品可以迭代得很快，并不断试验新功能。
其实在互联网领域中，不仅程序猿会面临上述问题，很多产品经理也会为项目进度和质量打架的问题烦扰。所以 Daniel 的博文提供了一个很好的思考角度，或许下一次再有人问你是不是可以牺牲一点代码质量来追赶进度的时候，你就可以告诉他们：你问的是个伪命题。