“重算法，轻设计”必将遭到反噬

1

现在的面试中有一个不好的现象，那就是太注重算法了，搞得大家都去疯狂地刷题、背题，以求通过面试的初选。

我知道这是内卷时代的一种筛选手段：人群蜂拥而至，所以门槛就会提高。

我也非常理解数据结构和算法对程序员逻辑思维能力的锻炼：理解了这些算法，知道计算机是如何“机械地”解决问题的，对写业务代码有很大好处。

但是凡事都是过犹不及，如果公司过分强调算法的能力，而忽视了设计的能力，必将在以后遭到反噬。

这是因为我们主要在应用层编程，除了极少数项目和产品之外，都是在实现业务，都没有机会去创造一个精巧的数据结构，实现一个复杂的算法。

实现业务最重要的是什么呢？

是设计！

注意，这里说的不是高层的架构设计，是底层的模块内类的设计，函数的设计。 

设计做得很清晰，才能真正把代码写好，否则即使把变量名起得再好，分支考虑得多么周全，也只是代码得堆砌而已， 读起来非常难懂。

设计容易扩展，才能应对未来可能的需求变化，让自己改动代码的代价降到最低。

切记：“代码主要是让人读的，顺便让机器执行而已。”

2

有经验的编程人员都有这样的感觉：一旦理解了表结构或者关键的类结构，这个模块就理解得差不多了。

正如Fred Brooks 在《人月神话》中说的那样：

Linus也说过类似的话：

好的设计对程序员提出了抽象能力的要求，这种能力和面试中的算法能力是大相径庭的。

举个大家都能理解例子：排序。

在算法题中，只要你能用某种算法把整数数组从小到大排出来就可以了，考虑的是空间复杂度和时间复杂度，数组的下标，各种边角条件等等。

但是站在实用的设计层面，需要考虑：

1.  数组内的数据类型不确定，不一定是整数。

2.  比较的不一定是整数值的大小，有可能传进来的是对象，用对象的某个属性比较。

这时候Comparator这个抽象的价值就体现出来了，排序函数接受一个用户自定义的Comparator对象，不用考虑具体实现，只要调用compare方法，根据返回值就能得知两个对象的“大小”。

3

如果在面试中不注重设计能力，过分考察算法的能力，会形成一种不良的导向，让大家以为刷够了题，背会了面经，就能搞好软件开发，实际上还差得远。

对于公司来说，建议在面试中可以降低对算法的要求，增加设计的内容，可以拿出公司的实际业务问题请候选人来设计，看看候选人的设计能力如何。

对于程序员来说，如何提高自己的设计能力呢？

1. 了解一些最基本的方法论

向模式重构，把经久考验的模式当做目标；或者遵循SOLID原则，看看自己的设计是否满足；还有这些年声势不小的DDD，专门应对复杂的业务逻辑。

2. 在项目中实践锻炼，遇到需求，想想怎么去设计更清晰更容易扩展

3. 阅读优秀的源码， 向大师学习