这篇文给正要架构前端项目的人提供一份参考。

1.技术不盲目追新:

    完美满足需求的技术才是这个项目最好的技术

    程序员喜欢用新技术无可厚非,但是如果项目是公司核心产品,用的技术过新,一种可能是技术存在BUG,无人解决,哪怕自己可以解决,但是不能保证团队中所有人都有能力解决。

2.技术选型不能盲目追求高逼格

    还是相同的原因,你的技术很厉害不代表团队中所有人技术都很牛,给团队成员带来太高学习成本的项目本身就不利于快速开发,在快速开发过程技术选型要尽量简单,适用,功能无需过于复杂,后期可对项目做增量升级。

3.技术栈以精简为佳

    不要选取太多相似功能的插件包引入项目,一来增加开发人员学习成本,二来会增加项目体积,导致项目运行变慢。

    不要习惯于使用第三方组件,其实很多组件实现原理很简单,自己写也用不了多长时间而且扩展性更强。

4.项目的可维护性、一致性

    一致性很容易理解,就是尽量统一组员的代码风格,书写规范,编程思路。

    可维护性就属于比较复杂的了,要视具体情况具体实施,这里重点介绍我架构的一个大型VUE项目,这个项目我们开发团队和维护团队分属于两个公司(类似常规外包模式),我们开发团队人数特别多,但是维护团队人员少得可怜。

    问题介绍:因为VUE开发过程中会有很多块切分,在最初项目搭建的时候考虑到组成员之间水平参差不齐,所以想将每个人负责的业务作为单独的模块,模块之间通过接口沟通。这本来是一个正常合理的模块化开发思路,但是在实际实施过程中,组员会将公用的功能组件拉入自己的模块进行分别开发(别人写的代码都是垃圾),导致出现很多本没必要的脏公共代码出现在项目里,并且每个人的开发风格不一致,最后导致这一部分的维护变得艰难。

    这里合理的解决方法是:强制要求组员学会书写公共代码,强制视图层与功能层分离,功能代码尽量提取合并而不是各自为政,并尽量统一代码风格,为后期接手维护项目人员减少学习成本。

5.对组员技术的提升

    很重要的一点,组员的综合实力决定了这个项目最终的结果,适时的对组员进行技术培训,让他们知道你在想的是什么,这里为什么要这么做,沟通很重要。(要不就等着组员背后骂你傻X吧,哈哈)

6.前后端沟通交流

    架构之前必须制定合理的前后端规范,约定好文档书写模式,如:字符串与整型要明确标示、哪个参数是必须要存在的,哪个是可传可不传的等等。

    如果组员有对http协议、服务器不熟悉的一定要进行培训。很多前端都会觉得这部分不是自己的事,实际上这部分双方都要处理。

7.前端与各个岗之间的协作方式

    从哪里获取了解需求,原型图的获取,UI,前后端。测试的开发测试方式,虽然这是项目经理要考虑的事情,但是了解这些可以更好的把握项目开发的缓急程度,从而更好的做技术选型。