[TOC] ## 前言 本文主要借鉴宋小菜的大前端的部门结构以及一些分享列出可参考内容。 ## 基本认知 ### 链路足够长，就可以出工具 链路足够长，每个节点都可以变成产品，必要时可以通过技术的手段形成工具。 ### 以人为核心的做事 创业公司的技术团队本质就是人和事，用合适的人做合适的事就能得到理想的效果，人才的瓶颈是公司产品落地速度和质量的瓶颈。 之前的管理 ，如果一视同仁，对于人员过于扁平化，大家做一样的事，认为能力是一样的，培养或者基本不培养能力，关心或者不关心兴趣方向，跟进相同的业务线或或者随机分配，技术人员经过1-3年的职场工作之后就会对技术缺乏初心，觉得在公司受到了极大的限制or瓶颈。那么公司的技术团队就会不断的流失人才，而留下来的员工或者是按部就班的做事并不能发挥额外的价值，或者是公司做一定的改革或者变更团队的人事任命。 ## 团队管理 ### 人才梯队层次 基础架构，基础建设，业务上层 ### 人才成长规划 兴趣栈，能力栈，公司关系 ### 人才能力拓展 单人能力和团队能力形成互补 ## 梯队讲解 ### 架构 技术最专精，有丰富的项目经验（不局限于当前项目），技术采用前卫的技术，为公司提供技术储备 ### 技术基础建设 采用稳定成熟的技术成果，尽量减少风险技术、兼容成本技术，上手难度高的技术 ### 业务层 可以用技术基础建设解决80%以上的风险和问题，具有一定的底层开发能力，如果没有，需要进行系统的培训，开发演练，注意事项等。（可以让实习期或者试用期的人常尝试开发历史项目），这就要求再之前的开发中保留某阶段开发的产入和产出，这样可以通过这段的适应以及无风险常识，更早的暴露问题。 ## 技术选型结果 ### 工具类 依赖node ；周边mongodb,redis,mysql,shell,python ### 业务类 强依赖react/react native ,适度集成其他技术，比如redux,graphql,apollo ### 框架类 react，其他的会谨慎，node端会有koa,thinkjs,eggjs 配置文件可以使用某模块的配置，尤其不同配置的情况，减少人为的修改失败 。 ## 组件库 分为基础组件 业务组件 尽量脱离或者团队内禁止使用第三方库，如果使用的话 进行使用约定，对于每个组价进行详细的编写约定。花费足够的时间去讨论组件是够是合理的，有用的。 ## 其他 node可以做接口聚拢或者接口拆分，实现基于页面的api优化 通用的工具技术方案 通用的技术模块和业务模块 团队整体问题解决套路：解决问题的思维方式