详细设计说明书应该如何发挥作用最近的项目，我才写完自己的详细设计说明书(以下简称LLD)，心里有很多疑问，
详细设计说明书应该如何发挥作用
最近的项目，我才写完自己的详细设计说明书(以下简称LLD)，心里有很多疑问，在此和大家讨论一下。
1. LLD是不是一个架构的概念？
2. LLD应该由谁来写？
3. LLD应该如何对后期的开发工作起到指导作用？
4. LLD写好后，在开发时期还可以更改吗？
以我的认识，如果LLD不能对后期的开发起到一个比较好的指导作用，那么写LLD就是浪费时间；但是要写出一个高质量、能真正指导开发的文档，也不是很容易，要想好整个程序的框架，还要一开始就想好后面的每个细节、结构的分布。就比如我们要写一个处理某个功能模块的类，如果不做个demo出来，我就不能确定这个类的结构，更别说每个接口、函数参数的确定什么了。
所以现在我所接触到的LLD，就好似一个鸡肋，写之浪费时间、还起不到作用，弃之又违背了正常的流程和规范，所以想和大家讨论一下，希望大家都可以说说自己在做项目过程中，关于LLD的情况。
谢谢大家。
[解决办法]
LLD是解决协议、结构、调度层面的文档，必不可少。一般来说，LLD出来，程序也就算出来了，只不过还是之上的程序而已。
开发期是禁止随意改动的，因为那时的改动就意味着系统重构！
LLD通常由系统构架师或系统分析员编写
一般由系统构架师出详细设计，系统分析员做测试方案。高程细化算法，程序员实现代码，运维人员作测试
[解决办法]
现在的项目中通常都没有时间来靠拢这个流程，有几个项目能真正按照流程的思想运作？
时间、进度。。都是倒排时间表，催命似的
能事后补一下流程文档就不错了
再说海量文档，真正有用的有几个？？
[解决办法]
很多时候，都是没写什么文档，直接编码的。
[解决办法]
[解决办法]
唉！没有文档就开发，这就是现在软件bug多如牛毛，质量上不去的原因啊
[解决办法]
文档这玩意的确很鸡肋。后期一般都不会有人去看，修改程序后通常也不会有人去改相应的设计文档。
[解决办法]
[解决办法]是很无语，因为你的观念属于伪论题，从项目开发上讲，没有文档是不能进行开发的，因为这不是你一个人过家家做练习，随时随刻都会有人员参与到项目或离开项目，面对没有文档的项目，怎么进行调度？难怪国内的一些啥都不懂程序员也能到处充专家当大爷！
一个项目程序员是很不重要的角色，可以说可有可无，只要有文档，会个编程的人都能完成项目。国内一些小公司自己本身不规范，从上到下没有作大型项目的经验意识，以为代码出来了就算大功告成了，这样的垃圾想法怎么可能开发出好的安全的软件？
补文档？那是在糊弄人！难怪甲方稍稍提点变更或改进，项目就一拖再拖了……
[解决办法][解决办法][解决办法]程序员还就是不重要，如果你叫个学生让他完全按文档要求编程，那基本上是没有什么bug的，我不是没有临时招学生帮我完成项目过，从某种程度上说程序员还不如学生呢，至少学生不懂时会问，不会乱作主张，编一些自以为是的垃圾在那里。只是学生相对手比较新，缺乏一些调试经验，对工具不怎么熟，上手比较慢而已。
另外，架构不是你程序员自己说架构就架构的，程序员干10年未必能当架构，写详细设计还早呢。
当然，有的人，没做过程序员一样能成为好的架构师，只是一些“程序员”看不懂罢了，那不是架构的问题，而是看不懂得程序员自己太烂了。
也许我的话触动某些人的神经，在这里我说声对不起！我道歉！我只是对目前这种混乱的编程市场很无语，因此有时不知不觉中就言语尖刻起来，我真的不是要有意贬低某类人，我自己曾经也是其中一分子，但我觉得大家应该把视角拉高一点，从一个更宏大的角度看问题，而不是仅仅局限于眼前的项目、客户。糊弄客户就是糊弄自己，这样就永远不会提高，这也是思想懒惰的表现。
[解决办法][解决办法]从自己的开发实际来看，让文档来指导开发，纯属扯淡
生活是很实际的，项目也一样
我们也想正规起来，也想体面一些，可是我们首先要活下来
除非你能准确把握2年之后的市场需求，然后沐浴更衣，精益求精的做好你的产品
否则，那也是一件闭门造车的意淫产品
[解决办法]公司雇佣员工绝对不是出于培养的目的
公司让你干啥就得干啥
饿的时候，你一样会喜欢珍珠翡翠白玉汤
------解决方案--------------------
你可以做一个简易的详细文档，首先确定好架构和数据协议、调度框架、冲突陷阱、数据要求标准，这些可以通过细化需求分析得出，一般10000行非算法类语句的，需求分析一天讨论确认，一两天出详细文档很正常，一旦出详细文档一定要客户确认，因为这意味着软件的定型，后面就是工作量的问题了，一个人忙不过来可以到学校找几个学生帮帮忙，给点工资就行了。一两周交货，有问题再作二期版本，先把钱拿到手，让对方先用起来，这对于那些对要做的事心中没有多少底的客户很管用，因为你可以免费的送几期版本改进，客户再提新需求是会比较谨慎的，一旦用完免费升级，就要再花钱！这样改进的版本会比原先的精良很多，客户由于软件早早上线使用，对上面也好交差，而且也提升公司整体实力形象。而公司也可以随时随地从项目撤出来做其它事，大家皆大欢喜，客户有事还会愿意找你，因为你们快。
[解决办法][解决办法][解决办法]找几个学生帮忙，就能搞定的代码，不知道质量如何。
反正现在的同事，有不少名校毕业（本科，硕士），干了几年的。码完一个项目后，会觉得，架构不错，但代码写得真垃圾，测试又把程序给测死了。
[解决办法]有详细文档我感觉还是好
写代码的时候就是由于没有详细文档，所以我是一边写一边添加一边改，很不爽的。
如果有专人写好详细文档了，就是一个很好的事。
[解决办法]让我感觉就是到哪一个层次说哪个话！
项目催的紧必然要先coding 因为没有人在意你的LLD，只在意你的东西！
到那个层面上了就该注意那些问题了！如果没有丰富的经验还是算了吧！不能为了流程而流程！
个人感觉东西好不好只有自己才知道！不喜欢因为别人说好做！
[解决办法][解决办法][解决办法][解决办法][解决办法][解决办法][解决办法][解决办法]铁打的营盘，流水的兵。
做任何事情有记录是最好的
------解决方案--------------------
听说过游泳教练自己不会游泳
没听说过详细设计人员自己不会编码
英文对话时，好的翻译会直接以英文思维，而不是用中文思考再自己翻译为英文
不需要有主观能动性的员工，好吧，只要会打字就行，因为我们有详细设计文档
如果详细设计文档能在这个层面指导开发，详细设计人员必然先在大脑中想好代码，然后用伪码表述出来
不确定的时候，甚至还需要亲自写代码先验证一下
好了，没问题了，拿去编码吧。。
[解决办法]在这里的有几个算大项目？ERP那种吗？还是数据库规划？前者不是，后则就是了：因为ERP有例可循，属于模板修正，有些周期长是策略性的而不是实际的工作量，就像我经手的一些项目，一周的工作量通常会一两个月交给客户，否则客户会觉得你不重视，随时都可能改需求，而且项目经费谈不上去；数据库规划设计或改进则有可能属于试验性的项目，这从技术上讲，不是工作量的问题，而是思考角度、算法研究是否到位的问题，在技术上算是大而难的。因此不是人数参与多就是大项目，而是核心设计的人多寡决定了项目的难度和大小。
如果技术总监、总架构师不管事(这很常见)，文档写的很堂皇却没什么实质性的内容，那么说明公司文化有问题，混日子的人很多，公司架构的脱节松散的，这样的企业文化风险会比较大。
[解决办法][解决办法]一个大项目，能独立写好LLD的人价值至少百万年薪
对一般公司来说，这个根本没啥用，基本写完后要改N遍，一旦修改还要协调各个部门，烦都烦死了
[解决办法][解决办法]好像 qq120848369 对算法有研究
http://blog.csdn.net/qq120848369
[解决办法][解决办法]哈，实际操作很快，尤其是高层，但分发是会很慢，尤其是给客户，不然动不动数百上千万的项目，人家凭什么给钱呢，开会讨论也是如此10分钟事，有时会扯一天，会务纪要上去了，客户也介入，你要会绕，客户就觉得你技术牛，你要学会向客户要细节，尤其是他们不在意地，你要揭示计算机怎么跟人不一样，有些东西只有人搞清楚了，才能让计算机自动执行。反正要让客户觉得技术上有难度，要解决的问题多如山，客户花钱花得值……
[解决办法]大公司官僚，什么是官僚，就是这么来的。我没去中联时，以为多么了不得，两次会一开，就找个借口让助理去了，反正到时东西拿出来，也没人能提出意见，基本上都是照着分发下去，有客户参与时，工作做细点，没客户参与，就按标准流程走，公司里做架构是很逍遥的。代码写得少，不过有关协议算法精化的事，这东西做得多，但没法考核。干干没劲，朋友开公司就合伙出来了。
