昨晚在攻城狮群里讨论问题的时候扯出了一个有意思的话题，在现有的技术体系和环境下，构建一款产品，似乎前端工程师工作量越来越大，他们正变得越来越忙碌，而后端工程师的时间则相对闲暇一点，但轻松之下，暗流涌动。
这个现象在我的团队似乎也得到了印证，新产品上线在即，每天工作最为忙碌的就是前端工程师，他们需要应对产品经理的需求变化，处理设计人员的设计样图，还需要和后端人员确定交互协议和数据格式。他们要保证交互能够达到产品经理的要求，UI 设计的实现要能通过设计师们钛合金像素眼的审核，最后与后端完成快速、安全、合理的数据交换。
这时候后端工程师在干嘛呢?他们一边喝茶一边说笑着对产品指指点点，这不是挑毛病而是兼职进行产品测试，同时还陪伴前端同学调试功能，满足前端的数据需求。后端工程师相信：陪伴是最长情的告白，相守是最温暖的承诺(围笑)。
前端费了九牛二虎之力，濞涕泡都累出来了，终于又弄出个界面，他们擦擦汗对后端说，再来个接口。后端吹着口哨说，好咧。十分钟，一个漂亮的基于 Restful 风格的 API 妥妥的写完，Json 格式，HTTPS 传输，快捷、方便、安全，response 和 refer 都无懈可击，童叟无欺居家旅行之必备良品……
这个现象并不是后端工程师造成的，而是云端技术的发展再加上后端和前端工程师的合力，形成了这么一种局面：反模式，前后端分离，前端很重，很多业务逻辑都由前端搞定，后端的大部分基础设施都挪云上了，反而变得很轻。
我们以前编程可不是这样。2000年左右我开始使用 Perl 写 CGI 程序(Perl + HTML混合编程)，后来陆续学了 JavaScritp、Java、C#、Python、Objective C、Go 等技术，早期的项目或产品基本上都是从前做到后，除了设计之外，从切图、前端页面到业务逻辑、持久化、连接池、异常、缓存、日志、集群等等，基本上都要自己参与编程或独立实现，在那个年代，你很难以专业细分的方式运作项目，因为根本找不到那么多程序员。
现在的情况完全不一样了，互联网的高速发展需要技术上更为专业、更为精深的编程人员，所以前后端技术体系的分离，就成了大势所趋，形成了一种「反模式」。早期开发更多是把前端当做一个展示层，大部分业务逻辑都放在服务端实现。前端很轻，因为前端很弱，缺乏好的前端框架，浏览器引擎和规范都不完善。
随着浏览器技术的突飞猛进，前端重获新生，不仅可以做 Web，还能实现原生级别的移动 App 开发，前端开始承担更多更重要的职责和角色。前端的强大，导致一部分业务逻辑从服务器端转移到了前端，后来逐步形成了前后端分离的开发方式，前端负责界面上的大部分业务逻辑，然后通过 API 与后端进行交互。原来业务系统看重的事务问题，要么一次 API 算一个事务，要么做成幂等服务，要么通过事务补偿的方式实现，要么交给异步消息队列处理，这样就形成了一套更为轻量级的开发模式。
后端干嘛去了?后端工程师的主要职责是设计和编写 API，前端恶狠狠的称他们「写接口的」，因为「一个接口累死多少前端英雄汉」。
前端工程师终于扼住了命运的咽喉，开始忙的不亦乐乎，每天上班都像打了兴奋剂，后端咋办呢?总不能写一辈子接口吧。有同学说，我们可以去做架构啊，搜索、消息中间件、存储、大数据、云计算、机器学习神马的……既然你这么说，我就给你看一张图，这是某云计算厂商提供的基础服务：
点击看大图
你看一下有没有覆盖你的知识和技能领域。类似亚马逊阿里云这样的云计算厂商，上千的技术人员除了满足自己系统的需求，其他资源都会投入到公共云的建设上，这些优秀的工程师做出来基础服务，无论是稳定性还是扩展性，都会大大超过创业公司里几个人捣腾出来的技术组件。比如我们，就用了阿里云的虚拟主机(ESC)、数据库(RDS)、负载均衡(SLB)、文件存储(OSS)、Redis、CDN、日志、NAS 等服务，这些东西以前都是需要后端工程师或者架构师搞定的事情，现在，云计算厂商都替你搞定了。
后端工程师何去何从呢?如果你不是一个纯粹的底层技术开发者，首先要让技术和业务结合起来。很多工程师不喜欢了解业务，这是这个时代最大的误区，领域知识对工程师来说同样宝贵。其次，既然已经有了这么多的好技术，用好它们，让技术驱动业务成长，就是最大的成功。
如何定义一个好的现代的后端工程师呢?
1、在领域内精湛的技术造诣和丰富的经验
2、技术上的远见和整合能力
3、广泛的技术知识，不做基础组件，不意味着你可以不懂
4、熟练的编码技巧和细节把控，想当架构师的程序员都写得一手好代码
5、熟悉信息的表示方法，了解主流的和常见的国际技术标准
说白了，就是既具备技术整合能力，也通晓技术细节，从而实现技术驱动业务的突破，而不是纠结于某个中间件或存储服务。
前几天在 Airbnb 女博士朱赟的小密圈里看到一个问答，很好的诠释了这个问题：
提问：作为一个后端开发，想请教安姐，如何去提高自己的驾驭复杂业务逻辑的能力、设计能力和抽象能力?如果接手一个稳定性不够好的系统，如何收敛复杂度，逐步提高稳定性?
朱赟老师非常干练和漂亮的给出了这个答案(略调整)：
驾驭首先要做到通晓。了解所有业务逻辑的来龙去脉，知道一些典型系统设计方案以及其针对的问题，还有优劣比较。接触过一些实际的系统。在此之上，才有可能把合适的设计套用到当前的业务逻辑上，把现有的业务逻辑抽象成一个已经存在(部分)解决方案，或更经典的方式。
接手一个稳定性不好的系统，如果没有足够的时间从头设计、完全重构。那么至少要知道影响稳定性的几个关键要素，然后根据重要性、紧急性和解决问题需要的资源(时间、技能集、人等)进行优先级排序，逐个击破。对于所有的改善型动作，确保有适合的评测和监控，这样能够知道不同的措施效果到底是怎么样的。
我想这就是对后端工程师的素质要求，也是一个工程师的价值体现。
当然了，工程师也不能总局限在自己的领域内，有时候跳出来，看看互联网里其他优秀的人是怎么做的，对个人和团队的成长都会有很大的帮助。我不一定在风口，但至少知道风从哪里来，到哪里去。前进一步，海阔天空。
推荐一下我们团队出品的 QCon 全球软件开发大会(上海站)2017。QCon 是国内最顶级的开发者盛会，每年都会吸引大量的优秀讲师、杰出的技术人和开发者、互联网从业者。这次大会内容涵盖了人工智能、编程语言、业务安全、软件性能、实时流计算等诸多重磅专题。C++之父 Bjarne Stroustrup、Google、Airbnb、Facebook、Uber 和国内各大互联网公司技术精英尽数到场，久未出现在国内社区的老赵(摩根大通)、罗辑思维产品负责人快刀青衣、无码科技合伙人二爷和 Airbnb 硅谷女神朱赟都会惊艳亮相，并做出精彩的分享。
大连治疗早泄的医院 http://jbk.39.net/yiyuanfengcai/zn_dlbhyy/
大连包皮手术医院 http://jbk.39.net/yiyuanfengcai/tsyl_dlbhyy/
大连好的男科医院 http://jbk.39.net/yiyuanfengcai/yyjs_dlbhyy/