工作这么多年，一直在考虑工程师这三个字的意义，总算有一天恍然大悟，正本便是：用技能办法改进世界。
那么，在软件方面，现在的世界有哪些疑问需要处理呢?有这么一些疑问可以考虑：
现在悉数世界的信息化程度是偏高仍是偏低?
程序员的人数够用吗?
软件工作的出产力是偏高仍是偏低?
大多数软件系统都可靠吗?
我想说说自己对这几个疑问的了解。
虽然现在我们的日子与十年前对比，现已发生了巨大变化，比如智能手持设备现已非常广泛，可穿戴设备也在蓬勃展开。十年前我们用手机收发短信或许邮件，阅读非常简略而老土的wap页面，但现在，绝大多数人的手机现已替代了电脑，成为平常日子中不可缺少的东西。
我们用手机交流，购物，欣赏影视，阅读书本，玩各类游戏，尤其是飞速展开的移动购物和支付系统，使得我们能在任意场合采购心仪的物品，订购旅行效力和宾馆，叫快餐，打车等等，日子非常夸姣，那么，悉数世界的信息化程度处于啥等级呢?
我觉得，才刚刚相当于小学二年级，悉数世界的信息化程度仍然严重偏低。从现在算起，往前10年，往后10年，这20年时间中，面向自己的信息化效力处于高速展开期，这个领域非常吸引眼球，因为它与每自己的日子休戚有关。可是，别的有一些领域，却非常需要展开，那便是传统工作的信息化。
之前有不少传统工作，进行了一定程度的信息化，但这个信息化只是能满足自身运作的基本要求，当它与悉数社会的潮流相对接的时分，就显得非常落后，缓慢。比如说在网购这个大系统中，通常用户所能看到的是产品展示，比价，下单的进程，但反面的基地环节却是配货与物流。
我还在上学的时分，有老师这么说过，现在核算机工作非常火热，很或许要丰满了，你们不一定非要从事这方面的工作。现在回头看这句话，觉得很幽默，人真的很难有眼光看到将来。上一年我入职苏宁练习的时分，孙为民副总讲了当年一个抉择方案失误的比如。90年代末，公司核算发现全国空调的年销售量抵达数百万台，觉得很可怕，这个工作或许要丰满，估计要再想办法拓展别的产品运营了，但现在，全国空调的保有量为七亿台，即使完全没有新增，十年换一轮，每年也卖得出去七千万台，当年凭啥说这就丰满了?
所以我现在看程序员的状况，仍然是求过于供，尤其是高端程序员，非常抢手。这个疑问的布景便是全社会的信息化进程在加速，之前的程序员人数远远跟不上需要量。
那么，如何处理这个疑问呢?一方面是继续练习，推动更多新人来到这个工作，而且细心做下去，别的还有一些别的办法需要考虑。
我想追问一个疑问：世界上懂业务的人多，仍是懂技能的人多?很明显，懂业务的人要多很多，啥叫业务?正本便是工作常识，日子阅历。
比如说，一个有阅历的仓库保管员，或许文化程度不高，了解不了软件的工作原理之类，但一定对产品出库入库的流程非常了解，包括各种阅览进程和反常状况，但这些，程序员是不了解的。那假设要推动这个领域的信息化，一定要在两者之间寻找一个结合点，程序员可以学业务，业务人员也可以检验参与软件研发进程，现在来说，都是前者对比多，因为程序员相对来说仍是对比年青，学东西快些。但从整体社会效益来说，这正本是倒霉的，因为程序员是更稀缺资源，而传统业务人员非常多。
之前见过一个疑问：如何让业务人员非常好地参与软件研发进程。这个疑问的根柢处理办法是DSL(Domain Specific Language)，基地处理方案是二次开发途径。
啥是DSL和二次开发途径呢，这两个词听上去很高端，但正本我们有很常用的东西就归于这个领域，比如Excel，它供应了林林总总的公式，还有VBA，运用这些东西的人绝大多数不是软件工作的，Excel便是一种很成功的二次开发途径，公式和VBA就可以算DSL了。
很多时分这些东西还不够直观，我们可以看到一些图形化的编程言语，比如Scratch，现在很多小学生的爱好班就会学，这些东西相对学起来就对比简略了，我们也可以做一些类似的抽象，以图形化的办法让业务人员可以参与，比如流程配备等等。图形化的东西，是最适合非技能人员了解的。
所以，要推动社会的信息化程度，最好是可以想办法把各工作的业务人员都拖进来一起搞。具体的分工大致是：技能人员和业务人员一起定义DSL，技能人员担任DSL的底层途径完结，业务人员担任运用它来构建业务模型和业务流程，甚至业务界面。
那么，软件工作的出产力是偏高仍是偏低呢?我认为严重偏低。啥叫严重偏低?假设以机械力气的改造来对比，软件工作现在的出产力水平处于蒸汽机发明之前。也便是说，出产力远远没有被解放，我们做的大多数东西将来是会被机械化的，不再需要这么多人来做这么重复的劳动。或许很多人会对这段话不满，如何就重复劳动了，你说说我做的啥是可以被机器替代的?
换个角度看，为啥几乎悉数外行都觉得软件贵呢?因为人力本钱太高了，他们觉得，做出这么多东西，应该是不需要这么多时间。为啥两头的反差这么大呢?
我觉得其间的要害点在于绝大多数工作的抽象程度严重缺乏，别的有很大一部分功率丢掉在编程途径或编程言语的不完善，比如Web前端。
从第一代到第四代编程言语，每一代都是丢掉一定工作功率，而大幅前进编写功率。跟着硬件技能的展开，软件编程一定越来越粗豪，大的趋势是不分外注重细节功率，只需没有数量级的功能损耗。
所以我们可以预期，会有不断添加的人运用一些工作功率相对不如何高的言语或构造，只是为了前进单位时间的出产力。从老板们角度想，也会了解，前进工作机器的功能，要比多雇几个程序员便宜多了。因此，从整体趋势看，寻求细节功能的程序员们恐怕会离自己的志向越来越远了，除非是在某些特定领域。
那么，绝大多数软件系统都可靠吗?我换一句话来问：各位程序员朋友，假设你们住的房子质量跟你们正在做的软件一样，你敢住吗?感触我们都在笑，笑是啥意思，我们都懂的。
那为啥软件系统的质量不简略高呢?我觉得首要原因是流程不完善。那为啥不完善?需要简略变。为啥简略变?是因为不论程序员自己，仍是需要方，正本潜意识都认为自己做的东西是改动本钱较低的。
试想一下，为啥没人在盖高楼盖一半改动需要?为啥没人修大桥修一半改动需要?甚至做衣服做一半的时分改动需要，理发到一半改动需要，都会被人认为是不讲理。可是在软件领域，好像这倒成了普遍现象。
因为悉数软件系统的完结，都是虚拟的，看不见摸不着，并不消耗啥物料，所以从这个角度想，变起来当然是简略的。但软件系统的架构，正本也跟实体的没本质区别，改动时分要考虑很多有关要素，并不是就那么孤立的看一小块本地，当然，也会有一些不影响全局的改动。打个比如说，假设你在盖房子盖到一半，那改动外墙颜色肯定是要比改动窗户大小简略的。要是想变得太多，估计只好拆了重来。
我见过不少公司是通过加强检验的办法来妄图控制质量，但自己觉得这种办法不划算，而且收效不高。要想极好地应对需要改动，很首要的一点便是不要有这个软件一定不会改的主见，然后，从架构上做拆分，隔绝，组件化等等，力求做到即使要改，也只改某一块的内部，不影响别的本地。
很多软件公司，一方面不注重架构的方案与宣贯，致使改动的时分疑问多多，程序员也不能极好领会架构意图，一方面疏忽悉数进程中对架构的管控，认为架构只是开端那张静态图。
任何一种架构方案，都需要一个出色的管控机制。没有哪个盖大楼的只细心管方案图纸，不控制施工进程。架构正本是跟施工进程严峻有关的，架构并不是一张扁平的图，而是一个立体的东西，作为悉数系统工程的骨架。假设能在开发的时分看到这个骨架逐渐建立，血肉充盈的进程，对悉数系统的成功把握一定会大
得多，这也便是开发进程中架构管控的理念，具体完结要依赖于不一样场景。
所以，将来的软件开发方案，一定是会朝着几个方向展开：
高出产力，单位时间出产功率更高，通常人员也可以参与
高可控性，悉数出产进程更加完备可靠
有时分看现在的小孩子，会觉得他们很夸姣，因为等他们这代长大，就不需要像我们现在这么编写程序了，那时分，编程现已成了一种令人习认为常的通用技能，就像现在的人用Office软件一样，所谓的编程，很或许现已不需要敲代码了，而是图形化，设置几个参数就完事了。
