zeromike 我做了一个微信读书分享的卡片工具，爱分享 https://www.ifenxiang.xyz 欢迎试用和反馈
今天聊两件事，一个是包壳的工具值不值得做，第二个是同样的工作，是不是谁干都能干好
包壳工具事件
前一段时间在推上，我关注的两个前端圈有影响力的人在谈论工具包壳的事情，事情我在这里不做评述，因为我在两个人的贴子下都留言了，我这里想说我只是就工具包壳的事情去评论，没有站谁，也没有为谁说话，这个世界本来就不是非黑即白。我的发言如果有人有误会，那请了解我的想法，不理解的话，那只能说很遗憾，只能说我不能让所有人都满意，我也只是一个普通人。我个人觉得冲突更多的是来自双方的信息差，愿不愿意达成共识是一个事，不达成共识出现的冲突是另一个事
咱们还是就事论事的来说说在公司里，尤其大公司里，对各种工具包壳到底有没有用，我这里给出我的答案，绝对有用
为什么
一个前端项目开发工具，好几年前，react相关的项目，本地开发和构建，就是用webpack、grunt、gulp、rollup、babel、react-router、redux等等，不像现在已经有很多成熟的包装好的工具了，尤其是在webpack上，很多前端工程师被称作webpack配置管理员，因为配置项很多，loader和plugin也很多，针对于业务场景和团队情况，需要做很多配置，再加上babel插件的配置，十分繁琐，对于很多人来说，十分不友好，主要是浪费时间，效率很低，仅说配置来说，没太多技术含量
所以为了提供业务团队的开发效率，不管是单个项目本身的迭代效率还是新开项目的开发效率，都需要一个约定式的工具集把这些开发侧的事情给固定化
ok，那么这里就会出现另一个问题，开发工具需要时间，推给业务团队使用也需要时间，那么一般的方式就是工具团队会在几个项目中验证过ok，才推出去让业务团队使用。工具的发展是通过自行迭代和业务团队反馈来迭代的，这是一个适配的过程。那你让业务团队换掉原先项目的工具，这本身就是一个难题，因为这是对一个线上运行的项目的稳定性的巨大冲击，这里需要团队老板决策的是：工具的目的是提效和稳定迭代，那么这个新引入的工具是否能够解决当前的最大痛点，影响面有多大。业务团队的开发人员对于引入一个外部工具来说，基本上一开始都不会太爽，除非这个工具能给他带来显著的价值，并且使用过程没有出过什么大问题，有问题的时候相关工具开发人员能够积极协助解决。因为对于业务团队来说，他们的第一优先级是业务价值，就是实现用户需求，并且不出问题。所以他们很关心这个工具带来的风险。担心工具不可控，出锅谁来背，担心如果有问题谁能够快速解决
我这里说一下，所谓的适配，有工具本身设计的适配，底层包装很多工具，内部的设计，对外提供给用户的配置都会在变化，和业务团队沟通后也需要适配业务团队的特殊需求，工具团队和业务团队都在发展，行业技术和自身技术视野也在发展，变才是不变，有抱怨很正常，工作不得继续干嘛
谁能够干吗
我再说另外一个事，同样的工作，技术水平不同，达到的表面效果一样，是不是说明让谁干都行
项目不复杂的话，如果看短期收益的话，我觉得可能同意谁干都行，复制粘贴都能搞定的话，技术水平不需要太高，代码也不用考虑很多事情，毕竟生命周期短嘛
但是如果是一个长期维护，迭代频繁的项目，那么每次上线都是对项目稳定性的冲击，特定需求对整体架构的影响，特定方案设计以及未来可能的影响评估，历史数据兼容，业务打点，灰度方案，线上监控等等，这些东西你告诉一个技术水平只能撑起业务需求实现的人有这样的规范要做，他们也是有心无力，再加上压缩deadline，根本不会考虑那么多事情，长期来看，各种环节的隐藏的问题都变成了历史债务，你只能烧高香或者去哪个寺庙拜拜不出问题
所以，我觉得技术水平好+项目经验丰富对于一个长期迭代的项目是很有益处的，只从项目的呈现角度去看，说谁干都行的话，评价标准有点单一，另外，我还想说开发规范的约束，需要形成氛围，怎么形成氛围，需要有榜样的影响力，需要切实给大家带来有益结果的影响，没有获益的事情，任何人做的动力都不大
找到我
喜马拉雅、小宇宙、Apple Podcasts、Snipd、listennotes 搜索大话前端