小时候老师问我，你的理想是什么？我说没想到我是个工程师，所以我长大后就当了工程师。工作了这么多年，我一直在思考工程师这个词的含义，终于有一天我恍然大悟原来是：用科技手段改善世界。那么，当今世界在软件方面需要解决哪些问题呢？有几个问题值得思考：整个世界的信息化程度是高还是低？有足够的程序员吗？软件行业的生产力是高还是低？大多数软件系统可靠吗？我想分享一下我对这些问题的理解。虽然我们的生活与十年前相比发生了翻天覆地的变化，比如智能手持设备已经非常普及，可穿戴设备也在蓬勃发展。十年前，我们用手机收发短信或邮件，浏览非常简单老式的wap页面，而现在，大多数人的手机已经取代了电脑，成为日常生活中不可或缺的工具。我们用手机来交流、购物、看电影、看书、玩各种游戏，尤其是手机购物和支付系统的快速发展，让我们可以在任何场合买到心仪的商品，订旅游服务和酒店，快速下单吃的，打车等等，生活很美好，那么整个世界信息化到什么程度呢？在我看来，仅仅相当于小学二年级，整个世界的信息化水平还很低。从现在算起，未来10年，未来10年，这20年，个人信息服务正处于高速发展时期。这个领域非常引人注目，因为它与每个人的生活息息相关。但是，还有一些领域是非常需要发展的，那就是传统产业的信息化。过去，很多传统行业都进行了一定程度的信息化，但这种信息化只能满足自身经营的基本要求。当它与整个社会的趋势联系起来时，就显得非常落后和缓慢。比如在网购这个大系统中，普通用户看到的只是商品展示、比价、下单的过程，但背后的核心环节是配送和物流。还在上学的时候，一个老师说现在计算机行业很火，很可能已经饱和了。你不必从事这个领域的工作。现在回头看这句话，觉得很有意思。人们真的很难用远见去看待未来。去年我去苏宁培训的时候，副总裁孙为民举了一个当年错误决策的例子。90年代末，公司发现全国空调年销量达数百万台。太可怕了。这个行业可能已经饱和了。7亿台，就算根本没有新增，每十年每年也能卖出7000万台。为什么说这个饱和了？所以我看现在程序员的情况，还是供不应求，尤其是高端的程序员，非常抢手。这个问题出现的背景是整个社会的信息化进程在加快，过去的程序员数量远远跟不上需求。那么，如何解决这个问题呢？一方面是继续培训，鼓励更多的新人来这个行业，认真去做，还有其他的办法可以考虑。我想问一个问题：这个世界上到底是懂业务的人多，还是懂技术的人多？显然，懂商业的人要多得多。什么是生意？其实就是行业常识和生活经验。例如，一个有经验的仓库文员，可能文化程度不高，无法理解软件的运行原理，但他必须非常熟悉产品发货和入库的流程，包括各种审批流程和异常情况，但这些，程序员不懂。如果要推动这个领域的信息化，就必须找到两者的结合点。程序员可以学习业务，业务人员也可以尝试参与软件开发过程。目前前者比较常见，因为节目党员比较年轻，学东西比较快。但是从整体的社会效益来说，这其实是不利的，因为程序员是比较稀缺的资源，而传统的业务人员很多。之前看到一个问题：如何让业务人员更好的参与到软件开发过程中。解决这个问题的根本是DSL（DomainSpecificLanguage），核心解决方案是二次开发平台。什么是DSL和二次开发平台？这两个词听上去很高端，但其实每个人都有很常用的属于这一类的东西，比如提供各种公式的Excel，还有VBA。这些人中的大多数不在软件行业。Excel是一个非常成功的二次开发平台，公式和VBA都可以看成是DSL。在很多情况下，这些东西不够直观。我们可以看到一些图形化的编程语言，比如Scratch，现在很多小学生都在兴趣班学习。这些东西都比较容易学，我们也可以做一些类似的抽象，让业务人员以图形化的方式参与，比如流程配置等。图形化的东西最适合非技术人员看懂。所以，要推动社会的信息化，最好能想办法把各行各业的业务人员拉进来一起工作。具体分工大致如下：技术人员和业务人员共同定义DSL，技术人员负责DSL的底层平台实现，业务人员负责利用其构建业务模型和业务流程，甚至业务接口。那么，软件行业的生产力是高还是低？我认为严重低。什么是严重低？如果与机械动力的变化相比，软件业目前的生产力水平是在蒸汽机发明之前。也就是说，生产力还远未解放，未来我们做的大部分事情都将实现机械化，不再需要那么多人做这种重复劳动。这段话可能很多人不满意，你为什么要重复工作，告诉我我做的东西可以被机器代替？从另一个角度来说，为什么几乎所有外行都觉得软件贵？因为人工成本太高，他们觉得做这么多东西不应该花那么多时间。为何两方差距如此之大？我认为关键是大部分工作的抽象层次严重不足，效率的损失很大一部分是因为编程平台或编程语言的不完善，比如Web前端。从第一代到第四代编程语言，每一代都损失一定的运行效率，大大提高了编写效率。随着硬件技术的发展，软件编程必然会越来越广泛。总的趋势是不特别关注细节效率，只要没有数量级的性能损失即可。所以我们可以预期，越来越多的人会使用一些相对低效的语言或者框架，只是为了提高单位时间内的生产力。站在老板们的角度，他们也会明白，提高跑步机的性能，要比多雇几个程序员便宜得多。所以，从整体趋势来看，追求细节表现的程序员可能离自己的理想越来越远，除了某些特定的领域。那么，大多数软件系统可靠吗？换句话说：各位程序员朋友，如果你住的房子质量和你做的软件一样，你敢住吗？感觉每个人都在笑，我们都知道笑是什么意思。那为什么软件系统的质量不容易高呢？我觉得主要是工艺不够完善。那么为什么不完美呢？需求很容易改变。为什么容易改变？是因为不管是程序员自己还是需求方，潜意识里都认为自己做的事情，变更成本比较低。试想一下，为什么没有人在盖高楼，半改要求呢？为什么没人修一半桥，改需求？甚至在做衣服的过程中改变需求，或者在理发的过程中改变需求，都会被认为是不合理的。但在软件领域，这似乎已经成为一种普遍现象。因为整个软件系统的实现是虚拟的、看不见摸不着的，不消耗任何物质，所以从这个角度来说，当然是容易改变的。然而，软件系统的架构与实体的架构并没有根本的不同。进行更改时需要考虑许多相关因素。它不仅仅是一个孤立的小区域。当然，也会有一些不影响大局的变化。例如，如果您正在盖房子的一半，改变外墙的颜色比改变窗户的大小更容易。想弄多了，估计得拆了重新来过。我看到很多公司试图通过加强测试来控制质量，但我个人觉得这种方法性价比不高，效果也不高。要想很好的应对需求的变化，很重要的一点是不要有这个软件永远不会变的想法，然后从架构上进行拆分、隔离、组件化等，努力去实现，即使你想要改变，只需要改变某一块的内部，不影响其他地方。很多软件公司，一方面不重视架构的设计和实现，导致在变更时出现很多问题，程序员无法理解架构的意图。图片。任何架构解决方案都需要良好的管控机制。没有人建造一栋楼只管设计图纸，不控制施工过程。事实上，架构与施工过程密切相关。架构不是一个平面图，而是一个三维的东西，它作为整个系统工程的骨架。如果你能看到在开发过程中逐渐建立骨架，然后用血肉填充的过程，你就会对整个系统的成功更有信心。这就是开发过程中架构控制的概念。具体实现取决于不同的场景。因此，未来的软件开发计划肯定会朝几个方向发展：高生产率，更高的单位时间生产效率，普通人员也可以参与，可控性高，整个生产过程更加完整可靠。孩子们会觉得很幸福，因为他们这一代人长大了，不需要像我们现在这样写程序了。在那个时候，编程已经成为人们习以为常的一种普遍技能，就像现在的人使用Office软件一样，所谓的编程大概不需要敲代码，而是图形化的，设置几个之后就搞定了参数。
