想听听大家对写开发文档或者设计文档的看法

[cong]

没经历过大公司，平时写复杂逻辑会画一些简单的图。想听听大家对写开发文档或者设计文档的看法。

[xuanbg]

我司要什么文档我说了算，所以。。。。。。

流程图(BPMN 多泳道流程)、业务分析图(脑图)、建表 SQL 脚本、接口文档(README.MD)、资源配置表(脑图)就是全部。

其实最重要的文档就是代码本身呀

[ebingtel]

能保证别人知道你要干嘛就行 格式不必拘泥 关键路径落到纸上会好些……然后才去看你的代码

[sumarker]

没写过设计文档
开发文档一般就是找个地方画一画看看

[securityCoding]

1.模块图
2.关键流程时序图
3.接口文档,导出 swagger json 文件,导入到 yapi 平台
4.排期

[iConnect]

文档还没写完，由于需求变更，代码已经重写啦

[FrankHB]

最有效的是 coding convention 之类具有强制约束力的文件。
其它的，就写给自己会用的才用心。

[hoyixi]

其实，设计文档没出来，根本不该开发，你开发啥？照着什么开发？尤其规模大的项目，没有好的需求文档和设计文档，就是一坨翔

当然领导不会这么想，反正让下面人加班就行了，996 搞起来

[nianyu]

国内别想了，都是走形式

[Takamine]

ER 图，时序图，接口文档，设计方案业务分析。

[Leigg]

如果想走的更远，必须约会画图，除非你牛鼻到需要时脑中自然成图。团队开发时，图和文档尤其重要

[cong]

不知道大公司是怎么做的，有大公司经历能不能说一下啊

[Aresxue]

作为开发人员，平时主要涉及的设计文档基本上是功能的详细设计和概要设计，对于它们的态度我认为是必须要有，工期紧也要先有概设，后期再补详设。但是在实际过程中不写文档的人比比皆是，但这是有问题的。正规的开发流程是先写概设然后找业务人员确认，然后写详设，叫上开发组长评审，最终把详设中的设计付诸代码，你管不了别人但你可以约束自己。

[DoctorCat]

代码不要屎一样，结合基本的业务设计文档和注释，还是可以应对的。
代码屎一样，结合基本的业务设计文档和注释，还是很难应对的。
至于设计文档与代码实现之间的关系，很容易因为开发同学或者 PM 同学的尽责程度变成一种玄学过程。

文档说明白、更新的及时，怎么个形式都好说。关键在于文档的维护。见过太多文档对不上业务实现的案例了。