企业软件领域前端开发的困境
前一段时间，看到阿里几位前端大师的讨论：阿里前端的困局与突围，对这个职业的发展方向有一些思考，我上次跟winter和dh一起吃饭，也简单聊到这个话题。
winter问了一个问题，如果在互联网企业跟游戏开发的企业同时进行一次针对前端开发的大裁员，对这个企业的核心价值而言，哪种影响更大？
这个问题问得很有意思，在每个行业里，前端开发的侧重点是不一样的，重要性也有所不同，简单来说可以分为3个大类：互联网、企业应用、游戏，分别侧重于：交互、架构、算法。
在这三个大类里，互联网方向的前端开发最为正统，算是根正苗红，所以在这个领域的人，对标准研究得最为透彻，对交互理解得最为深刻，目前前端方向的高手大多集中在这个领域。这个领域的人最关注的问题是兼容性，对一些细节的优化把握得炉火纯青。因为这个领域的业务特点，前端做的事情过于扁平，整个可发挥的余地不够，虽然高手众多，但就像很多龙挤在浅水里，常常有无用武之地的感叹。刚才玉伯这篇文章，讲述的就是这个领域中前端的困惑。
企业应用方向的前端开发其实很多时候并不在意他们用的是Web还是其他类似技术，比如Flex，Silverlight等，对他们来说，即使是C/S的系统，也能够发挥出很大价值。这个领域的人最关注的问题是组件化和快速业务开发。
从企业软件的方向来说，它的业务是很丰富的，对各种前端技术的应用也都很广泛，一个大型的企业应用，几乎什么特性都能用上。相对于互联网系统，它的客户相对比较专业，可以排除一些低端过时的浏览器，所以少了很多兼容的负担，在框架选型上，也可以接受很复杂的框架，比如ExtJS、AngularJS等，因为他们的业务特性，往往需要很复杂框架的支持。
用我所在的电信行业软件举例，业务复杂度非常高，一套全业务系统会有两千左右的数据库表，两千个左右的业务菜单，其中有些业务界面的复杂度非常惊人，而且经常会根据需求有较大变动，性能也有较高要求。
理论上来说，前端在这个领域可以领悟到很多事情，但这个领域有个最大的问题，盈利太低，不足以支撑很深入的研究。另一个无奈的问题是，由于历史原因，前端开发人员在这个领域并不容易受到重视。比如说资深技术人员多数是做后端开发的，认为前端很小儿科，在应届生入职筛选的时候，也会把能力较高的弄去做后端开发，剩下的留给前端。这些原因，造成了企业应用的前端领域就像一个又大又深的湖，里面小鱼小虾众多，却很少有大鱼。
我在企业软件前端开发做了很多年，经常思考其中的一些问题，在这个领域做，总是有一种寂寞的感觉。我们这种行业，为了保证交付的及时，倾向于划分业务开发和技术平台开发，业务开发人员并不在难解决的问题上花时间，遇到问题的时候向技术平台团队寻求支持，把问题转移给更专业的人，避免耽误自己的交付时间。在他们开工之前，也由技术平台团队预先搭建框架，他们直接在这个上面以固定的模式进行开发。两个团队，前者的特点是多而泛，后者的特点是少而精。
这么做，效率比较高，但带来一个问题，业务开发团队的技术水平很难提升。因为他总是忙碌赶工，很少有时间去思考很多问题的前因后果，即使你帮他解决了问题，告诉他，他也不一定有心情去关注一遍，因为他确实很忙。可能有些有激情的人会自己花点时间研究一下，但多数人很难有这样的心境。
这就造成了业务开发团队和平台开发团队的技术实力严重脱节。从另外一个角度看，技术平台团队长期专门给别人解决问题，自己却很少全职参与某个业务项目的开发，他也很难有成就感。这还不是最大的问题，最大问题是，不管从哪个团队，都很难成长出能够设计最适合这些业务的前端架构的人，这恰恰是这个领域前端开发最重要的部分。
当出现各种新技术的时候，平台团队比较容易去快速跟进，但投入通常不会很大，当取得一些进展的时候，会逐步向业务开发团队推广，但这个推广的难度是很大的，因为人数的比例会比较大。当技术从一个人向三个人推进的时候，是相对还算容易的，如果从一个向十个或者二十个人去推进，难度就大多了。而由于传统企业盈利规模的限制，没办法在每个技术方向都有较大投入，所以往往就是一两个人去折腾，他们在探索的过程中遇到问题，是很难找到能够交流的人的，如果自己解决不了问题，就会持续苦闷，非常寂寞。前端这个领域更是如此，现在客户端技术这么多，各种终端，各种浏览器，各种前端框架，每个上面投入一个人，就已经是个很大团队了，这种模式很明显就碰到瓶颈了，因为它很直接地跟人员编制产生了冲突。扩编直接对利润产生冲击，但是不扩编的话，技术平台团队的压力就会进一步加大，除了要探索新技术，还要对越来越庞大的业务开发团队作技术支持，每个人都痛不欲生。
这种困境怎么解决呢，我想了很久，无计可施，也许，是时候要效仿互联网企业的开发模式了？但是积重难返，而且传统企业招聘的门槛远比互联网企业低，人员的能力有差距，也很难有互联网企业那么蓬勃而广泛的技术研究气氛，可能就更难做下去了。
可能这个领域的出路是寻找更为简单快速的开发方式，并且把相关的外围工具也做大做强，在业务领域中，把组件也积累沉淀出来，这时候能够用更少的业务开发人员来实现同等规模的系统，把更多人力节约出来做技术探索和改进吧？
