所谓“前端能力不足”

前言

随着前端越来越多的被提上日程，用户对产品的体验度要求越来越高，产品除了实用的特性还必须满足方便用，美观，交互好，人性化等一系列的操作，谁的产品先做到这些，就能获取用户的青睐。那么这样一来，前端无形当中追加了很多工作量，所以前后端分离是趋势，不可能要求后台去很多精力花费在帮我们吧数据和前端的静态效果以及相关的资源整合上。让大家分别去做各自擅长的事情。 那么问题就暴露出来了，当对前后端能力要求、测试要求不一样多不一样难得时候，前端就会团队中处于短板，这在中小公司很常见。因为优质的前端是稀缺资源。

突出问题一　前端能力不足　

1. 问题列表　
   • 某些特性化的，有难度的需求做不来
   • 代码的模块化，可维护性不强
   • 修改ｂｕｇ的能力以及效率有限
   • 分不清楚优化、需求、缺陷、bug不同等级
   • 开发时过于粗糙，不能综合考虑各种数据情况、操作的容错性不好
   • 貌似其他职能没毛病
2. 　解决方案
   • 需求走前端部门统一评审，按照难度等级、可实现等级、替代方案处理，不计入基本的开发中
   • 普及模块化开发的基本方式，增强写注释、团队协作的培养
   • 学会自己的妥善分类，对于需求、缺陷等明确分类，参照前端整体分类
   • 基本的培训，案例分享，在产品不做相关处理的时候，希望前端应该有的基本处理
   • 请问各个其他职能有做好自己的事情么，是否够专业，现在只是因为前端的问题是暴露出来的而已，我们的后台、设计、产品、测试都无可挑剔吗。如果真这样，为什么不把前段淘汰或者这些人去更好的公司谋求更好的待遇和发展空间。

突出问题二　需求不明确，测试提需求加优化

• 首先不可否认，测试可以提一些优化或者特殊的需求，但是如果这个比例远远超过了bug本身的比例，那么这部分就是不合理的，应该从以下几个角度避免。
• 产品原型最大程度的明确应该有的产品细节，包括各种数据，数据可能情况，意外情况，用户交互，交互效果，数据验证，插件，等等。举例说明：产品不能说这个地方需要轮播图，而应该说是这个页面什么位置出现多大规格的几张轮播图，最多几张，最少几张，播放效果如何，有没有默认图，跳转的链接是什么，图片来源是什么，什么格式等。
• 测试应该有自己基本的测试准则，不要每次都没有准则，没有原则的去测试全部的需求，个性化的测试我们要尽量规避，尽量约定统一的规则，尽量参照原型以及需求来进行相关的测试，默认认为如果符合产品设计的90以上的要求，那么这轮测试才是符合产品和开发预期的，而不是直接70以上的测试提的问题都是产品从没提过的、没说要做的。
• 项目经理控制好整个的测试联调过程，保证基本的缺陷都解决的情况下，尽量在开发周期内完成具体功能模块完整的上线，对于不能很好的实现的，被砍掉的需求要做到下一版本的迭代，而不是全部列入bug修改中。
• 测试以及联调修改过程中没有周期版本性概念，一直是不间断的断续的提问题，而对于所有问题没有任何规律性，等同于过筛子，期望是整体过一遍功能后，模块仔细测，保证模块可用，而不是每个模块都测点，最后每个都有问题，都不能上。

突出问题三　线上版本bug多，发现就及时改

问题１：为什么之前bug的有那么多，还能上线 问题２：为什么那么多的bug都必须是当天提，当天改的，有这样严重么 问题３：我们提的bug有没有规律性，是无意发现的还是必然的，我们是否经常进行大规模的一次产品优化，吧这些纳入到开发状态，而不是一味的不断续的改问题 问题４：当天问题当天改，能改完么，改的这些bug谁会记录，属于哪个产品版本

突出问题四　前端暴露出来很多分支提交问题

１首要责任在前端 ２前端做不好，为什么不让有能力的人去做，或者交给他怎么做 ３是不是很多源代码不是前端写的也让前端背锅 ４项目架构不明显，增加了前端开发修改的难度，建议尽早前后端分离，而不是四不像的结构和合作方式

突出问题五　团队协作

• 团队协作需要有基本的协作常识，互相帮助，怎样才能让对方更方便高效的协作，建立基本的规则，如果不能保证各种个性化的要求的，就要给其他职能提供最基本的原则性的支持。
• 人员角度的互相帮助，责任是要追究的，但是团队需要互相体谅，共同承担压力和责任的，遇到问题要沟通问他，帮他解决问题。只有最上面的人才是boss，可以只关心任务和结果，每个团队的具体成员都关心的是自己如何去实现，有什么难度，如果做不到，谁可以帮我；如果做得好，怎么分享给其他人；如果自己有能力有经验去帮别人做点事情。
• 每个职能对于专业能力认识不够，专业能力不足导致很多后续问题。所以职能主管或者职能培训是必须的。