很困惑，UML的东西应该谁来写？普通开发人员吗？

比较困惑，这行也干了5、6年了。现在这家公司内文档要求很严格，有点过分的意思。是个内部用的支撑系统，框架有了，也开发了一些功能，目前的开发都是往上添新功能。
现在问题来了，领导要求不论大小开发，哪怕是一个页面都得写需求设计、详细设计，得在里面画出序列图、用例图、流程图。我很困惑，干这么久没见过这么搞的。一直觉得这种文档是用来描述架构的东西，没想过在详细开发中还写。
大家觉得这样合适么？

PS：这个系统架构好像没有文档

17 个解决方案

#1

如果体系好，画也没关系
我也碰到过，设计之类使用文档及其详细
而后通过工具将文档直接生成程序，写得越详细生成的越好
实在无法生成的，再手动添加

PS：这个系统架构好像没有文档 
说明准备用流程图代替系统架构

如果按LZ所说写完文档后还需要程序员手动写全部程序，似乎是有点过了

但每个公司有每个公司的习惯，如果想留下就要适应，不想适应就要选择离开

#2

楼上说的对，确实写完文档还得写全部程序。
我以为UML这类东西应该有架构师来做，编码人员写好像不太合适，看不到整体。

#3

显见公司是把工作合并来做，还能对外宣称项目正规

不过也要说明，文档非常重要，写文档的过程也是明确功能模块思想的过程
如果永远只是编码，无法进步
我做项目也要写，不知道LZ写得量有多大
但我做项目时间的大致比率 - 
概要设计：详细设计：开发：集成测试=15%:15%:30%:20%:20%

事情都是两面说的，一方面确实感觉工作繁琐，另一方面对编码人员也是个锻炼
如果不愿意做只能走人

#4

老兄说的有道理，所以才感觉到困惑呢，呵呵

#5

你写个错的有没人检查,没人检查,随便拷个图就是了

#6

如果作成的文档都没人review，那就是公司本身纯属胡弄

#7

:$ 貌似是这样的，写了没人看。
呵呵

#8

开发人员应该要写文档，就说详细设计，这东西总不该SE和架构师来写吧，你想想看一大篇文字和一幅时序图谁的表达力更强。

当然，象楼上同学说一样，前提是得有评审，不然就是在糊弄。我们项目一般是将概设省略，详设融入STORY中。看STORY是否合格，主要是以是否能将你写的设计拿给同组其他人指导他编码为衡量目标。

至于上边说编码人员看不到整体就不应该画UML，我坚决反对，谁说UML就一定得表达整体呀，比如你的模块用适配器模式解决了外部系统版本兼容性问题，难道你不应该画个类图出来说明一下吗？

#9

写写也好啊。。我想写还没机会呢

#10

应付上面的东西

#11

不写文档的坏处之一：老板损你，你没有证据。这东西要专门腾出时间来做。

#12

难道你就一直不想有所提升吗？
多好的机会啊，你就一直想做代码？
多会点东西不是什么坏事

#13

这个很好得学习

#14

你学习了涨自己的本事

#15

构架师写UML，程序员写代码，这个应该是通例了，如果等代码都写完了才想起来补UML，这个东西也只能是验收时候当材料用了，实际上没啥用啊，我估计楼主公司应该没构架师这个岗位，单子下来开个会就各干各的了，呵呵

#16

引用 2 楼 kfeng_bird 的回复:

楼上说的对，确实写完文档还得写全部程序。
我以为UML这类东西应该有架构师来做，编码人员写好像不太合适，看不到整体。

那你就兼任一下构架师，这也是给你一个学习的机会。

#17

提升自己的机会