请教一下老哥们平时做开发有什么心得，最近新入职一家公司

[FieldFarmer]

我只做后端开发。先说下这家公司的开发规范很少，基本上按照架构能实现功能模块交给测试那边测一下就行了。

首先是产品搞一个需求出来（产品貌似不太懂技术），然后画好原型图，原型图我看了，略显粗糙，我由于刚入职，不太清楚他们有没有原型图设计的规范或者评审，至少我拿到手开发的时候，第一感觉是这样的：一些字段描述不清晰甚至缺失，在没有规范的情况下我需要靠自己的设计能力来设计表的字段，甚至有的字段是整型还是字符串型我都不太能确定，全凭自己的经验来设计。

之后大家开个会由产品大概说下业务流程之后就回去开发了（前后端分开做，开会期间反馈一些疑问，但不全面）。

最恐怖的来了，在以上的开发背景下，我抱着一种不确定的心态在一个人搞这个模块的后端接口以及数据库表的设计了两周!两周之后才开始由前端联调，这和我以前做全栈的方式截然不同，导致这周在和前端联调过程中果然发现了很多问题（前面说了开发规范很少，基本沿用前人的代码架构逻辑，我更不清楚前端调用有什么规范如何），然后就是反复的修改接口，调整接口，甚至有时候需要修改表字段...20 多个接口虽然都写完了，但是没有一个是敢说没 bug 或者完全符合需求的。

请问下老哥们有没有同种遭遇的，你们公司的解决方案是什么呢？加强产品原型设计能力？增加需求设计评审环节？

[DuDuDu0o0]

你们公司的解决方案是什么呢？ -> 接口文档
加强产品原型设计能力？ -> 开会时当面质问 PM ，业务逻辑又问题
增加需求设计评审环节？ -> 大多 curd 不需要设计评审，除非改动太大

[FieldFarmer]

@DuDuDu0o0 #1 谢谢，接口文档是我自己加到 swagger 上面去的，方便给前端看的，并不能提高我的开发效率...
另外开会的时候东西太多不能对每一个点都一一质问，后续再沟通的次数和麻烦程度就是从这开始的，个人认为这应该分两方面，一是产品设计出来的详细程度，二是开发在开会过程对产品的理解程度，前者我不可控，且后者受到前者的影响，唯一可控的只有我自己的经验

[waising]

产品直接安排程序员任务吗,中间没有技术经理或者部门经理来统一规划设计吗

[ray1504]

说的好像就是我们公司，哈哈哈哈
其实，大部分中小规模的公司都差不多吧，哪有那么多规范，都是遵循着前人的脚步走下去，实在走不下去了，就换条路走。说不定，还没等你换路走，公司就先倒下了。

[brader]

很简单啊，做出来的东西和原型一样就好了，你的接口就看着界面设计就好，不要想过多的东西。
最重要的是多摸鱼，提前做完了不要老实巴交交上去就对了

[haah]

国内嘛！习惯了就好了。

[wolfie]

跟开发规范什么关系。
原型没看懂就跟产品聊啊。

[nuanshen]

看的我都怀疑你是我同事了哈哈哈！总之就是需求、原型这一块有问题直接找到对应的产品沟通，确定好了再往下做

[ClericPy]

同经历过开发规范做的不好的公司, 提供几个建议吧

1. 测试一定要写好, 回归测试很重要, 集成测试尽量完整, 酌情实现核心部分的单元测试. 否则一定会加班

2. PRD 有任何歧义的地方一定要较真, 不管对方烦不烦, 否则背锅的时候会很麻烦. 比较有效率的情况就是对方先出 PRD 过了需求评审, 然后给你看的时候通过在线文档的选中批注 /评论功能把不理解或者模棱两可的地方指出来, 然后当面确认

3. 代码方面一定要抽象的干净利索, 能不耦合就不耦合, 否则需求变动的时候非常痛苦, 这是靠基本功的, 吃几次亏就记住了. 数据类型的 schema 一定要严格+统一, 否则你和别人联调的时候会特别浪费时间, 必要情况参考一下领域驱动设计

[FieldFarmer]

@waising #3 有研发经理，但基本不怎么管，直接叫我跟产品对接

[FieldFarmer]

@ray1504 #4 很有道理，从另一个角度解释了部分国内公司的状态。

[FieldFarmer]

@brader #5 可以，吾辈楷模！

[FieldFarmer]

@wolfie #7
@nuanshen #8 确实，感觉花一天跟产品聊，比自己一个人瞎琢磨一个星期要好得多。

[FieldFarmer]

@ClericPy #9 非常有帮助！感谢

[ClorisYe]

我这两年就是这么下来的，我现在躺平了，不较真了，不转牛角尖了，较真对己对人都没好处。关键是，推动进度就行了，模棱两可的需求需要找产品确认，但是不能保证最终就是这样，所以按照自己差不多的理解去做了，然后联调过程中也能发现一些问题将其改正。还有一部分问题，在测试的过程中也能反馈，就是一个不断校错的过程。

[Vkery]

很多需求产品也不确定，因为用户也不知道自己要什么 ，用户只知道自己不要什么。
所以经常出现，产品先自己脑补需求，先做出来，再让用户提意见去改。

[jjwjiang]

和产品的沟通上面都说了我就不赘述了

说说和前端沟通，显然你俩应该最早就定下来前后端交互的数据结构才对，这样不影响双方进度，也好随时沟通变更。

约定好结构之后双方定好一个人来把数据以 mock 的方式全部写好一份，在前端也好后端也好，都不费劲，然后在开发的过程中双方都能第一时间发现不合理的地方，在沟通这个结构的过程里，互相也能加深对业务的了解。

[wu67]

业务流程有疑问, 当场就要跟产品沟通....
至于你跟前端之间, 应该用接口出入参数描述, 最直观的就是, 你要知道哪个页面会调你哪个接口, 所以那个接口你需要取得什么参数, 需要返回什么数据. 在确定业务流程的时候, 前后端就该开始规划这个了...

[cndydb]

在一家做政府项目的公司，半年了没见过一个文档和手册，躺平了

[FieldFarmer]

@jjwjiang #17
@wu67 #18
其实开发之前我都问过，都说没有规范，前端直到联调的时候，才花了一点时间去找了以前的例子发给我让我仿造以前的数据格式返回数据给它，我也是醉了

[merpyzf]

前端和后端一起根据业务定好接口的规格，之后大家都根据 Mock 的接口进行开发。

[bitmin]

大部分工作都不适合埋头苦干等到结果出来再汇报。有问题及时发现及时修改比最后发现再改要省时间。

前后端配合的情况下，建议一开始就找前端商量好请求和返回的参数。

我以前写客户端的时候，自己理解完业务流程就写个 API 文档给后端参考，后端有什么意见再讨论修改。这样子干起来大家都舒服。

[unco020511]

你说的产品原型不清晰这个需要在评审时开发主动提出来,要求更清晰细节的产品原型,其次,接口本来就是双方开发完再联调呀,一开始前后端确定好接口文档(每个接口的请求 /返回数据),然后就按照接口文档各自开发去了.

[FieldFarmer]

@unco020511 #23 评审阶段我不在场...可以说不知道有没有评审，刚入职两周观望观望，确实听取了大家的意见后，我发现重点还是去怼产品给出更详细的原型图

[caiji11]

可以问问同事之前怎么处理的 这个后期很耗费精力

[RainCats]

前后端分离的现在难道不都是先出空接口约定好出入参吗~

[janus77]

1. 不要乱动屎山
2. 熟悉业务了尽量跟产品撕，不想做的不要勉强自己
3. 遇到提 bug 先甩锅，说不定甩着甩着就不用你解决了