什么是万倍的软件工程师

之前网上看到过一些对10倍或者100倍工程师的讨论文章，到底这种工程师存在吗？到底是用什么的标准来衡量这种工程师呢？在软件和互联网行业做了20多年，本文就谈谈本人对这个事情的看法。下面截图是美国投资人对10倍工程师的看法，而且引起了网上的讨论。

本人感觉这个对10倍程序员的看法虽然有个别地方是对的，但基本上还是一个门外汉的看法，没有真正的论述出高效程序员的本质。

经济产出才是衡量工程师效率的唯一手段

做软件就是满足客户的需求，产生经济价值，而软件是由工程师开发出来的，所以衡量工程师的效率和价值，也需要通过经济产出来衡量，否则就是在耍流氓。而这种经济产出不是因为代码量越大产出就越高，而是代码的质量，灵活性和适用范围决定的，简单一句就是，代码复用率越高，则劳动效率越高，则相应的产出也越高。

追求复用一直是软件行业效率提升的唯一手段

比如，C语言的发明让大家从晦涩枯燥的汇编语言编程中解脱出来，操作系统的不断完善和发展，也让软件和硬件分离开来，让软件发展变得更加专业化。其它触发软件行业大发展的知名软件有TCP/IP，互联网的基石软件，JAVA的J2EE后端相关技术带动了互联网行业后台开发的大发展，谷歌发明的BigTable大数据技术和均衡负载技术，扫除了互联网行业大发展的数据处理能力障碍。所以，每次信息化行业的大发展，都有关键技术大规模复用的身影，而发明和完善这些技术的天才工程师又是怎么能拿10倍或者百倍来衡量呢？在本人看来，万倍也不为过。这些关键技术的发明和完善通常也不是由个人完成的，但都离不开个别关键核心人物。

在软件底层的标准层有很多技术标准，这些技术标准的目标也是实现软件配件的最大可能的重用，从而提升软件的生产效率，下图是对JCP这个机构的描述。

未来软件行业复用的机会

现在，软件行业的底层标准层的复用已经非常完善和发达，开源社区里面有很多优质的框架，例如Struts和Hibernate这样的框架，H5端也有之前的jquery到现在很火的Vue。现在这种底层的框架已经多的让人眼花缭乱，以至于很多功力不够的人很容易跟风使用，缺乏对这些框架的深刻理解和认识，导致相反的结果产生。在本人看来，框架的好坏评判标准，也是需要通过具体的效率提升指标来衡量的，当然这也是和当事人是否能够巧妙使用框架相关的，有些看似好的不一定是真正好的。国内网上大家都十分推崇SpringMVC，到现在又非常推崇微服务SpringBoot，其实微服务有太多的坑，详细论述请参看”软件框架设计实例_微服务”。相比SpringMVC和MyBatis，其实Struts和Hibernate更加能够提升生产效率，详细论述请您参看”软件框架设计实例_Struts”和”软件框架设计实例_Hibernate”。

在网上很容易看到一些程序员抱怨写业务代码技术含量很低，每天都是CRUD，以致于很多人觉得做底层架构代码才有发展。其实反过来想想，这么多人抱怨低效率重复，正好说明上层业务层的复用最有前途，因为能够解决大多数开发头痛的问题。那为什么在上层业务层面很少有知名的复用框架呢？

1. 需要掌握多个交叉领域技能

做业务层面框架的前提条件是对相关业务和技术都有非常深刻的理解，而且因为业务层面是多样性的，和标准化的底层完全相反，多样性导致设计借鉴难度大大提升，所以做业务层面框架，严格来讲是交叉学科。做标准框架，框架之间容易借鉴，甚至会带有抄袭的成分，而且也只涉及到计算机技术单个领域，而且现在开源的东西越来越多，技术的流通性变得很强。

2. 上层业务的多样复杂性让抽象变得非常困难

在现实的物质世界里面，越到底层越趋向标准化，越到上层越趋向多样化。例如，底层的元素表，人们已经研究的非常透彻深入，但碳氢组成的有机物质和再上层的基因，却还有太多未知的东西。现在，在计算机领域的发展也有非常类似的地方，底层发展已经非常完善，但上层发展还明显不足。计算机科技发展的最大收益也将来自于上层的发展，因为上层的应用软件数量要远远大于底层的标准软件数量，各国的智能制造计划，中国的智能2025，德国的工业4.0，都是计算机技术在各个工业领域的持续衍生发展。其实，处理这种上层的多样性，即使挑战，同时也是机遇。在零售行业，客户需求变得越来越多样化，电商频频失利的生鲜电商行业也是多样化的形态，详细论述请您参看”多样化个性化带来的新挑战”。

因为是多样性的，所以设计出的复用框架必然有适用领域，而且适用范围大小定义也是非常困难的，范围太大，框架变得臃肿甚至不能实现设计目标，范围太小，重用性不高，也就失去了框架存在的意义。这种适用范围的界定体现了设计者对业务领域需求的洞察和归纳，抓大放小，而且还有考虑到业务需求将来的可能的变化趋势，才能保证框架的持续发展性和适用性。如果设计不好，很容易导致几年下来，框架已经和实际需求偏离越来越大，前期的投入不能得到积累和回报。现在人们常常提的PAAS，其实就是一种业务领域的框架，理想是丰满的，现实是骨感的，具体分析，请您参看”谈谈PAAS”。

3. 面对更加复杂的持续多变性

做业务代码多的人都知道，唯一的不变就是持续的变化，研发团队常常被业务需求拖得丢盔卸甲，疲于奔命，以至于产品经理和开发成了世仇。怎么应对变化，其实对团队的要求也越来越高，更高的综合能力和沟通能力，本质上和反恐部队类似。因为业务是多变的，所以框架的完善和发展也必须是持续的，必须建立起双向需求反馈机制，当框架遇到解决不了的实际问题，则需要扩展，同时还要保持之前的稳定兼容性。本人遇到这样的情况，使用框架的程序员发现部分功能不能实现，就放弃框架，自己去搞另外一套，这是一种缺乏团队协作精神的体现，团队协作目标被个人英雄主义破坏。电影里面，我们常常看到主帅要求将领“只许败，不需胜”，有些将领就是想不通，抗令行事，导致全局的被动。业务框架需求的采集不能靠设计者一个人来完成，需要团队协作来完成，而且很多需求是在不断使用的过程中才发现的，所以说，没有使用，就没有业务框架。

4. 集小胜为大胜

业务代码的重用性体现在业务的各个层面上面，有些可以是简单的几个类，在小范围内复用，有些可以是复杂的复用组件库，保持业务的独立性，实现更大范围的复用，所以，复用的模式是灵活多样的，需要根据业务具体情况来定的。最简单的重用案例，请您参看”小例子看编程的扩展性”，例子简单的就是一个函数，但绝大多人的答案根本不具备扩展性，简单的东西都无法做到可扩展，复杂的东西就根本不用提了。做业务框架，不能急于求成，一口吃个大胖子，必须做好各个细节方面的重用性。

5. 业务框架实现需要业务的持续性

业务框架是通过复用来实现效益的，而且复用越多，效益越高，所以简单业务不适合发展框架，因为框架的开发和完善也是需要成本的。例如，外包业务很多时候业务持续性非常差，而且要求也不高，关键的是外包公司是通过人时收费的，框架提升了质量，加速了开发，岂不是自己捅自己刀子。

6. 业务框架开发对团队编程规范和能力要求很高，即团队的基础能力

开发需要具备产品和测试思维，团队协作需要到位流畅，具体分析请您参看”谈谈不同技术团队的协作”，”软件开发规范的建立”，”程序员要有产品和测试思维”和”敏捷开发怎么真正实现落地”。

业务框架发展的过程中不可避免需要重构环节，就和巡航导弹不断修正方向参数一样，而且重构的基础条件是代码质量高，耦合度低，否则重构只能是幻想，框架的持续发展也就成了幻想。在PAAS文章中，很多国内企业谈到PAAS非常非常难，其实也是国内开发普遍不重视编码扩展性决定的，工程性的东西，往往细节会决定成败。

复用业务框架设计举例

之前的文章中，本人也讲了多个业务设计的案例，其中两个比较典型的案例有”软件框架设计实例_解析”和”软件框架设计实例_表格”。为了能够准确理解下面的论述，请您先参看这两篇文章，或者关注公众号，参看其它设计方面的文章。

通过前面的论述，我们知道，框架最大的作用就是代码复用，而且复用的越多，则生产效率越高，相应的经济效益也就越高。现在B端软件公司为啥活的都那么累，因为代码复用性太低，生产效率太低，绝大多数程序员眼里的复用和实际执行的复用，就是代码的拷贝粘贴，严格来讲，根本就不是代码复用。

1. 可以复用的框架组件让开发变得更快，而且实现的功能更强大，让绝大多数表格的开发变成了文件配置，而且这些表格可以实现动态的变化，满足客户的个性化需求。这个组件的是业务独立的，有着非常广泛的使用场景，可以运用到各种管理软件的开发当中，因为管理软件中表格的占比是非常非常大的。这就是前面讲到的，框架设计一定要抓大头，实现效益的最大化。

2. 应对需求变化的能力非常强，而且绝大多数需求可以快速实现，这样可以大大降低业务部门的运营成本。太多的时候业务部门的合理需求不能被开发满足，导致业务计划流产或者蹩脚的执行，在这个市场快速变化的时代，都意味着运营成本的大大提升。所以说，在信息化管理时代，信息系统的变化性影响着公司运作的各个层面。例如，即使相同的表格在业务各个部门需求是不同的，因为要看的数据栏不同，有些敏感数据被非相关部门人员看到，可能导致公司机密的泄露，所以企业需求天然存在着一定的个性化，而现在的软件基本上都是提供标准化不变的表格，如果变化，则需要另外开发，大大提升了软件的使用成本。

3. 成熟的业务框架模块化非常好，耦合度极低，让BUG率可控，因为调整变得更加具备可分析性，很多调整在开发阶段就可以预估影响的范围。可能影响的地方加大测试力度，不可能影响的地方，可以忽略测试，所以测试变得非常有的放矢。相反，面条代码对测试是一种灾难，因为任何修改都无法确定影响点，就和北美洲一个蝴蝶扇动翅膀，导致一个远在欧洲的瓶子掉落，砸到了一个人头上一样，太多的影响都是一种莫名其妙，偶然中又含着必然。针对这种代码，唯一可靠的测试就是全面回归测试，测试的成本指数提升，即使这样，也还会漏掉很多BUG。所以说，解决BUG的最好办法就是预防BUG，难预防的BUG，也要做到问题的科学的隔离分割，业务框架就是解决这个问题的最好最高效的方式。

4. 优秀成熟业务框架的生命期是非常长的，前面讲到的表格框架从2005年到现在已经10多年了，而且仍然可以持续扩展和完善，这就是一种技术积累的体现，长期持续收益，而且运用的项目越多，收益也越大。

业务代码复用的误区

网上很多低代码的案例，有些人想通过低代码工具来实现业务层面的快速开发，有的人甚至宣称通过AI来解决编程问题，取代程序员工作，最后被爆出是一个巨大骗局，真正编码者是远在印度的工程师。其实，这种低代码工具也不是什么创新，例如，很多声称的万能报表，实际上需要通过数据库层面编程来实现，如下图所示。

类似的工具还有金蝶的BOS，还有很早之前流行的拖拉编程工具VB等。这种工具生成的框架代码，重用性非常非常差，而且常常还非常臃肿，常常只适合二次开发的场景，或者简单业务开发，例如，VB常常用于单机版软件开发。使用这种二次开发的版本，在后期版本升级过程中也存在太多问题，导致持续维护成本大大提升。

总结

所以说，高效的万倍工程师并不是本文开头讲到的，”撸代码多么快，什么夜猫子”，真正的高效在于思想和设计，通过代码的复用，大大提升生产效率，是思想的结晶和重用，是解决单个问题和解决一类问题的区别，而这一类问题可能包含了太多太多的单个问题。所以，万倍工程师的本质，就是以类解决问题，还是以个解决问题。