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