本文转载自微信公众号「bugstack虫洞栈」，作者小傅哥 。转载本文请联系bugstack虫洞栈公众号。
研发已经讨厌我了!
傅哥，我是刚来公司的产品，就是还懂点技术的产品，因为我以前也是学的软件工程专业，但不太喜欢写代码就想着做产品吧，指挥别人写代码。梦寐以求的想法终于得以实现了
我通过王者辅助、零食投喂、介绍对象的方式终于和研发打成一片了，但最近他们有点讨厌我了。因为我接到了个业务老板着急要上线冲量的需求，但因为上线节奏过于着急从BRP评审到PRD产出已经占了大部分时间，到研发和测试完成上线的排期只能倒排，而且这期间还总是修修改改的补需求，研发说他的代码已经成屎山了，而我就像那个搅屎棍，临近提测又来了一杠子!
那，这杠子我不想再当了，我想知道都什么情况让码砖兄弟头大，我尽可能以后绕开，我是一个有良知的好产品!
以上是杜撰的一段，不过也就差念身份证了，基本只要写代码的研发，就会遇到各种各样的产品，但并不是所有产品都了解研发写代码怎么就会遇到这么多问题，因此想结合这段来讲讲那些有坑的路上，我们研发是怎么走的。
那些年踩过的坑
1. 新码的，着急上
当一个新的需求来不及让研发思考、设计、评审，所预留卡死的上线时间后，只能是堆人的方式怎么快怎么写功能，不会有文档、不会有注释、不会有单测，尤其是在这个阶段还有很多是产品没有确认清楚的功能反复修改时候，就更会把代码的实现搞得一团糟。
可能产品、业务，甚至是提这个需求的老板也搞不清楚，就是写代码吗，修修改改有那么难?有，这就像原来你给了一堆捡来的砖头、扣来的泥沙、手画的图纸，需求是盖一个厕所，现在厕所的坑挖好了要起架子了，不行改，我们不要厕所了，要猪圈。好像猪也得拉屎，挖的坑也够用，修修改改，扩大扩大面积，猪圈好像也行了，但这个时候埋下了很多的隐患，指不定猪进场的时候，就给你拱塌了，但就在即将贴膏药式修补猪圈安插水管的时候，产品传达了老板的最新意图，这个场地现在咱们决定要住人了，得给这UI界面改改，再豪华装修一下。都知道盖房子挖地基，放到写代码上好像就不懂了
举个例子，代码是怎么死的
- 需求无规划，想要啥就加啥，加着加着就出事故了。这也是大部分研发一天天在面对的场景。
- 从一个需求的提出到研发开发、测试验证、上线部署，这些过程都需要合理评估时间来执行，否则就不会有像苹果IOS那么好的体验产品。
2. 交接的，堆屎山
你以为你开发的工程都是从零开始吗，其实并不是的，尤其是互联网公司经常快速调整适应市场变化，也会导致你所接手的代码可能是别人写的，甚至是很多个别人累计写出来的，而你之前写的想宝贝一样的代码，也会被别人拿去堆成屎山。
屎山代码是什么样，同样是vo2dto有12种以上的写法、json2object 也有常见的3、4种、生成个编号ID也是N多种方式。那么现在任何一个人接手别人的代码，根本找不到文档、也看不注释、方法名也是随意英文和拼音，把queryBatch写成queryBitch也是常有的事。所以，就这么多花样百出同样功能多种实现方式的代码，怎么能更快的在里面迭代需求呢。我不知道我要改了什么，但别人加的我也不敢删
产品可能又不懂了，那不是删了就可以吗，会有难度?有，这想啥呢，比如你家里是一个三居的格局，有卫生间、有厨房、有客厅、有卧室，第一任住客还算讲究安装了马桶、买了沙发、装了卧室的床，后来交给中介出租，中介说这不浪费吗，厨房这么大也没安装啥，拆拆装个床，再装个马桶，独立卫浴，还多租一间。客厅也给它打个隔断，接个上水管和下水管，也给它来个独立卫浴，主卧、次卧都装独立卫浴。好，后来房子交给你了，你整租了，发现这屋里到处都是马桶，拆哪个的时候，都开始往出喷水，不知道他们的水管是怎么链接的，与找师傅修的成本看，不如都拆了重新装修了。这像不像，代码根本没法重构，只能重写!
3. 复用的，不合身
不能重复造轮子，已经有现成的你为什么不用，你自己写的这个有什么创新，为什么不找某某部门调研下，你这是不是技术自嗨。你听了还怕不，吓人不，明明你可能就是为了更好的、快速的、熟练的把项目写完，但现在你为了做一个项目，需要跑遍所有部门调研他们都有什么组件能支撑你的需求，之后开始要文档、对接、联调，好，你的需求可能原来并不大，现在一对接你甚至从原本三天干完的事，现在要干两周。妥妥的增加工作量，年终奖又是你的了!
一般在述职、答辩、汇报的时候，大家都把自己做的事包装的非常牛皮，甚至只要是用上你这个组件，公司都能早上市三年。但一汇报完，再去找问你这个东西是否能对接的时候，完了，这块不支持，那块不能做。为啥?因为一个需求功能的设计很多时候是偏向于自己业务诉求的，而不是一个统一的标准方案，不能解决其他业务部门的个性所求，甚至为了支持很小的一部分功能都要从头到尾的梳理和开发，加表、加字段、写类、写方法、写单测，一全套下来并不是那么容易的就支持了，可能支持不好还给自己的系统带来非常沉重的负担。
产品可能又不懂了，复用一下不是减少开发了吗?这就像啥呢，一个老爷，家里大老婆和几个姨太太，大老婆位置稳平常就当当评委，分分蛋糕，大姨太喜欢表现自己，和大老婆走的近，没事就给老爷和大老婆汇报最近的工作成果，小姨太刚进门没有什么成绩，跟老爷说想做个裤衩穿，老爷说那大姨太上次汇报说她那不是有裤衩吗，你还浪费那工期干啥，去复用一下就穿呗。小姨太找到大姨太，问裤衩能不能借来穿穿，大姨太说有点难呀，我这裤衩太小了，你那身材也穿不进去呀，我要按照你那尺寸改，都能提到脖子了，你看看要不我们找老爷说说，你就说你的裤衩比较定制，还得要一些特殊功能，比如说展开是裙子、收起来是裤子、夏天是裤衩、冬天是棉裤，这样就给你批了，你就创新了。
爬上来皆是过往
1. 提高自身能力
在职经历了这么久，让我深深感受到，即时非常有技术含量的项目在没有太多经验的研发面前，也能用CRUD+整篇的ifelse写出来，产品的PRD流程是啥样，代码里的分支判断走向就是啥，不会有点的模型抽象也不会有一些共性提炼，这样方式的写代码只能是让代码一篇篇的烂下去，这与产品无关、与排期无关、只与自身的技术能力和项目经历有关，也许只是因为你写，所以才会这样。
经历了这些以后我会每次开发新的功能都与上次做对比，把那些比较不错的实现方式复用下来，再把实现的不太好的地方进行优化，一点点沉淀出自己对技术实现过程的经验积累。慢慢也就有了一定的条件反射，知道那些项目会刺激到我创造出更好的设计，那些项目可以复用我之前的逻辑，这样既能快速且高质量的完成需求，又可以满足产品功能的迭代。每一次成长，都是自己的收获
2. 遵守规范标准
其实你要知道人并不是稳定输出的机器，只要是人在写代码就一定会有不规范、缺流程、出异常的情况，因此这些需要有一个制定的标准，大家统一按照一个方式进行执行，这样即时在出问题的时候，也可以很快的定位和处理，否则你用一个方式开发，他用另外一个标准编码，最终一个团队就要维护两套内容，即耗费人力又可能出问题。
尤其是我们开发的项目并不是小作坊的时候尤其重要，从市场BD，业务运营提出BRD、产品评审PRD、架构做设计、研发做细节、代码要评审、完成要提测、上线要把控、交付要验证等，每一个环节都需要有执行标准，如果整个组、整个部门、整个公司，都有标准的流程规范，即时在交接代码、协调资源、共同开发时，也都不会那么多的障碍在阻隔我们深厚的码砖情义了。
3. 产研测多沟通
我们并不能保证产品不改需求，即使是快到要上线的时候，因为市场、因为风控、因为流程、因为财务等等，可能甚至都不是研发所能知道的一些特殊原因的情况下，不改需求根本就不可能让你上线。那研发可能会问，为什么不能早早的提出来，那是因为这些特殊情况都是来自于不确定性，就像我们跑着的代码一样，没人知道是因为网络、IO、负载、明星突然官宣流量猛增，而导致出问题的。
为了能更好的承接产品需求，最好的方式就是沟通，多沟通，尤其是在产品需求设计初期，提前查看他们的PRD文档，这里可能有很多内容是你可以提供的服务，也有一些是产品在犹豫使用哪种方式实现的功能，在与你讨论后，而决定复用你已经有的系统。所以沟通真的可以给你后期开发带来很大的收益，减少很多不必要的事情的蹦出来!
- 业务，不要做产品的渣男
- 产品，不要做研发的渣男
- 研发，不要做测试的渣男
- 测试，不要做业务的渣男
做一件事，就把一件事做好，我们都不做下一环的渣男，也是对自己成长的负责!
