软件的精髓在于设计

软件的精髓在于设计，设计是一件费脑子的事情，因为软件设计背后是权衡的动作，比如时间换空间、空间换时间、TCP还是UDP、同步还是异步、数据冗余与一致性、微服务边界如何划分、架构中的功能性逻辑与非功能性逻辑等。

但往往很多程序员花在设计与权衡上的时间太少了，花了大量时间在写代码、重构、问题排查。

如果缺少足够的设计思考，一上来就去写代码，势必造成很多瑕疵、隐患与质量问题存在，而这部分在未来会变成新的成本、耗费精力，杀死你的时间。

同样一个架构在早期没有考虑好其功能性与非功能性的设计扩展的话，未来的某一天架构去解决高性能问题、高可用问题时，因为缺少足够的扩展性，难以快速解决这个问题，甚至出现推倒重建的情况，这部分依然是个逃不过的成本。

重构是件好事，但频繁的重构是噩梦，频繁重构代表了这个系统的设计者缺少足够的思考，没有留有扩展性，没有考虑到业务可能的发展方向，缺少规划。不断重构表面上消耗了人力与时间，背后会让团队情绪低落，产生厌倦情绪。

如果你花了时间在架构的设计上，比如和业务聊了下发展趋势与变化，做好了技术难点细节的隔离，推敲了一段设计的合理性、风险、复杂度，看到了设计上的缺陷，那你其实不需要频繁的重构，因为这些成本在日常的每一次迭代中被低成本的消化了。后续你的系统将会越来越轻松，越来越稳定。

多些时间做设计，不是让你写了更多代码，做了更多迭代，而是考虑到其背后的成本，减少了不必要的冗余，更快更好的交付一个更好的产品。

代码的好坏有这几种级别：

1）可编译 2）可运行 3）可测试 4）可读 5）可维护 6）可重用

通过自动化测试的代码只能达到第3）级，而通过设计的代码少会在第4）级甚至更高。

导致大家认为没思考时间的原因有几个：

1. 项目DDL的压力：这种情况很多人觉得要在速度和质量上做个权衡。但偶尔的时间压力让我们非常痛苦是正常的，都会有几次通宵突击的情况，但如果这是常态就不正常了，需要和业务方与老板聊聊，背后的原因是什么；
2. 过度的设计：我们谈了要多一些设计思考，但往往变成了研发同学的过度设计，一些无关或成本不可控的场景被复杂且过度的设计，出现在一个本不应该投入的地方，导致舍本逐末、买椟还珠。好的设计不是纸上谈兵，需要结合实践；
3. 团队成员水平决定：这其实是很常见的一种情况，很多同学缺少建模与面向对象的设计，在职业发展初期过多关注于高并发的术，反而缺少了业务及基础技术层面的积累，导致很多过程代码的出现。团队是需要培训的，结合团队平均能力做合适的设计，比较再好的设计也需要一群人的执行，每一个人都有可能变成木桶的短板，而这个短板决定了整个设计的下限；

怎么提高设计能力呢？

我觉得最重要的方式就是多看，看看好的系统怎么设计、好的源码怎么设计、好的书籍中的例子。

比如《大话设计模式》，里面的例子看似很简单，但有时候简单就对了，反而没必要搞那么复杂。

简单的面向对象做好以下几个方面：

1. 数据与其行为打包封装；
2. 程序的接口和实现的解耦；
3. 组合优于继承；
4. 依赖接口而不是依赖实现；
5. 高内聚低耦合；

高级一点就是SOLID原则。

当然更推荐《UNIX编程艺术》。

有时我们会发现，系统中存在一种胶水层，最开始python、ruby也被叫做胶水语言，这一层用于粘合业务逻辑和基础能力，Unix设计哲学认为，胶水层应该尽可能的薄，太厚了你将苦苦挣扎。

比如我们对外部RPC、二方jar都需要加一层防腐处理，也就是胶水层的意思，网关API对不同终端的不同数据结构要求做不同的处理，也是胶水层发挥作用，千万不要把这一层随时可以撕掉的胶水放到逻辑层。