1、前端成员管理
成员管理涉及以下几个方面：团队技术水平、团队基础建设、团队考核
团队技术水平：技术能力、沟通能力、质量把控和风险预测能力、业务能力等
团队基础建设：npm私域，脚手架，基础组建开发等
团队考核：要尽量做到公平
2、项目沟通
项目成员角色有：产品、设计、开发（前端开发、后端开发）、测试、运维
项目流程为：需求导读->设计导读->技术设计导读->测试用例导读->上线文档导读->上线
在项目建设过程中，沟通是必不可少的，遇到问题不能单纯的靠自己理解，要及时多沟通，对于：
1）需求有问题的点要及时提出来
2）设计不合理或者难以实现的地方要提前说，跟设计人员沟通更合理以及易于实现的交互方式
3）接口层面不合理的点也要及时提出
4）及时响应测试人员的问题，不能不管不顾或者因为你们理解不一致就搁置问题
5）运维层面沟通会较少，但是要积极配合生产问题排查
所有的问题都要及时提出，不要硬着头皮实现，尽量沟通出来一个合理的实现模式，切记不要通过前端代码帮后端实现一些前端实现会有bug的功能，注意不要埋雷。设计方面如果交互过于复杂，也要积极沟通，不要写一堆bug，给项目质量埋雷。
3、外包管理
我认为厂商管理最大的问题不在于外包的能力，在于流动性，流动性会带来很多问题，人员更换批频繁会造成代码比较杂乱以及难以维护，解决这个问题就需要建立易用好用的规范，范不能过于复杂，过于复杂实用性不高和学习成本很高，对于整个团队的效率有不好的影响。
框架设计层面要有意识的降低代码复杂度。
1）代码可读性，维护性
一个项目如果想好易于维护，那么代码必须有良好的可读性，可读性代表代码的一致性要高，不能每个人写一套逻辑，看完一个业务流程的代码还要再看一个，类似的业务流程要做到看完一个，其他的都知道，只有业务细节不一样，但是代码整体框架学习一次就可，不能类似流程每个都要学习。
2）代码可靠性（质量）
可靠性可以从测试来说，同一个规范同一套相似的代码，前期已经成熟，那就尽量要复用（或者复制）其他流程的代码，没有充分的理由不要搞创新，因为新的写法和模式都会产生新的bug，前期已经稳定的代码表示bug基本都被避免了。
3）可复用性
可靠性里面也提到了复用性，复用性能够有效提交开发消息，其实1、2、3是相辅相成的，不是独立存在的。
总结来说就是要从框架层面降低代码复杂度，从书写层面保持良好的代码规范和一致性。
另外一个层面就是代码review的时候减少个性化理解，减少扯皮。
