回顾2019,更好的向2020迈进

2019年有许多感触和想法,所以想用文章的方法好好回顾一下2019年自己的成长与不足。我是一名前端开发领域的小学生,真正从事前端开发工作只有一年半时间,在这期间受到许多人的教导和照顾,无论是专业知识或是职业走向,确实获益良多。在2019的总结中,不得不感谢这些前辈。2019年,我对自己所做的事情总结为四个方面:

  • 独立的项目开发
  • 重构老旧项目
  • 规范与新技术的落地
  • 公共库,构建方案的输出

因为是年末总结,所以并不会像纯粹的技术博文一样,对某项应用技术进行总结或是更深层的思考,这篇文章更多的是对2019年的自己的一些看法,接下来会从以上的四个方面进行描述。

独立的项目开发

承担项目开发任务,是每个开发人员都必须要做的事情,对于如此平常的事情,为什么要单独总结呢?因为在2019年中,对于独立这两个字有了深刻的体会。2019年中由一人独立承担并完成了四个项目,项目类型涉及小程序,公众号,移动端。看起来完成的项目数量不多,但每一个项目的开发周期都在二到三个月左右,后期也有许多维护任务。在这些项目开发中,我认为有以下几点收获:

  1. 学习并掌握完整的开发流程。
  2. 沟通能力的提升,与开发的上下游的沟通时间增多,更加明白沟通对于顺畅的项目开发的重要性。
  3. 独立的开发,能够引发更多的思考,对于项目的技术选型,应用哪些技术方案有了更多的主动权,并且也在比较方案的过程中学习了更多的知识,建立更加完整的知识体系。

这三点可能对于经验老道的开发者来说可能是正常操作,但对于新手上路的我来说是非常必要的。从这之中,也有一点不得不说,作为一个项目的开发者,对于技术方案的选定以及最终选用何种技术,应该有更多的思考和实践。固有的方案可能确实稳定且无需考虑过多的实现细节,但是假设它存在更好的替代品或者不适合项目性质,应该学会忍受变革的阵痛。另一方面,假设是比较成熟完备的方案,那也不可以只是被动的使用而不加思索,这对于成长并不利。

重构老旧的项目

2019年完成了两个项目的重构工作,项目为什么需要重构呢,我所认知的基本有两类:

  • 业务逻辑的编写存在太多的不合理,导致维护难度的急剧增加,对于代码设计的考虑不足,陈旧的项目已经无法进行或很难进行维护工作,所以重构是必然。
  • 技术的迭代,在引入新技术的过程中需要将已有代码以新的框架特性进行迁移。

重构的项目没有人对你阐述业务的流程,所以比较考验代码的阅读能力以及对总体的结构的理解能力。重构的任务相比开发新的项目,更多的是已有逻辑的再设计与解耦,通过已有代码进行梳理最终转化为自己逻辑的产物。在这过程中最大的领悟是业务开发过程中不应轻视对于模块的设计,对于任何业务逻辑都可以抽象为数据的输入与输出,这里的 输出 可以理解为页面的最终展示或是函数处理的最终结果。重构让我体会到任何的逻辑生成都是开发者对于世界观的再现,构筑代码和理解世界是相同的概念。

规范与新技术的落地

加入团队的一年多,明显感觉到了整个团队的不断进步,团队的全体成员都对团队利益贡献了自己的力量。在团队带给我进步的过程中,我也希望回馈给团队一些什么,所以开始在工作流程,编码规范,技术引进方面进行更多的探索。一个好的团队不在于全体都是技术顶尖的人才,我认为一个好的团队应该具备的几点是:

  • 完备合理的工作流程
  • 良好的编码规范
  • 对技术的敏锐感知和接纳度。

在这几点上,我们开始引用新的规范或是技术使我们的工作更加合理并且高效。在gitlab的项目提交上,研发团队开始使用Angular风格的提交规范,这使得每个节点的对应修改非常明了。对于CHANGELOG.md我们也探索出了更好的生成方法。在编码中,改进了各项目中的eslint风格不同的问题,最终确定以airbnb作为基础生成符合自身团队开发习惯的规则集。样式编写也开始讨论更好的BEM实施方案与stylelint的引用。

在一翻头脑风暴与多次讨论之后,确定了技术栈统一这一事,以此为开端我尝试了react与typescript相结合的技术引进一事。typescript这一技术好像已经成了前端的大势所趋,在学习和研究过后,也确实从中体会到了这一技术的魅力。在年末时,终于落地了团队中第一个react与typescript的项目,在此期间也将许多知识转化并对内输出了许多文档与知识总结。输出这一事在今年是认为做的不足的一件事,今年只输出了10+篇知识总结,原创的文章有但是极少,2020年应该输出更多原创并且更有意义的文章,对于知识总结的文章可以收起来当做日记就行。

公共库与构建策略

公共库、组件、构建策略这是我今年觉得最有难度并且乐在其中的事情,这些任务对我来说是个不小的挑战,核心的输出总是需要考虑大量的应用场景并且权衡如何实现更加好,投入真实的业务开发中使用后,就会衍生更多的问题。所以这件事不断的冲击着我的知识储备,也使我更快速的成长。

年末最多的时间用在了小程序的自研框架上,在团队中起初主担的是小程序开发的工作,在许多项目的实践并且对于多端框架的使用后,我们做出的决定是基于原生小程序进行构建,自研符合我们需求的框架,使我做出这一决定的原因主要有:

  • 市面的框架主打的是多端这一概念,但事实上这一技术并不成熟,在应用了编译原理后许多编译过程我们不可控,如果应用在单一平台的项目上,我们踩了许多不必要的坑。
  • 对比了许多框架最终构建的体积并不理想,并且性能出现了一些问题,在实践过程中深有体会。
  • 原生的小程序发展势头迅猛,已经开始发展的不像之前那么鸡肋,为了跟上官方的研发速度,决定由团队自身进行构建并且考虑同构方案。

在实践的过程中,更多的时间是关注构建速度,体积和一些必要功能的组合和封装,这使得我的知识涉及面更加广泛,眼光不在局限于某一框架某一技术,而是其原理和本质。从使用各种loader、插件包到自己编写loader、plugin、脚本、工具,确实从中成长了不少。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章