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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 943 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

字段

原型

开发

规范

27 条回复 • 2022-05-06 22:32:31 +08:00

DuDuDu0o0

2022-05-06 10:59:35 +08:00

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

FieldFarmer

2022-05-06 11:09:27 +08:00

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

waising

2022-05-06 11:31:35 +08:00

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

ray1504

2022-05-06 11:36:37 +08:00

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

brader

2022-05-06 11:36:39 +08:00

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

haah

2022-05-06 11:41:03 +08:00

国内嘛！习惯了就好了。

wolfie

2022-05-06 11:53:15 +08:00

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

nuanshen

2022-05-06 12:07:59 +08:00

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

ClericPy

2022-05-06 12:22:29 +08:00

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

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

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

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

FieldFarmer

2022-05-06 14:17:35 +08:00

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

FieldFarmer

2022-05-06 14:22:01 +08:00

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

FieldFarmer

2022-05-06 14:22:22 +08:00

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

FieldFarmer

2022-05-06 14:23:12 +08:00

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

FieldFarmer

2022-05-06 14:24:06 +08:00

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

ClorisYe

2022-05-06 14:52:59 +08:00

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

Vkery

2022-05-06 14:57:36 +08:00

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

jjwjiang

2022-05-06 15:00:02 +08:00

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

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

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