一、写前端代码和对前端开发人员未来职业规划的思考
为什么我用“写”前端“代码”，因为在前端真的是在“写代码”而非“做开发”。
我在之前的公司从实习生开始一直是做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的也不少。
二、做后台开发和对架构师未来职业规划的思考
在后台“做开发”的路径曲折而悠长，一开始的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. 下次再说说自己的研究和对游戏开发的看法😊
