1 技术发展的一些体会
从2016年开始, 笔者走上了"程序猿"这条路, 至今已经有6年了.
这6年来, 从项目开发所使用的前后端技术不断变迁, 我深切体会到这一行技术发展的日新月异, 何其迅速.
本文不谈具体的技术细节, 只谈一谈入行这6年来, 笔者对行业和这份工作的一些看法.
1.1 早期(2016年~2017年)技术
刚开始开发项目时(2016年), 笔者所在团队使用的技术栈是Spring+jdbc+FreeMarker作为项目的整体框架, 前端没有太具体的技术, 硬要说的话, jQuery可能算是吧.
最大的特点就是, 许多层次是没有很明显的区分的.
后台还好, 至少有Controller层和dao层的区分, 但有一些需要转换处理的逻辑时, 有时是放在Controller层进行, 有时是放在dao层进行, 好在项目的大多数逻辑并不复杂, 倒也没有遇到十分混乱的情况.
前台就比较糟糕了, 五花八门的写法比比皆是. 比如当时作为新人的笔者, 在遇到给前端传送数据时, 有时使用FreeMarker直接将所有数据放在模板转换后的<script>中作为一个js变量, 有时则使用ajax请求发送请求@ResponseBody的数据(这个在当时来看, 算是最合理的). 数据处理尚且如此混乱, 就不必提前台的分层了.
这并非特例, 那个时代的中小公司开发情况普遍如此.
这带来的一个问题就是, 后端还好, 前端在处理"新的"复杂页面逻辑时, 会非常花时间. 而当时没有什么复用方案, 项目中充斥着大量复制粘贴代码.
1.2 此后(2018年~2020年)技术
一次偶然的机会(大约是2017年底), 为了解决这种复杂页面开发效率低的问题, 笔者尝试使用了Vue.
笔者最早用的是最原始的Vue开发模式,就是在每一个html页面内的<script>标签内直接new Vue({...}). 尽管使用方法原始, 但这成功的将视图与数据分离, 使得前端页面的开发效率大大提升.
后来(大约是2018年), 团队在开发一个新项目时, 首先将前后端作为两个项目完全分离, 其次, 在前端项目使用了Vue2.0技术的完全体.
开始这样做时, 团队的大多数人都是比较痛苦的, 因为虽然大家都知道这是大势所趋, 但忽然放弃以往写.html的熟悉的写法, 而改为使用.vue文件的写法, 学习起来并不轻松.(尽管Vue在当时的三大前端框架中, 对新手最为友好).
至于后端, 虽然改变也很多, 从Spring到SpringBoot的分布式项目, jdk版本从1.7到1.8, 数据库连接从jdbc到myBatis, 以及其他的一些变化, 只要有模板, 改变并不费力. 因为后端的核心--实现业务逻辑层面, 变化并不大, 一点一点去掌握, 并不影响继续开发.
1.3 技术学习不能买椟还珠
最终大家还是适应了这种写法, 开发效率当然有所提升.
但就笔者观察, 很遗憾的是, 很多人的开发思维仍停留在了几年前开发html页面上. 遇到了相似逻辑的页面, 第一想法不是通过自定义组件实现, 而还是复制粘贴, 或者寻求现成的插件(组件). 更不必说一些更复杂的特性, 如mixin,插槽,修饰符等, 或者对vuex和vue-router的深入了解了.
这里提一句, 笔者认为, 理解Vue的这些较深入的特性, 为何而设计(解决何种问题), 在何种情景下使用, 比单单会使用要更重要. 尤其重要的是: 不要为了使用而使用!
再有一点也是很多人(包括以前的我)所忽略的, 即: 现在的前台技术, 已经能很好的支持, 在前端也实现类似MVC的层次, 即将模型层(model, 负责业务逻辑),视图层(view),控制层(controller, 负责数据搬运)区分开. 对于Vue, <template>和<style>里的内容可以称为视图层, <script>里的内容, 应该只实现控制层的内容, 即只负责数据的搬运, 将处理好的数据传给视图层, 而不应将模型层的工作也拿过来干, 这样逻辑一旦复杂, 开发和维护的效率又会很低了.
时至今日(2021底开始), 公司又开始使用了新的技术栈, 包括TypeScript,Vue3.0等新技术. 我还没有完全接触, 但不出意外会和3年前一样, 再次经历阵痛期.
2 工作内容中的重点
笔者以为, 开发项目最重要的一点, 不是让项目代码变得多优雅, 或者结构多么严谨合理, 或者框架多么紧跟潮流, 开发项目只有一个重点--满足业务需求.
所有的一切工作, 包括所使用的工具, 框架, 乃至于逻辑结构设计, 全部都应该为业务需求服务.
因为业务需求, 才是真正体现项目价值的核心.
2.1 冲突发生的必然
之所以这么说, 是因为笔者遇到过很多种情况, 与提出业务需求的人沟通, 双方的冲突点在于:
如果要按照++业务需求++完全实现, ++开发所需的时间/精力++, ++代码的优雅性++, ++保持现有的逻辑架构++, ++系统的使用性能++, 这5个方面方面之间难以保持一个良好的互容, 往往要打破其中一个两个甚至更多个, 才能很好的满足客户需求.
这其中, 业务需求往往是必须实现的, 好在一般可以相互让步妥协.
2.2 沟通带来的问题
关于业务需求, 另一点比较重要的是, 开发者自己需要始终对业务需求有着清醒的了解.
除了这样做, 可以使上面所说的冲突发生的更少一些外, 这又有助于另一些涉及沟通的情况的处理:
- 需求方自己并不能很好的理解原需求(比如这个需求可能是来自领导或者其他方的). 这个挺要命的, 尤其是一些比较复杂的需求. 最好的方式是直接越过去, 找到原始需求方直接沟通, 不然就等着返工吧.
- 需求方与开发方在沟通理解上存在偏差, 这常常会出现.
因为需求方自己往往是没有软件开发思维的, 而开发者对需求方的业务领域往往也所知有限, 最后很容易形成鸡同鸭讲的场面, 甚至双方各自火气上升;
没有别的好办法, 只能双方各自克制, 冷静下来沟通才能解决.
3 以后该怎么做
3.1 技术推陈出新带来的负面影响
纵观历史, 科学技术在开始发明创造初期, 即使再能推动社会发展进步, 往往不能得到很好的推广.
一个重要的原因是, 一项科学技术的进步, 往往意味着会有大量习惯原有技术的人无所适从, 利益受到损失, 进而反对, 有时甚至会有十分激烈的冲突. 譬如蒸汽机作为动力进入纺织业时, 大量传统纺织工失业, 这些人将矛头指向纺纱机, 有些会武装破坏.
这便是技术进步的负面影响, 它对整个社会而言确实是有利的, 但也实实在在的破坏了一部分人的利益甚至生计.
3.2 程序员的困境
相比于其他行业, 软件技术的发展更加迅猛, 特别是前端.
这两天看到一个新闻, 在5年前极为风靡的一个插件layui, 它的官网已经停止提供下载服务了. 这项技术基于jQuery框架, 但到了如今这个数据视图分离框架流行的时代, jQuery确实已如冢中枯骨无人问津了, 所以layui的停止服务, 其实也在预期之内.
程序猿, 特别是前端的程序猿, 可能是最容易无所适从的了. 学习的东西非常多, 偏偏这些技术过几年就要过时, 就要学习心得技术, 这实在不是一件让人愉快的事情.
笔者自认为还算是一个比较爱好学习的人, 面对日新月异需要学习的内容, 有时也不免感慨一声要学的太多了. 更不必提那些不爱学习/没有时间精力学习/学习效率低的同学了.
笔者一直在想, 这样下去何时是个头呢? 5年前的技术放在现在已经过时了, 但如果只掌握了现在的技术, 又无法处理5年前的项目, 但5年前的项目又不一定只会使用5年.
程序猿这个行业就是如此, 不是在学习就是在学习的路上, 再往后5年10年会一直如此. 如果不学习, 那么被淘汰就是迟早的事. 这也是为何大龄程序员少的原因.
3.3 大龄程序员的优势与劣势与选择
优势:
- 对于业务逻辑更加熟练. 如果常年在一个业务内容体系里开发系统, 这个业务经验是不会随着技术的进步而减少消除的.
- 掌握的旧时代的技术也并非完全无益. 其一, 总有一些旧的项目需要维护修改, 这对新人而言几乎不可能做到; 其二, 旧时代的技术, 也有其可累计的地方.
劣势:
- 年龄原因, 熬夜加班等能力远不如年轻人, 在接收新知识层面有时也不如年轻人.
- 资历与工资正相关, 但如果你在老板眼里, 性价比远不如掌握新技术的新人的话, 离职也是理所当然的事了.
选择(仅代表个人观点):
- 学习技术, 要求深入, 不要一味求广博. 譬如, 不要看着三大前端框架
Vue,React,Regular就都想学, 看准一个学, 并深入掌握其用法. 这些框架的深层思想是互通的. - 技术之外, 注重业务经验与开发思维的总结. 这些是不会随着技术的进步变更或者消除的, 是能真正累积下来的.
- 周期性输出博客更新, 客观的说, 这对普通程序猿而言是有一些难度的, 特别是输出高质量的博客. 但坚持下去, 必有所得.
end