第16期 | 后端工程师的危机
池建强
讲述：池建强大小：8.24M时长：09:02
你好，这里是卖桃者说。
前两天跟人聊天的时候，扯出了一个有意思的话题，在现有的技术体系和环境下，构建一款产品，似乎前端工程师工作量越来越大，他们正变得越来越忙碌，而后端工程师的时间则相对闲暇一点，但轻松之下，暗流涌动。
这个现象在我的团队似乎也得到了印证，新产品上线在即，每天工作最为忙碌的就是前端工程师，他们需要应对产品经理的需求变化，处理设计人员的设计样图，还需要和后端人员确定交互协议和数据格式。他们要保证交互能够达到产品经理的要求，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。卖桃者说，明天见。
（编辑：成敏）
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《卖桃者说》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(29)
- 最新
- 精选
小斧1、在领域内精湛的技术造诣和丰富的经验 ; 2、技术上的远见和整合能力 ; 3、广泛的技术知识，不做基础组件，不意味着你可以不懂 ; 4、熟练的编码技巧和细节把控，想当架构师的程序员都写得一手好代码 ; 5、熟悉信息的表示方法，了解主流的和常见的国际技术标准. 说白了，就是既具备技术整合能力，也通晓技术细节，从而实现技术驱动业务的突破，而不是纠结于某个中间件或存储服务。池建强回复: 赞
有心猴说的把后端的工作说没了，其实，真正的业务都是后端实现的。10分钟搞定一个接口，也是用了十天时间把基础业务做了很好实现封装这个前提下才有可能的。不然为啥还要后端？直接扔一个数据库接口给前端好了，但那样又回到您说的所有工作都一个人干的原始社会了。前后端关注点不同，前段注重表现，后端注重逻辑，前端实现不好可以推翻重做，后端每一个变化都要考虑各种兼容性。前后端联调时，后端当然轻松，因为前期苦逼的时候刚熬过去，后端苦熬的时候，前端正在和美工妹子说笑呢96
dongecs片面了，说的是crud后端工程师吧，优秀的后端工程师学习成本是很高的14- desmond迭代版本中，一个接口10分钟，并不是不可能，这体现了代码设计的良好扩展性。 当然后端工程师的工作时间不能这么算，一个接口的编写时间，是需要n倍的准备时间的。9
李春恒去年某云故障，导致一个千万级创业公司数据丢失的痛这么快就忘了吗。😂 云出问题了，干坐着嘛。 所在的即将大促的某大厂，后端服务开发大促前的几个月在做什么事呢。除了正常的需求开发外。制定大促应急预案，梳理依赖资源，配合大促链路压测，性能优化，那这块要真的做的很好的话，需要什么知识储备呢，看耗子哥的专栏吧，里面写的很清楚了😅。 如果只想做个api的程序员，老铁没毛病😅9- Geek_dba6ea小公司可能，大公司不一定，我们公司各种微服务特别多，业务复杂度高，有的系统后端开发一个月也是可能4
吃草🐴~看到标题，非常兴奋，听了两遍，若有所思（咋不押韵😂 ）~按理说，我的职位是 Java 后端工程师。由于上家公司用的 Ofbiz 框架，跳槽时（大部分，哦不，是绝大部分人都没有听过，导致找工作困难~），自己对新的框架（Spring Boot，这也是我沉迷极客时间的原因，我就从丁雪丰老师的课开始学起的~），无论是使用还是思想，只是自己瞎捣鼓的水平。到新的公司以后也就是网上下载的基础课程的水平，接口没写几个，但是已经做了公司两个官网，也就是说前端做了挺多，后端了解得还是很少，也就是会使用。目前给手机端写接口，老大要求使用了 Leancloud，感觉确实后端的事情并不多，只要注重逻辑，设计一下表结构就行了，用法都有例子，写个通用方法直接就能用。确实，注重逻辑也是我考虑到的一个方向。听完这篇文章让我也开始考虑我的前路。3
扫地僧我们80多个后端，10个前端。2
匠心零度我就是后端工程师，瑟瑟发抖😂😂😂2
nil极客时间的业务说实话逻辑并不复杂，甚至比爱奇艺这种视频网站还简单，你们更重要的是资源的好坏而不是你们技术有多牛逼，业务多复杂，所以你感觉自己的后端工程师没啥事干。你再去看看地图业务，导航业务等复杂场景下，后端工程师的逻辑还是很重的。1
收起评论