阿里巴巴高级程序员告诉你，前台究竟难不难

先说一下个人认为：整个Web层的纯业务开发可以说都没有难度，后台业务基本就是CURD，前台基本就是数据渲染到视图。

1.逻辑部分: 后台业务层的代码大多数时候只是在解决数据库中的数据，即使是双十一这种场景大部分难点也基本是在业务框架（HSF分布式服务框架）、数据库（OceanBase）、网关（SLB负载均衡）、缓存（分布式KV存储Tair）、计算平台（Blink）、调度平台（Sigma）等等层面被处理了，而不需要过度侵入业务层。所以比照前台将数据稍加解决渲染到页面上，后台的CURD也没有凸显出什么难度。

2.性能优化：服务端的性能优化基本离不开负载均衡、缓存、资源池，至于IO优化（异步、非阻塞）一般也是在框架或者者语言层面处理了。

我承认有在有线程与锁的语言（例如Java）中，并发场景下做好多线程优化和锁的优化不简单，但是并发编程的范式不仅限于线程与锁啊，还有CSP和Actor等等，我作为一名前台过了一遍Go语法和框架文档后就能快速上手写出性能不算太差的后台Go代码了，基本不用去考虑线程和锁。

数据结构这个点，一方面是由前后台的运行场景不同而决定的，服务端数据结构的优化的确可以给内存占用、运行耗时带来客户数量级的减少，客户量越大效果越可观。而前台是运行在用户端上的，大多数时候即便是10倍的速度提升，也不过是从0.01s优化成了0.001s，客户体验上的改变不是很大，甚至不如优化动画带来的提升显著。另一方面，则是因为JS本身比较弱，没有很成熟的相似于Java集合框架、C++ STL的数据结构库，而且前台会对打包大小比较敏感，一般生产环境直接引入第三方库前会反复review。至于网络优化，大多是在架构的层面去做的，业务层不会去考虑。

3.工程复杂度：我没有在淘宝和天猫工作过，但我在淘票票（淘宝电影）实习过大半年。淘票票作为典型的淘系业务，的确符合你说的后台人数远超前台，但这个很大程度上是业务和领域模型导致的。

最典型的例子，淘票票后台需要对接很多第三方的院线，有万达、大地、幸福蓝海等等；还会和第三方售票系统例如满天星对接，而这些对前台几乎是没有感知、不需要也不应该去关注的。

而我现在所在的团队，同样因为业务的起因，前台人数是大于后台人数的，前台团队维护的业务产品线与代码量绝不亚于后台。

总结

说了这么多，个人认为，假如是狭义上的前台业务开发，几乎是没有难点的，后台也是。逻辑、性能优化、工程三个方面的复杂度都是由业务决定的，不能一概而论的认为前台比后台复杂或者者后台比前台复杂。

感谢阅读

喜欢看小编文章的点个订阅或者者喜欢！小编每天都会跟大家分享文章