1、我目前所处的公司选择开源组件往往都喜欢找功能和业务上最贴近需求的，然后直接拿过来二次开发，这样可以少做很多事情，但是这种想法其实不太对！！！
我们忽略了找的组件的实现方案是否合理，这往往是导致虽然眼前应对了需求，但后期却越来越难开发下去，因为从刚开始组件的实现方案就不合理，这样的组件将很快无法真正满足需求！！！
所以我们找组件应该把组件的实现方案是否合理、能否长期开发下去这方面的考虑放到第一位，而要把需求放到第二位，仅作选组件的辅助参考就行，因为无论怎样都要花很多时间去二次开发，只图眼前之快，后期将损失更大(虽然很难避免重构，那至少尽量避免核心代码的重构)
比如这次的 ocr（图像智能识别） 中 multi-crop 组件的二次开发就选错了，我估计，因为ocr要求的是多区域裁剪，然后网上正好有这么个多区域裁剪组件，而且多区域裁剪就这么一个开源组件，其他都是单区域的裁剪组件，所以当时就这么草率的选择了这个 multi-crop 多区域裁剪组件进行二次开发；现在严重的问题发生了，选组件时根本没去考虑裁剪区域的实现方案是否合理，正常这种动态显示的裁剪区域为了更好的性能，一般都会使用 canvas 或 svg 去实现（我看到阿里云的ocr 就是用 svg 去实现的），canvas 和 svg 都是以计算的方式去动态生成的，性能好得多，而这里的 multi-crop 组件为了图方便，直接用动态遍历集合的方式动态生成 div 封装的组件开实现裁剪方框，这就是很严重的问题了，因为每个div上都要动态添加样式、事件，这些都是用代码一个一个用遍历写死的，这性能方面可想而知，要想用这种方式来优化内存和画面不卡的问题，难度可想而知
2、我目前所处公司前端开发的过程有待优化：设计图是一个页面一个页面出的，出了一个页面就开始开发了，然后前端缺少一个技术主管，没人去合理管控前端的开发架构和模式，都是把开发任务直接交给一个人让其随意开发了，代码风格要求还可以，但是开发架构上实在太乱，所有页面几乎都是每个业务页面就是用一份单独的js去实现，好多相同的页面都要写好几份相同的js，一旦出现一个问题，几乎好多页面都要修改，实在不合理；
我曾经管理团队，前端开发分为3层架构，组件层、模板层、业务页面层；
组件层：是一个一个单独的小零件，有的是自己开发的，有的是基于开源组件二次开发的；
模板层：不是凭空开发的，是先要根据设计图，把相似的页面都分组整理出来，然后一组相似的页面就去开发一个模板组件，一些页面共有的UI和功能都会集中在模板组件中开发，当然若要模板层更优，模板层也要分出基类模板层，多个模板公用的UI和功能都在基类模板组件中实现，其他子模板基于某个基类模板层即可，如此复用性和可维护性更高，出了问题改一处即可，避免重复劳作；
业务页面层：当开发好一个模板组件后，再开始开发对应的这组页面的业务页面了，一些特有的功能就再业务页面进行实现；
以上3层架构的好处：将一个页面的功能解耦、模块化处理，减少业务层代码量，业务层就关注于业务开发，公用的功能出来问题，只需要改一处代码即可，层次分明提高复用性和可维护性，随着模板组件的增加，后期遇到相似的页面，只需要使用相同模板进行开发，随着整个项目的成熟，越后期开发效率越高
当然，一些非常独特的页面是没法实现模板的，强行实现模板反而导致鸡肋了，一个永远都没有机会去复用的模板组件是没有存在价值的；
如果刚开始只有一个页面，但感觉好像以后可能会存在相似页面，也不要盲目直接去开发成模板组件，因为开发成模板组件需要考虑很多复用性问题，也为了高效，这种情况也只将这种页面开发成业务页面即可，就是这种业务页面开发的时候要尽量把代码整理干净，能封装的封装，尽量注释，为了后期真出现相似页面了，然后再去开发模板组件的时候，可以方便的挪用代码，复制粘贴，提高后期开发效率
网友评论