随笔：写前端代码与作后台开发的区别以及将来职业规划的思考

1、写前端代码和对前端开发人员将来职业规划的思考

为何我用“写”前端“代码”，由于在前端真的是在“写代码”而非“作开发”。

我在以前的公司从实习生开始一直是作Java后台的开发，再以前的公司实习也是Java后台，前先后后的后台经历累计有3年多（中间有996加班哦）。

由于“机缘巧合”——前端开发“跑路了”，本着一样是Java语言的本家，让我临时顶替Android开发的职位，同时还要承担一些Java后台的维护任务。

再后来，赶鸭子上架，被迫去研究H5（捂脸，当时内心真的怕怕的，忐忑不安）

一开始自学前端的时候仍是挺有意思的，前端与后台不一样，很形象。好比写个组件立马在真机上跑一下，能够看到显示效果，还有手势、点按、拖拽等的动画效果。

但是常常为了显示效果好看，要调整代码N遍，为了适配各类坑爹机型 ＝_＝＃

前端对复杂数据处理和逻辑判断很少，基本上都在后台作。

由于前端计算的数据最多只是显示，后台不可能依赖前端的计算返回的数据去入库的。

好比：以前开发过一个App拥有地图LBS的内容，实际上是在Android本地载入了一个地图数据包，前端要作的事情就是显示一张区域大地图，获取用户在屏幕上点按事件的参数——“屏幕位置”（左上角开始的XY轴），转换计算成图片的像素位置（一个轴位等于几个像素是根据图片被用户放大的倍数来计算），再去地图数据包里查询像素位置，获得用户点按的区域叫什么名字，如“徐家汇地铁站”等，在这个区域上“插上小镖旗”是调用图像绘制方法在屏幕上画图。或者，调用系统的GPRS接口得到经纬度的参数，去地图数据包里查询，以后和前面同样“插上小镖旗”。

在这过程当中前端只负责：显示地图，获取触点数据，查询本地地图数据包，画图。接下来要得到用户点按后选定的地点之间的导航路径，就得向后台发送查询。

由此看出，前端更专一于，“显示”－“获取”－“反馈”，这三个与用户交互的层面。

而从前端的开发语言和框架的发展历史上也能看出是顺应这个路线轨迹的。

好比：Android和iOS自各都会更新显示组件，变得与用户的交互体验愈来愈好，程序员调用和增长本身想要的效果愈来愈方便，例如：最新的AR／VR。

甚至还出现了入门更加简单的语言：Swift（iOS）、Kotlin（Android）。

而前端的代码在需求改变时被整个推倒重来的几率是99%，因此真的是“写代码”而不是“作开发”，说多了都是泪！

这里插入一下编程语言的发展规律介绍：

我在一开始学写代码的时候（大约十二年前，刚刚拥有一台很破的电脑能够上网，不能关机，只能休眠，不然开不了机的那种，😓）

梦想有一天能够本身创造出一门编程语言。为此，大学里的“编译”这门课是我自学课程里成绩最好哒（此处应有掌声👏👏👏）

但是，当我踏上工做岗位时发现，创造一门语言简单，可是要有人来用却很是复杂。

1. 语言须要定位

好比：

Java一开始解决不一样平台的移植问题，创造了JVM虚拟机的概念，此后还顺应时势和自然跨平台优点推出了EE、SE、ME等。在服务器、桌面、移动等领域大展拳脚、吸引许多开发者为之贡献出本身积累的代码、迭代演化成框架。

C++更专一于底层的灵活调用，不像Java那样耗费内存，更适合于图形学、图像处理、数据处理等浮点数计算的场景。（在GPU、显存价格很高的年代剧有非凡意义）

R语言的各类统计学计算公式现成方法，调用处理数据很是方便。

Python定位为脚本，方便易用，功能强大，“人生苦短、我用Python”。

C# 微软的“语法糖”系列之一，与微软本身的产品结合紧密，常常能够一体化完成全部功能。（以前的公司有.Net开发团队，有幸去帮过忙，接触过一段时间）

JavaScript 跟Java不是一家人，是Netscape公司为了自家的浏览器推出的前端脚本语言，后被各大浏览器接受称为W3C标准之一。（微软还破坏W3C的标准，54安全隐患，给JS增长了不少“语法糖”，以此吸引并下降前端开发者门槛，恶劣竞争排挤其余浏览器——能在IE上跑的JS“语法糖”代码在其余浏览器上会失效，因此不少网站都注明必须使用IE，其中银行类网站是重灾区⭐️_⭐️！）

2. 框架须要维护

好比：

前端JS的框架多如牛毛，各类前端效果、DOM操控、设计模式。github上90%以上的JS代码是重复的。

后台Java框架跨遍各大领域，在服务器端百花齐放，微服务、路由、消息等等。开源、维护厂商众多。

一门语言不仅仅是语法体系成熟，更重要的是拥有众多使用者积累出来的框架，使得新手拥有众多框架资产可供选择使用，语言才能存活。

3. 是否依赖硬件

一门语言的诞生可能只是解决某个问题，出于某种目的。

前端的编程语言高度依赖硬件，举个🌰：

一开始的智能手机内存和CPU都比较差，要显示一些复杂的图形效果很是困难，屏幕获取的精度也不高，前端开发人员能作的事情不多。

但随着硬件设备的更新换代速度如此之高（感谢果粉的肾），前端的功能也愈来愈多，可是前端的开发语言却愈来愈简单，不少功能直接一个现成系统接口调用搞定，这是为何呢？

缘由是，硬件厂商都有本身的竞争法则，硬件高端和低端产品升级都有本身的规划路线，而其中依赖于硬件性能和功能的编程语言就会随着硬件厂商的规划而变化（注意：不是发展而是跟着变化，是被动的）。

所以，硬件厂商为了扩大市场占有率，但愿大量开发者能使用本身的开发语言，会千方百计下降本身开发语言的门槛，吸引更多的开发者和新手（Swift（iOS）、Kotlin（Android）都是出于这个目的）。当市场上某种语言的开发者占多数时，作软件的公司招人成本会下降，更容易找到适合的人，更愿意为其硬件开发App等，使得此硬件的用户量颇高，造成良性循环。

几大厂商亦是如此：

微软自身不出产手机，为了扩大本身.Net在移动端的地位，联合Nokia推广本身的WinPhone系列，依然走“语法糖”路线，可是诺基亚原本的塞班系统体验很好，开发者群体也稳定，加之诺基亚集团的内部矛盾，还曾出现过一个短命的OS meego，最终致使Nokia在智能机时代的覆灭。

因为Android内核的开源性，Google 摩托罗拉、三星、华为、小米等厂商各自为本身的硬件打造最适合的Android系统，Google领头作开发框架的统一规划，下降新手开发难度。

iOS的苹果就不用说了，高大上的开发工具、丰富的组件、标准化的机型、内部生态圈体系，无疑吸引着全球开发者渴望的眼球。

JS语言依赖浏览器、W3C标准。

后台开发语言依赖操做系统，.Net至今还未对Linux抛出绣球，Java在Win系和Linux等支持良好。

4. 支持的IDE

一门语言要存活并发扬光大，除了以上几点，还有要对开发人员友好，美丽的IDE和丰富的懒人插件是必不可少的。

这里有点扯远了，为何要说这些？

由于前端人员的职业规划很是依赖其语言的发展，从横向提及，为了扩展生存能力和技能维度，前端人员能够横跨Android、iOS、WinPhone，精通JS作H5和Hybrid，还有PHP（传说中最好的语言，论坛奇迹，不懂自行google知），甚至学学Node.js作一个伪后台开发。从纵向深刻拓展，能够了解某个移动硬件操做系统的核心（Android是开源的，苹果就比较悲剧，但最可怜的是.Net的开发人员），了解JS赖以生存的浏览器、解析器等。但这些都基于几大硬件厂商的态度，他们为了扩大自身的占有率，下降开发门槛，致使大量新人涌入，形成2～3年的开发者在以后的职业发展上被新人轻易取代的悲剧。由于在前端，新的框架一出现，每每学习成本上，新人和有资历的老人是同样的。而前端开发人员往纵向深刻拓展时，就须要不断跳槽，在须要你更高技能的公司担任要职，大部分普通的软件公司对前端的需求技能要求并不高。

这样就产生了一个矛盾，对高端职位的需求又不会很大，造成过个几年前端人员的晋升面临僧多粥少的局面。因此，很多前端开发人员另找出路，转型作产品经理、UI、UE、UX的也很多。

2、作后台开发和对架构师将来职业规划的思考

在后台“作开发”的路径曲折而悠长，一开始的SSH框架、MVC设计模式，带你入门 ，在大学课程里学习的数据库、数据结构、面向对象设计、高数知识、网络原理、编译原理等知识都派上用场（而在前端就...😄）

在洗礼完了这么多知识和实践应用过程后，会对各类开发框架和设计模式有所认识，对技术架构有所了解，专一于数据库方面的对数据架构很有感慨，趁着大数据的东风翱翔。而若是是在甲方的话，就能上升到应用架构和业务架构的层次，还有企业架构EA。

后台好玩的东西特别多，并且和业务联系很是紧密（前端是和需求联系紧密，和业务真没啥大关系，个人感受）。

最先，我作的实习项目是给电视台搭建抽奖平台，总体平台设计很是复杂，各类消息控制，我在其中写了一段定时更新消息的模块。

后来，参与了几个ERP系统，作供应链管理的，都是大型集团内部使用，或对客户下单的，基本上以MVC为主。

其中，对客户和对管理都有两套系统体系，系统之间业务架构设计和数据架构特别有趣（当时在乙方，涉及某些机密这里不能多说）。

再后来到了金融行业，随着电商行业大发展，架构上有SOA，通讯上有RESTful API、各类消息组件、智能营销大数据。还有幸知道并参与了一种叫作“1+1+N”的银行架构（望天ing，仰望➕崇拜）的建设（在其中搬砖）

这里插一个对安全的思考

应用层的安全在前端和后台通讯加密方面比较着重且被研究众多（连量子计算都来凑热闹了），在作Android的SDK不被篡改方面借鉴了移动游戏的更新包技术（具体咋作的保密），然后台的业务逻辑安全真的很是复杂。

不但涉及到业务逻辑的设计，更重要的是在开发过程当中进行跟踪和管理。不少时候业务逻辑的设计只是正向的，符合正常人的思惟方式，不会去过多涉及黑客的思想。而开发人员在拿到概要设计开始规划模块时，也是思考实现这些功能，而非作过多控制和防御。这就致使，模块与模块、功能和功能之间的控制差别，一些权限的全局控制，信息流的传递过程直至最终入库是否被篡改等，都有着许多隐患。

并且在跨几个系统之间信息传递和校验控制上很容易出现问题，每每越日后面的系统越不知道前面的系统到底干了啥，只会根据现有的业务逻辑去作开发，不会考虑是否存在总体的业务逻辑漏洞。

因此，为了解决这些问题，在最前一层，也就是暴露给前端调用的接口设计上，必须尽可能简洁，一个接口就是一个简单的功能，不能由于参数差很少就几个功能复用一个接口，要防止黑客经过多余的参数篡改达到绕过校验控制的目的。在提供出去的API接口上，最好作后台SDK进行封装，不能把复杂业务逻辑都抛出去直接给外部调用，以防止黑客利用接口之间调用逻辑的调换和参数的巧妙移花接木达到破坏的目的。

扯回来继续说后台！

后台，真的是“作开发”，每每亲自写的代码并很少（IDE太聪明啦，自动填上代码），更多的是集中在模块的规划，功能的实现方式（数据库过于强大啦，能丢给数据库作的绝对不要本身写代码，给本身挖坑），调用方法的逻辑层次上。

往横向考虑能够作技术架构，了解各类技术：Java框架、数据库、通讯组件、SOA等。

往纵向考虑能够作某一领域的专家，好比专门作电商的、金融的、ERP等，成为某种业务领域的应用架构专家或数据架构专家。

对业务很是熟的能够作业务架构，甚至作企业架构。（在作业务的那段时间里，感受到业务的深奥，逼迫你不断学习各类知识，MBA、FRM、CFA、营销学等，还好有点会计基础）

P.S. 下次再说说本身的研究和对游戏开发的见解😊