对代码质量的思考

“梳理”是我们日常工作最消耗时间的动作，需求开发、私有化部署、技术改造…第一步都是要梳理应用代码，费时且容易遗漏。所谓梳理2小时，写码5分钟。清晰简洁的代码梳理成本是极低的。摆脱沉重的梳理只有提升代码架构和质量，科学技术是第一生产力。

如果把整个公司的协同看做一条依赖链路的话，开发和测试是基础服务，他的RT(耗时)会扩散到各个链路节点。现在市场，公司之间的竞争已经到了深水区，基本上你能做的别人也能做，不太可能再有一方拥有压倒性的优势（特别是toB，比如说不太可能出现销售能力很强，反正能拉到单子，光靠这个就建立了势不可挡的壁垒），一定就是在长时间的你追我赶过程中，看谁能在各方面多做好一点点，效率高一点点，在持续的时间累计下积累优势。从这些来看，好的架构和代码质量时间复利是比较大的。

1 业务形态的区别，注定了toC的代码直接用于toB业务是不合适的

• toC的业务系统：完全中心化的，面向不太确定的零散需求堆积（试错），追求快速迭代功能，抢占市场，追求业务爆发力，可以牺牲资源成本和代码质量，积累大量技术债，巨大的历史包袱。

• toB的业务系统：比较确定的功能需求，高度产品化、一键化、轻量、扩展能力强、扩展成本低，对人效成本和资源成本非常敏感。追求极致的边际成本，不然就是外包业务。

2 对开发的意义：摆脱烟冲式开发（烟冲式就是每次都要从头来一遍，每次都要关注全局，梳理全局，如果扩展点设计的好那就可以只关注扩展点，如果分层很合理，那就只关注对应的层面的问题，不用牵一发动全身）。像平时工作过程中，要求沉淀文档，及时总结，都是摆脱烟冲式的工作的思路，不用每次问题来了，要重新回忆，重新思考，重新到处问。

3 总结几个标准：

• 不要很多if else，判断、校验、打日志等无关核心业务的逻辑代码，这些代码多了会让你的代码核心逻辑不突出，可读性自然差，看了100行代码，发现最后一行才是有效逻辑，很难受 。不要太多try catch，有异常鼓励抛出来（system error真的没啥用），有问题就得及时暴露，而不是隐藏，这个和项目管理一样的道理。

• 好的业务代码大部分应该是线性的逻辑，上面的输出就是下面的输入，而不是上下左右各种网状关联，对人脑不友好，这种代码最容易出问题（大部分业务代码可以做到，底层算法为了极致性能，确实会有较多的复杂的网状逻辑）。

• 代码好不好，看缩进齐不齐，缩进大开大合就说明代码充斥各种嵌套的if else之类。

• 好的代码设计和好的产品设计是一样的道理，本质上好坏就在于是否规划一个对人脑友好的思维导图。合理的工程组织结构，简洁清爽的代码（核心逻辑重点突出，类拆分、方法拆分合理）。每一个节点，都只能看到和他直接相关的下一级的最小范围。不要把下一级的逻辑上浮，也不要把本该属于这一级的逻辑下沉。那种一眼望去大量无序信息的代码或者产品，都是不太好的设计。
  

• 抽象轻量灵活的框架（以简化问题为导向，学习成本要低，框架出问题易排查）。

• 极致的收敛（高内聚）：商业能力的收敛、工具类的收敛、域能力的收敛。

• 链路层次不要太复杂（to数据密集型应用）。

4 重构的核心不是一次性的代码改造，更为重要的是它所传达的写精致代码的理念，要形成一个对每一行代码讲究的，写到让自己满意的意识和氛围。不然开发的人多了，马上打回原形。… 今天又想了想，感觉在紧密的业务开发节奏下，每个人的意识和水平不一样，做到这些不太现实，还是得靠个人的强行干预，你们说呢？

5 不要认为一些小的问题不重要，大的点注意就行。比如命名很随意，无用的代码不删除，代码不格式化，风格规范不统一，idea的黄色提示不关注。。真实的规律可能是讲究的都讲究，不讲究的都不讲究。

6 最后一句话:如果你发现一个问题的解决方案搞的很复杂，那一定是方案有问题，写代码也是一样，简单才是王道。“简单点，代码的方式简单点”。