这段时间搞Vue开发的一些坑（优化项目交付流程）

       最近项目组忙不开，暂时放下手上的事情，给项目组开发一些组件。这些天真的是心力憔悴，现在讲讲这些天遇到的一些坑。

       项目采用前后端分离技术开发，前端使用Vue + ElementUI来实现页面效果。我过来开发一个侧边的导航组件还有支持表情输入的富文本评论组件，还有几个定制的轮播组件。下面就是坑了，说出来释放下这些天的心里压力。

       1. 一定要在工程上开发前台组件，并及时测试整体的展示效果！

      我接收开发任务后，想着方便就单独起了一个工程，在上面测试开发的组件，并单独测试组件的效果。结果就是：在独立的工程上样式是好好的，整合到大工程上简直就是面目全非！虽然说是组件化开发，但是因为不同开发的习惯，可能会出现给类命名的时候出现同样的问题，而且并不是所有的人都会在style标签上加上scoped的属性！太坑了，花了不必要的时间解决样式问题，很浪费时间和精力。

       而且在开发中，大部分前台开发发现样式不生效的情况，直接上面加上了!important，头都大了，你不能改其他人的代码，你的样式还被其他人覆盖了，没办法你也加上!important，到后面项目里面全是!important，非常不利于开发和维护。

       所以，建议在开发组件的时候，使用层级关系来进行css的编写，如less，可以减少很多麻烦。

       2. 分析项目开发时间剩余和需求修改的方案可行性

       原定开发时间只剩下半天的时候告诉我该需求，还是大改，还要玩花样。该需求不是不可以，你改的话就延长交付时间。所以，最好从流程上优化。很简单的道理，开发时间短，交付时间不变，需求更改频繁，人在高度疲劳和精神紧张的情况下是很容易出错的，而且测试也没有充足的时间进行测试，打乱了原有的开发计划，最终是极有可能影响最后的交付质量的。大部分产品经理或者业务分析人员，需求方说什么是什么，压力全在开发团队上。作为迭代版本，最好评估一下当前的开发进度和需求变更的工作量是否过大，然后在决定是不是把这个变更需求加到当前版本。上线前该需求，都没时间测试，这东西非要上线你说不被客户骂都难。

       3. 给需求分析人员或产品经理的建议

       一般需求传递的流程是：需求方 -- 业务分析人员 -- 开发人员，中间可能略有缩减，不同的公司可能有所不同，但其实是一样的。业务分析人员的工作不是简单无脑的传递需求方的需求，而是需要了解业务，去帮客户分析怎么样才是好的方案，客户说的内容有些时候是单纯的基于业务来描述的，业务分析人员要根据系统可行性和业务诉求来合理的给予建议和意见，引导客户，这样既能满足客户的诉求，又可以将主动权放到自己的手里，这样大家都好过。如果就是单纯的传话员，那么客户有些时候提出的东西天马星空的，按照他们说出来的做出来的东西可能根本就不是他们想要的，大家白费功夫。

       说的有点多，其实就是想说说坑的，问题上升了，大家有不同意见欢迎交流。