如果说基础知识的掌握是起跑线,那么使大家之间拉开差距的更多是前端项目开发经验和技能。对于一个项目来说,从框架选型和搭建,到项目维护、工程化和自动化、多人协作等各个方面,都需要我们在参与项目中不断地思考和改进,积累经验。

本文将要介绍:

  • 前端项目设计
  • 前端项目管理

# 前端项目设计

除了具体的前端领域知识以外,当我们开始负责起整个前端项目的管理时,需要具备一些方案选型、架构设计、项目瓶颈识别并解决等能力。

# 前端项目搭建

很多时候,我们的项目在刚搭建的时候规模会比较小,因此在项目启动阶段需要做简化,来保证项目能快速地上线。但从长期来看,一个项目还需要考虑到拓展性。换句话说,当项目开始变得较难维护的时候,我们就要进行一些架构或者流程上的调整。

在项目开始之前,我们需要做一系列的规划,像项目的定位(to B/C)、大小,像框架和工具的选型、项目和团队规范等,包括:

  • 前端框架选择:基于团队成员偏好和能力,选择适合的前端框架
  • 工具库选择:基于项目规模,选择是否需要路由管理、状态管理等工具库
  • 自动化工具:基于成员规模和项目状态(快速上线、稳定维护等),选择是否需要代码构建、自动化测试等自动化工具,以及搭建持续集成、持续部署等自动化流程
  • 项目流程规范:使用一致的项目规范,包括项目代码结构、代码规范、开发流程规范、多人协作规范等内容

项目的维护永远是程序员的大头,多是“前人种树,后人乘凉”。但是很多时候,大家会为了一时的方便,对代码规范比较随意,就导致了我们经常看到有人讨论“继承来的代码”。

代码规范其实是团队合作中最重要的地方,使用一致的代码规范,会大大减少协作的时候被戳到的痛点。好的写码习惯很重要,包括友好的变量命名、适当的注释等,都会对代码的可读性有很大的提升。但是习惯是每个人都不一样,所以在此之上,我们需要有这样统一的代码规范。

一些工具可以很好地协助我们,像 Eslint 这样的工具,加上代码的打包工具、CI/CD 等流程的协助,可以把一些规范强行标准化,达到代码的统一性。还有像 prettier 这样的工具,可以自动在打包的时候帮我们进行代码规范的优化。

除了这些简单的命名规范、全等、单引双引等代码相关的规范,还有流程规范也一样重要。比如对代码进行 code review,尤其在改动公共库或是公共组件的时候。

最重要的还是多沟通。沟通是一个团队里必不可少、又很容易出问题的地方,我们要学会沟通和表达自己。

# 洞察项目瓶颈

我们常常会觉得自己做的项目没有什么意思,每天都是重复的工作、繁琐的业务逻辑、糟糕的历史遗留代码,反观其他人都在做有技术、有难度、有挑战性的工作,越会难以喜欢上自己负责的工作。

实际上,那些会让我们觉得枯燥、反复、杂乱的工作内容,更是可以去改善做好、并能从中获得成长的地方。涉及前端工作的业务,只有极少一部分的业务例如涉及多人协同的在线文档、或是用户量很大的业务如电商、直播、游戏等,这些业务重心可能会稍微倾向前端,更多时候前端真的会处于编写页面、最多就用 Node.js 写写接入层等状况。好的业务可遇不可求,我们在遇到这些业务之前,就什么都不做了吗?

大多数工作中,对开发的要求都不仅限于实现功能。如果只是编写代码,刚毕业的应届生花几周时间也一样能做到,那么我们的优势在哪里呢?洞察工作中的瓶颈,并有足够的能力去设计方案、排期开发、解决并复盘,这些技能更能突显我们在岗位上的价值和能力。对团队来说,更需要这样能主动发现并解决问题的成员,而不是安排什么就只做什么的螺丝钉。

一般来说,用户量较大的项目的瓶颈通常会在兼容性、性能优化这些方面;对于一次性的活动页面,挑战点存在于如何高效地完成一次活动页面的开发或者配置,通常会使用配置系统、结合拖拽以及所见即所得等方式来生成页面;对于经常开发各式各样的管理端系统,优化方向则在于怎么通过脚手架快速地生成需要的项目代码、如何快速地发布上线等。我们要做的,就是找到工作中让自己觉得烦躁和不爽的地方,然后去改进优化它们。

# 方案调研与选型对比

找到项目的痛点或是瓶颈后,就需要设计相应的方案去解决它们。而当我们需要投入人力和时间成本去做一件事,就需要面临一个问题:如何让团队认同这件事情、并愿意给