本文转载自微信公众号“bugstack虫洞栈”，作者小傅。转载本文请联系bugstack公众号。R&D已经讨厌我了！付哥，我是刚来公司的产品，对技术还是有点了解的，因为我之前也是软件工程专业的，但是不喜欢写代码所以想做产品指导别人写代码。梦想的想法终于实现了。通过kingassists，snackfeeding，和introductionobjects终于接触到R&D了，但是最近他们有点讨厌我了。因为接到一个急着上线的企业老板的需求，但是因为上线节奏太着急，所以从BRP审核到PRD输出的时间已经占了大部分时间，上线的排期到研发和测试的完成只能是逆向的，而这期间，我总是修改修改补充需求。R&D说他的代码变成了一堆屎，我就是那个搅屎棍。临近考试，又是一团乱麻！好吧，我不想再成为这种废话了。想知道是什么让码砖兄弟们头疼不已。以后我会尽量绕过它。我是有良心的好产品！以上是杜撰的段子，但要读身份证几乎是不可能的。基本上只需要编写代码进行研发即可，你会遇到各种各样的产品，但并不是所有的产品都明白研发和写代码会遇到那么多问题，所以我想结合这一段来谈谈那些有坑的路，我们的研发是如何走的。那些年踩过的坑1.新代码的人急着上当。一个新的需求，研发没时间去思考、设计、审核。将没有文档，没有评论，也没有单元测试。尤其是现阶段，当有很多功能没有被产品明确确认，反复修改时，代码的实现就会乱七八糟。也许提出这个需求的产品、业务，甚至老板都想不通。只是写代码吗？修改有那么难吗？是的，就像你给了一堆捡来的砖头和泥土，手绘图，需求是建一个厕所，现在厕所的坑已经挖好了，还得摆架子，不能被改变。我们要的不是厕所，而是猪圈。看来猪也要拉屎，挖的坑够多了。修改修改，扩大面积，猪圈看似还好，但此时却埋下了很多隐患。说不定等猪进了田，我就给你。拱门塌了，但就在猪圈准备用灰泥修补、安装水管的时候，产品传达了老板的最新意向。现在决定住进这个地盘了，只好换个UI界面，装修的豪华一些。我们都知道盖房子打地基的时候，写代码的时候好像不懂。例如，代码是如何消亡的？需求没有计划，想加什么就加什么，加了就会出意外。这也是大部分研发每天都面临的场景。从一个需求的提出，到研发开发、测试验证、上线部署，这些过程都需要一个合理的评估时间来执行，否则就没有苹果IOS这么好的体验产品。2.交接，一堆狗屎，你以为你开发的项目是白手起家的吗？其实不然，尤其是互联网公司往往会很快适应市场变化，你接手的代码可能是别人写的，就算是很多人写的，你之前撒娇写的代码也会被别人堆成一堆狗屎。石山代码就像，vo2dto也有12种以上的写法，json2object也有3、4种常用的写法，还有N种生成数字ID的方法。所以现在接手别人代码的人根本找不到文档和注释，而且方法名也是乱写英文和拼音。将queryBatch写成queryBitch也很常见。那么，有那么多代码对同一个功能进行多种实现，我们如何才能更快地迭代需求。不知道自己要改什么，但是别人加的商品我也不敢删。也许我不明白。删了不好吗？这会很难？是的，你怎么看，比如你家有一个三层住宅，布局有卫生间、厨房、客厅、卧室。第一个住户讲究装马桶，买了沙发，卧室里装了床。后来，他交给中介出租。代理人说这不是浪费，厨房那么大没啥可装的，拆装床，装马桶，独立卫生间，多租一个房间。客厅也是隔断的，上下水管相连，还为它提供了独立的卫生间。主卧和次卧均设有独立卫生间。好吧，后来房子交给你了，你租出去了，发现房子里到处都是厕所。拆掉一个后，他们都开始喷水。我不知道他们的水管是怎么接的。跟找师傅修是不一样的，从成本上来说，还不如拆掉重新装修。不像啊，代码根本无法重构，只能重写！3.可重复使用，不适合，不能重新发明轮子。为什么不用现成的？你自己写的有什么创新点？你为什么不找到它？某部门调查下，你是不是技术狂妄？你听了不害怕吗？很明显，你可能想更好、更快、更熟练地完成项目，但现在你需要去所有部门调查他们必须支持哪些组件才能完成一个项目。为了你的需求，你会开始需要文档，需要对接，需要联调。好吧，一开始你的需求可能并不大，但现在你甚至需要做两周来对接你原本三天做的事情。适当加大工作量，年终奖又是你的了！一般在报、答、报的时候，大家把自己做的事情打包的很牛皮，甚至只要你用这个组件，公司就可以很快上市三年。但是一旦report完了，我去问你这个东西能不能接的时候就完了，这部分不支持，那部分做不了。为什么？因为一个需求功能的设计往往偏向于自身的业务需求，而不是统一的标准解决方案，无法解决其他业务部门的个性化需求，甚至从头到尾只支持一小部分功能。整理开发，加表，加字段，写类，写方法，写单元测试。支持一套完整的并不是那么容易。它可能得不到很好的支持，会给你的系统带来非常沉重的负担。也许你又不了解产品。复用不是减少开发吗？就像一个主子，一个大夫人，几个小妾。大太太地位稳固，平时充当判官，分享蛋糕。阿姨们太爱炫耀了。我和大嫂亲近，闲着没事就向师傅和大嫂汇报最新的工作成果。小姑姑刚进来，没有什么成绩，就跟师傅说要穿内裤。师傅说，上次阿姨反映说她不是有内裤吗，浪费那个工期干嘛，重复用完再穿。阿姨找到阿姨，问能不能把裤子借来穿。阿姨说有点难。我的裤子太小了，你穿不进去，我想换成你的尺码，我可以提一下。脖子断了，看我们跟师傅说，你说你的裤子比较定制，需要一些特殊的功能，比如展开裙子，折叠裤子，夏天穿裤子，冬天穿棉裤.这样，给你批了，你就创新了。爬上去都过去了1.提高自己的能力工作了这么久，深感即使是非常技术性的项目，在研发前也可以用CRUD+整个ifelse来写，经验不多。产品的PRD流程是什么，代码中分支判断的方向是什么，不会有模型抽象，不会有共性抽取。这样写代码，只能让代码一点一点烂掉。跟产品无关，跟进度无关，只跟你自己的技术能力和项目经验有关，也许就是因为你写的，所以才会这样。经历过这些之后，我每次开发一个新的功能都会和上一次进行比较，复用那些比较好的实现方式，然后优化不好的实现方式，逐渐积累自己对技术实现的理解。过程中的经验。渐渐地，我有了一定的条件反射，知道那些项目会刺激我去创造更好的设计，那些项目可以复用我以前的逻辑，这样就可以快速高质量的完成需求，产品可以满足Iteration的功能。每一次成长都是自己的收获二、遵守规范和标准其实你要知道，人不是机器，输出稳定。只要人在写代码，就会出现不规范、流程缺失、不正常的情况。所以，这些需求是有一套标准的，大家用一种方式统一执行，这样即使出现了问题，也能快速定位和处理。不然你用一种方式开发，他用另一种标准编码，最后一个团队要维护两套内容，既费力又可能出问题。当我们开发的项目不是小作坊时，这一点尤为重要。从市场BD，业务运营提出BRD，产品评审PRD，架构设计，研发细节，代码评审，完工测试，上线管控。交付需要验证等等，每个环节都需要有执行标准。如果整个集团、整个部门、整个公司都有标准的流程规范，即使在交接代码、协调资源、共同开发时，也不会有那么多的障碍阻隔我们深厚的友谊。3、我们不能保证产品在产学研测试中通过更多的沟通不会改变需求。甚至快要上线的时候，因为市场，因为风控，因为流程，因为财务等等，可能连研发都不知道。如遇特殊原因，不更改要求是不可能让你上线的。那么R&D可能会问，为什么不能早养呢？那是因为这些特殊情况来自不确定性，就像我们正在运行的代码一样。宣传流量飙升，由此引发问题。为了更好的满足产品需求，最好的方式就是多沟通，尤其是在产品需求设计的前期，提前查看他们的PRD文档，你能提供的内容可能有很多，有些是products在犹豫过用什么方法实现功能后，跟大家商量后，决定复用你们已有的系统。所以交流真的可以给你在后期的开发中带来很多好处，减少很多不必要的东西弹出来！测试，做生意不要做没心没肺的人，做好一件事，做好一件事，下一环我们就不会做没心没肺的人，我们也要为自己的成长负责！
