觉得公司的流程不合理又无能为力该离职吗?

本人web前端，目前工资税前10左右，最近有点想离职了，觉得公司流程不合理，公司对bug有考核，前后端都做考核，每年加薪30-40%，考核完作为加薪的依据前后端指标一致，但是相比于后端，前端bug更多，举个例子，提示语错误或者不友好是前端的bug，比如请输入正确的密码？测试觉得请您输入正确的密码更好，于是就提了一个bug给我。说难听点，测试想提，前端就可以提无数的bug，我觉得正常提示语应该是UE/UI给出的，但是在这家公司变成了前端的活，UE/UI只给个界面设计，具体过程中的提示语全部前端自己提供。感觉太憋屈了，自己认认真真重复验证整个交互，结果因为提示语被提了很多bug？自己最近也变成杠精了，做前端没以前开心了，常常为了几个提示语跟测试扯很久？其实有时候觉得挺合理的，但是涉及指标又不想改。只要你改了就相当于承认是bug了。另外一点就是设计验收，UE出图的基准是1920x1080，但是实际上，作为前端肯定得考虑低解析度的情况，所以有些是使用百分比，或者一些flex布局，但是测试验收的时候精确到了像素级别，很难满足，去年bug有40%来自提示语修订，20%来自像素不合格，比如按钮A是距离按钮B20px，我只做到18px，有时候不是不能，而是没必要，如果非要完成指标，那就是用媒体查询一个解析度做一个了，但是感觉真的没必要，真的心态要崩了，长久下去，一点升职的机会都没有。另外最近我发现我是我们组里面工资最低的，比倒二低了1k不止（工作一年后吃饭的时候才知道，之前为了协议和心态也没问），但是事情却没少干，甚至比一些人干得多的多。

工作流程有问题，就试著去改善它，完善它，抱怨是没有用的。你在能够写好代码的同时帮助团队解决了流程问题，你一定会成长很多，领导也会对你刮目相看。

针对你目前的状况，我们来看一下在流程上有哪些点可以改善：

1、制定 UI 规范

把一些共性的，产品，测试以及设计师达成共识的规范落入文档，比如一些提示语和像素尺寸都可以纳入规范里面。那些地方是按照百分比处理，那些地方是按照像素固定值处理都可以在规范中说明，刚开始不全没有关系，可以逐步一点一点完善。

在规范的基础上，设计师出的原型设计稿需要把一些大小、间距等像素值，颜色色号都标注清楚，让开发人员和测试人员，严格按照设计稿执行。如果有需求变更调整，往往在很多情况下产品经理就直接找开发去改了，这个时候其实是需要设计师把设计稿也同时改到，作为测试人员的测试依据。顺便这里提一下，所有的需要变更都需要告知对应的干系人。

2、加入 Test case review 环节

Test case review（通常是一个会议），每一个新功能开发前，PM 在介绍需求的时候，测试人员必须参加，随后, 开发人员在做开发设计的同时，测试人员写测试用例，在写完用例后，产品，测试，开发一起过一遍测试用例。这个过程可以有几个好处：1.可以让需求中不确定性的点，通过这个环节确定下来。 2.为测试人员的测试过程提供依据，并达成共识。 3.可以让开发明白在开发过程中那些是需要注意的点。