你们开发项目有没有都先写一下开发文档,程序猿(媛)们都来说说吧

快乐起航2020 2014-08-02 10:08:56
各位大神,大师及各位小伙伴们,请问你们开发项目有没有都先写一下开发文档,程序猿(媛)们都来说说吧

我们公司不算是软件公司,只开发自己的项目,是程序开发完了,在写开发文档,请问一下这个正常么
...全文
874 40 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
40 条回复
切换为时间正序
请发表友善的回复…
发表回复
快乐起航2020 2014-08-08
  • 打赏
  • 举报
回复
引用 39 楼 gdf87521 的回复:
大多数国产,都只能1.0,要想升级,得重新来。。。
成都-狗蛋儿 2014-08-08
  • 打赏
  • 举报
回复
大多数国产,都只能1.0,要想升级,得重新来。。。
effun 2014-08-05
  • 打赏
  • 举报
回复
引用 37 楼 hemowolf 的回复:
[quote=引用 33 楼 effun 的回复:] 楼主既然你问了这个问题,说明还是有心人。文档这种东西本来就没有哪条法律规定一定要的,但有一定比没有好。 1、需求文档可以减少和客户扯蛋。 2、概要设计文档可以减少项目经理和程序员扯蛋。 3、详细设计和代码注释可以减少程序员之间相互扯蛋。 4、说明书可以减少后续培训的口水。 当然,到底文档起不起得了作用,还有看写文档的质量,还有看文档人的水平,文档的多少取决于项目的大小,但不管多大的项目,开发前的设计文档是必要的,否则时间一长,就叫天天不应了。
有的时候,老板今天说个需求,明天就要看结果,这个文档怎么给?[/quote] 加班 or 走人
小灰狼 2014-08-05
  • 打赏
  • 举报
回复
引用 33 楼 effun 的回复:
楼主既然你问了这个问题,说明还是有心人。文档这种东西本来就没有哪条法律规定一定要的,但有一定比没有好。 1、需求文档可以减少和客户扯蛋。 2、概要设计文档可以减少项目经理和程序员扯蛋。 3、详细设计和代码注释可以减少程序员之间相互扯蛋。 4、说明书可以减少后续培训的口水。 当然,到底文档起不起得了作用,还有看写文档的质量,还有看文档人的水平,文档的多少取决于项目的大小,但不管多大的项目,开发前的设计文档是必要的,否则时间一长,就叫天天不应了。
有的时候,老板今天说个需求,明天就要看结果,这个文档怎么给?
於黾 2014-08-04
  • 打赏
  • 举报
回复
还有7.用户竣工验收,补写所有文档
於黾 2014-08-04
  • 打赏
  • 举报
回复
引用 25 楼 chen870201 的回复:
实际的过程: 1)Excel+其他系统截图=原型; 2)编码; 3)单元测试; 4)交付(试用)。
实际的过程: 1.用户提出需求 2.内部探讨,写概要设计文档 3.用户确认,并回到1,如此反复多次 4.编码+测试 5.试用 6.用户需求变更,回到4,如此反复,直到用户满意
chen870201 2014-08-04
  • 打赏
  • 举报
回复
理想中的过程: 1)项目经理或指派人员到客户现场了解需求,谈限制、条件、方案; 2)项目经理带领设计人员做原型、概要设计、数据库; 3)客户确认原型(少部分看概要); 4)详细设计; 5)代码实现; 6)编码Review,单元测试,集成测试; 7)用户测试; 8)交付。 实际的过程: 1)Excel+其他系统截图=原型; 2)编码; 3)单元测试; 4)交付(试用)。
  • 打赏
  • 举报
回复
大团队和小团队的区分啊,团队大了,没文档工作没法开展,小团队,有文档没文档都一样,都能开展工作
於黾 2014-08-04
  • 打赏
  • 举报
回复
引用 22 楼 alex_my 的回复:
总是会缺这缺那的,加班都搞不完项目,哪有人写文档。
所以大团队和小作坊的区别就体现在这里了 大团队要协作,没有文档如何分工? 而像你我这样,每个人负责个小项目,改来改去的,有文档也没人看...
alex_my 2014-08-04
  • 打赏
  • 举报
回复
总是会缺这缺那的,加班都搞不完项目,哪有人写文档。
iniins 2014-08-04
  • 打赏
  • 举报
回复
计划经济时代可能比较普遍,市场经济时代……呵呵
whhmkj 2014-08-04
  • 打赏
  • 举报
回复
项目设计稿,项目功能静态页面,具体的功能需求分析文档,项目编码,项目测试,项目上线
莫_问 2014-08-04
  • 打赏
  • 举报
回复
引用 13 楼 sp1234 的回复:
其实写文档之前,项目经理应该先拿出“工具平台”设计草案来。而最终的产品肯定需要根据用户需求改变成百上千个部分,也能灵活应对。 比如说给你40万,让你用3个月做一个相当巨大的“一堆工作流”的业务处理信息系统。如果你先把所有的“增删改查”模式先找UI设计师定个初稿,然后决定做5、6个通用控件(UI 个性扩展完全可以用技术手段达到),而成千上万的界面其实都是因为配置数据的变化而自动变化的,那么3、4个人完全可以完成一个大系统,而且得到用户的充分肯定。 而如果让那些小作坊里的“简单功能分解”式的做法去做,找10个人(工资同样)做16个月可能最终也被用户骂得狗血喷头、拒绝验收。 我的亲身经历都是如此。但是小公司遇到后者的情况自然有独特的“猫狗之道”,具体是什么做法就不多谈了。 我的意思是,软件开发并不是一直都在“代码工人”在流水线上拼凑 csdn 上可抄袭到的一些程序。如果你们把70%的精力放在自己的平台、组件的设计开发上,那么一定时间之后,你收获的就是几套良好的“生成器系统”,你就获得了自由。 程序员也因为大多数时间是在开发这样的生成器系统,那么你写的“文档”的层次也是这个生成器设计层次的。这时侯你再来讨论什么“有没有先写文档”就更有意义了。 但是这要求,项目经理不是一个码农,甚至不是眼中只有单一的一个产品,而应该是一个长期发展的平台的设计思路。
你的回复太中肯了。。支持一个。
於黾 2014-08-04
  • 打赏
  • 举报
回复
引用 17 楼 walkeeper 的回复:
个人感觉是因为客户自己对需求的不确定性搞的文档会很难写,小公司的经理一般为了偷懒省事都不写的,客户要改啥就改啥,改的乱七八糟一堆BUG再加班折腾,总算折腾完了才去写文档……
没错,很多时候客户根本不知道自己需求的到底是什么,只不过是参观了别的地方,发现挺好,然后就想要个差不多的. 但是其实他自己的业务跟人家的根本不一样,即使做出来了,还是要各种改. 而客户一开始根本连自己的业务都不熟,都是摸索着在干,那软件也只能跟着他们摸索,干完之前都没法出一个完整的文档.
walkeeper 2014-08-04
  • 打赏
  • 举报
回复
个人感觉是因为客户自己对需求的不确定性搞的文档会很难写,小公司的经理一般为了偷懒省事都不写的,客户要改啥就改啥,改的乱七八糟一堆BUG再加班折腾,总算折腾完了才去写文档……
於黾 2014-08-04
  • 打赏
  • 举报
回复
一般只有需求明确,才能先出文档,后实施. 像我们做的一些配套项目和一些用户定制的功能,用户自己对自己想要个什么都说不清楚, 都是做出来看,然后不满意改,哪里能写出什么文档来. 很多时候连做完了都整理不出文档,太乱...
快乐起航2020 2014-08-04
  • 打赏
  • 举报
回复
引用 8 楼 devmiao 的回复:
你说的文档是用户文档么?因为似乎没有开发文档就搞开发实在难以想象。
是指整个项目的需求文档和使用书册 啊
罪人不釋之枷 2014-08-04
  • 打赏
  • 举报
回复
我們公司我是負責設計內部消化的程序,基本就是其他部門提需求,設計出格式,要求的功能什麽的,然後就是自由發揮了。 ……
快乐起航2020 2014-08-04
  • 打赏
  • 举报
回复
引用 34 楼 zbdzjx 的回复:
写文档???!! 文档还没写完,很有可能老板的需求就变了!!! 当然,我们写的程序是公司内部使用的,而且老板的思想多变,今天说的东西,很有可能明天就变了。
我们老板也有点多变啊
zbdzjx 2014-08-04
  • 打赏
  • 举报
回复
写文档???!! 文档还没写完,很有可能老板的需求就变了!!! 当然,我们写的程序是公司内部使用的,而且老板的思想多变,今天说的东西,很有可能明天就变了。
加载更多回复(20)

111,098

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • AIGC Browser
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧