怎样做分析才能使“代码工人”顺利编码实现呢?

按软件工程的原则来说，分析要细化的每个函数，这样也许你所谓的“代码工人”
就可以顺利的编码实现了：

附： 我本人的意见是，尊重每一个程序员，不喜欢看到如“代码工人”这样的词语，至少在我们国家现在的情况下，不适合。

xtrrsg (算了)
首先你要进行详细设计 而且必须要有对所使用行业的深刻了解 还要勇于承担责任 这是一个基础
首先我不知道你是不是可以承担项目的开发的完全责任 如果你不能 那么你就不要做详细设计了

to o6z：

我正在想你呢，就看到你了，呵呵。想就这个“代码工人”的问题跟你聊聊。

在现有的OO方法及OO语言下，我根本不相信什么“代码工人”。举个最简单的例子：我是设计师，设计了一个stack类；你是代码工人，你来给我写这个类的pop方法。我告诉你：我把所有的元素都放在_elements这个数组里面了，你把最后一个元素弹出来就行。结果你这样做了。但是你忘了一件事：在执行之前检查_elements数组是否为空。结果，如果有人对一个空的stack执行pop，就会得到undefined的结果。

为什么出现这种情况？因为软件的问题主要是出在模块之间的结合部，也就是模块之间的“契约（contract）”上。如果我只是告诉你“写一个pop方法”，又凭什么要求你一定会检查“栈是否为空”的情况？所以，Design by Contract应该是OO方法成为可能、使分工协作成为可能的基础。除非你把对象之间的契约写在代码里，靠编译器来保证它们得到实施，否则对象之间的关系就是不可靠的，开发者之间的协作就是不可行的。

to zhf_karen(zhf)：

你的想法很好，但是存在一个比较严重的问题：如何判断是谁的错误？就以我上面的例子：当一个client对空的stack调用了pop时，这是client的错还是我们这边coder的错？如果你不能在契约中把对象之间的责任和义务规定清楚，那么程序设计最终将演变为政治——出钱的人有话语权，位高的人有话语权，所有的责任都被推给coder。这恰好就是我们这个产业的现状，难怪程序员都这么难过。

wengdy2000(浪子)同志代表了一种很不好的倾向：否认软件工程的科学性，否认分工协作的可能性。

请看清楚：分工协作是必须的，“个人英雄”式的软件开发是不可行的。既然要分工协作，就必定有些人专攻编码，有些人专攻设计。既然如此，难道叫不叫“代码工人”，事实就有所不同了吗？

代码工人，不管这个名字好还是不好，它是客观存在的。我们应该考虑的，是如何保证这种分工协作可行并且合理。

SHIZUMARU(绯雨闲丸)先生:
你说得也有道理,分工合作,对吧!他说得也没错"代码工人"称呼而已
也有人叫"程序员",称呼各人有各人的爱好.
好了,我对我刚才的过急之言, 对 xtrrsg (算了) 表示歉意
(不过,你这样说有一种倾向:是不是想得点分呢?)

我想这里有一个很关键的问题所在：
你说：“我本人水平比较菜，不过也做了几年的分析了，回头想想，总觉的乱七八糟，
没有什么项目的分析让我满意。
怎样做分析才能使“代码工人”顺利编码实现呢？
”
这岂不是跨过了开发中最关键的一步：设计!
就算是在日本人和给国外做软件外包开发的那些开发公司里，所承接的也是设计全部做完以后的设计文档，然后来完成编码部分的。
注意：并不是分析结束以后就如何如何!

印度的做法也是把设计文档交给真正的蓝领代码工人来进行编码的，做设计的就不一样，在印度，仍然是水平比较高的人或者教育程度比较高的人来承担的。这些人在国外仍然称之为：Software Engineer，而不是Coder。

分析只是做了用户需求的解析，说实在话，这根本不是软件开发中最关键的步骤，应该说这是一个入门步骤，在软件开发过程中需求的获取就是第一步!应该说这一不应该是由行业专家和设计人员协同完成的，或者有一些可以充当行业专家的软件工程师和用户一同完成的。

只有承担设计来进行编码的人才会被称为Coder。

to o6z：

我不写这样的伪码，因为这是抢了“代码工人”的饭碗。如果我做设计，我大概会给你一个这样的contract：

class STACK[G] --“[G]”表示这是一个泛型容器
...
feature
pop : G -- pop方法的返回类型是G，即泛型容器的类型参数
require
count > 0
ensure
count = (count-1)
end

在这个contract中，我保证调用pop方法时栈内元素计数（count）大于0，并要求你除了弹出一个元素之外还要保证元素计数要比弹出之前少1。至于你如何实现弹出的动作，甚至如何实现元素计数（在Eiffel中，count可能是一个方法也可能是一个field），我都不关心。

你觉得这个方案如何？

To SHIZUMARU(绯雨闲丸) :

1. 你的描述还是不够“代码工人”来实现。因为他还是不知道
对象是以什么顺序进出容器的，当容器满了时怎么办？

2. "我保证调用pop方法时栈内元素计数（count）大于0”也就
意味着你在设计使用这个栈的所有地方都要有这样的明确的逻辑检查。
否则“代码工人”怎么知道？但是这样就有矛盾了，因为你不知道
“代码工人”何时要用你的这个栈来实现另一个功能，因为在你的方法
里，选择具体的实现方法是“代码工人”的工作。这样讲可能不是很好
理解，还是举你的例子吧，例子中好像可以不必指定“代码工人”用一个
怎样的计数器类来实现栈的元素计数，但是你怎么保证“代码工人”
所选择的计数器类的contract是符合要求的呢，（比如，栈的容器的
最大计数值是一个maxlong，而他选却选择了一个只能计maxint的计数器）
所以你必须雇用一个能根据上下contract，来寻找满足条件的计数器类
的“代码工人”。而这样的选择难道不是一种设计嘛？

3. 如果你同意我上面的讲法的话，我们再讨论一下我们看中
“代码工人”的是选择以及实现方案的能力呢？还是在编码的能力呢？
其实在现在这个编译工具随手可得的年代纯粹的编码早就不存在了。
无论什么形式的伪代码，只要是严密的都可以自动转换成代码，如果
不是看中“代码工人”的判断能力，我们何需“代码工人”呢？

4. 我想你的设计一定是基于可复用原则的吧，这个栈不要说对某个
“代码工人”来说，是他的第一次，而且应该是对你手下的所有
“代码工人”来说都是第一次吧，对于这样的一个永远面对第一次的，
时时在做选择的“代码工人”我们至少应该尊称他一下为“高级技工”
吧。（其实设计师不也就是一个高级技工嘛）

本来“工人”或“蓝领”并不是一个什么下贱的名词，可是有一些人
非要将这个标签贴在干着和他们没有太大本质区别（最多是考虑范围这个
量上有区别）的其他人身上，以示自己的特殊，就很容易引起反感。

首先恕在下答非所问，先不说你是否混上系统分析员，不知你是直接跳到分析员，还是也从“代码工人”过来的。以后建议你不要用这个词语，你这是自己贬低自己...............

嘿嘿，
我就正在给鬼子作详细设计，
很细很细的说，
所有接口和内部变量都要写出来，
能剩下的工作也就是用等号什么的把变量连起来了，
真怀疑他们需不需要coder，
直接找个打字员ok了。

什么工人不工人的？
我感觉老是提代码工人的都是些需要进行洗脑的家伙，他们的思维仍然停留在工业时代，尽管他们使用着或开发着信息时代的产品。
还有一种情况，资本家是最讨厌“知本家”的说法的。

用教科书式的伪代码来写详细设计，这样做有两个缺点：
1.增加了工作量，如此详细的设计，还不如直接编码，而且增加了以后同步文档和实现的开销。
2.如果不考虑实现，这样作出的详细设计不一定是完全可行的，在实现过程中很可能需要对其进行修改，越详细的设计，被修改的可能性就越大。
其实无论叫代码工人也好，叫程序员也好，他们不是没有脑子的工蚁，他们也是能做设计的，只不过由于经验和知识的限制，他们可能暂时只能做模块内部的比较细节的设计，因此原来的详细设计是可以由程序员来负责的（但是不一定要形成那种详细设计的文档，设计可以只保留在程序员的脑子里，后面讨论这么作的可行性）。
由程序员来做详细设计的先决条件是：设计人员要描述清楚系统如何由各个模块组成、每个模块的契约：包括模块的逻辑功能（通过文字描述）、模块的入口条件（如pop时，stack不能为空）和出口条件，程序员根据契约来进行模块的设计和编码，在这里要相信程序员的能力，他们会自己决定如何实现契约的。
由于程序员可以根据契约之间进行设计和编码，因此比契约更详细的设计文档就没有必要了。

我现在的开发方式是这样的：
先给出数据模型（主要的表都有，但可以进一步补充）和系统框架（包括公用函数、公用类等）
然后划分模块，把模块分到人，指出哪几个模块之间应该有接口（但不规定详细的实现方式）。

然后要求每个人都根据自己的模块写设计文档，必须包括设计思路，详细界面，对别人的接口要求，别人对自己的接口要求，公用类调用要求等等
然后召集相关人员讨论一份份设计文档，逐步定稿，一般大概讨论2－3次。
最后出来的文档，凡是涉及到接口部分的都是很详细的，但是内部的基本就只有思路。
详细设计的不足用详尽的单元测试用例和代码注释来补充。

请各位指点。

非常赞成mach(照虎画猫) 的观点，在我们软件行业所有参与软件
开发的每一个成员都应该是设计者（设计工人），只不过因经验，
知识，分工的需要每个人参与不同的设计而已。我们应该学会尊重
每一个人的智慧和劳动，也只有这样才会产生出结合集体智慧的
优秀的软件产品。

To zhf_karen(zhf):
我觉得你误解了mis98ZB(Effective Typer)的意思了。他的本意
应该是能直进行编码的详细设计必需是非常详细的,如鬼子写的那样。
但是他对这样的详细设计的必要性提出了质疑。（我知道你还对这样
的做法在类似MIS系统以外的系统中的可行性也提出了质疑）

To SHIZUMARU(绯雨闲丸):

你讲的面向契约的编程方法和mach(照虎画猫)讲得确实是一样的，
但是从你的“既然要分工协作，就必定有些人专攻编码，有些人
专攻设计。既然如此，难道叫不叫“代码工人”，事实就有所不同
了吗？”讲述中，可以看出你对做详细设计的程序员的理解却和
mach(照虎画猫)讲的是完全不一样的啊!面向契约的编程方法（在80年代，
搞程序证明的人那里很流行，其实质是一种设计规范和设计方法是正交的）
当然没有错，错的是认为有了面向契约的编程方法就可以产生不懂设计，
可以专攻编码的“代码工人”的想法!

是阿，这样要求，设计人员的设计工作一定要细致，不过这个工作可以和程序员大家来一起做，作完了，一起编码，哈哈

分析设计人员要的是知识面广，而程序员要求的是深，不同，但相通。
一般的分析设计人员，必须有深厚的编程背景，呵呵

zhf_karen(zhf)：
呜呜呜呜呜呜……
我想你是被我的另一个帖子误导了（那帖子我结了，分数请笑纳），我在的项目不是mis，它是一个纯C写的结构化的程序，系统平台是在rs6000上跑的AIX，数据库服务器是oracle 7。完全没有跨平台、跨语言的顾虑，所以我觉得没有必要写那么细（真要跨语言，就更不能写那么细了……）。
我并没有瞧不起coder，因为我是个Typer，Effective Typer∶）。
其实coder，programmer，designer，architecturer不过是工作在软件开发的不同分工中罢了,一个coder写几行汇编代码，能难死一堆architecturer……

努力，up

to :clamp_chen(燕归来)

如果您的程序员要是回家开路了呢？您的项目以后怎么维护升级呢？没有细致的文档，后续问题太多了，

re:xtrrsg
该有的东西都有，只不过以不同的形式表现出来。
你提到没有细致的文档，后续问题太多，却忽视了另一点，再细致的文档如果没有维护，那也一点用都没有。

另外，我并不赞成一开始就从程序员会离开的角度来考虑问题。
小组中任何一个人的离开对项目都会产生影响，但是我只会考虑有限的影响，如果把太多的精力放在预防小概率事件上，那么项目就会变得过于沉重，很难推进。

风险成本是有限的，要用在刀口上，客户改变一次需求、数据模型的改变、系统架构的改变比跑掉三个一般的程序员都严重。
而如果在项目进行中，核心人物跑掉，总是会产生极大的影响，控制的再好、文档再齐全都没有用。

上个星期跟朋友聊天，说起这个文档的问题。我觉得文档根本就是给领导和用户看的。如果你叫程序员一边看程序一边看文档，他一定叫你去死。如果你叫程序员一边写程序一边写文档，他一定把文档扔在旁边不管了。程序员的语言就是代码。程序员之间有什么话，都应该通过代码说。如果用代码都说不清楚，难道你还希望文档能说清楚？

在self-document的方向上，很多人都做过尝试，例如javadoc。但是javadoc还是需要写注释，还不够好。Refactoring指出了一个不错的方向，基本上能编写self-document的代码。但是程序单元只有好的名字肯定还不够。程序单元应该能够self-specify，这样程序员之间的交流才能通畅。这个时候，Design by Contract的价值就很大了。

最近研究Eiffel。Eiffel Studio可以把方法的前条件后条件、类的不变式……都提取出来变成文档。程序员写好一个单元之后，规范是清楚的，责任是明晰的，文档是及时更新的，这样的生活比较美好。

要先有设计分析才能有编码

我是个低手，在公司里设计和核心代码我也碰了一点，也负责给别人凑合做点简单的设计。就我感觉而言，（不说OOD，这玩意，我刚学不懂。）撇开感情上的争论，代码工人是完全可以存在的。但上面的诸位老兄争论那么多，其实我感觉都是一个设计能做什么地步才能让“代码工人”接手的问题。这个问题和代码工人的水平无关，而只和设计到了什么地步，设计就可以从理论上翻译成代码有关。如果机器能将设计翻译成代码，人完全可以做到，而这其中，人做了机器做的事情，这就是“代码工人”的本意。

To Gadfly(海阔天空)

你没有接触过OOD，所以还有很多事情你没能领会，理解，
这情有可原。但是如果你是真正理解计算机软件的人的话，
有一点我想你应该是明白的，软件的一个根本目的是将一些机械
的工作交给机器做，而不是反过来。如果计算机会做的工作，都要
我们人来做的话，我们就不需要软件了，因为到现在为止计算机能
做的工作我们人都能做（只是效率和精度不一样）。

至于你问的设计做到什么地步足以让“代码工人”来继续之后的工作。
看来我们这里讨论了半天，你还是没有看明白，我们的结论是无论采用
什么方法做设计要能让不懂设计的“代码工人”来直接编码的话，设计
就必须详细到形式语言级。而设计能做到这一级的话，本质上已经是在
编码了。后续的工作都可以让软件来完成。我想我们总不至于为了某些
人虚幻的“代码工人”概念而制造“代码工人”吧，声称需要大量
“代码工人”的人，我看他更本就不懂软件，至少可以说更本就不懂
诞生了OO思想以后的软件。

To SHIZUMARU(绯雨闲丸):

完全同意你上面的意见。而我只是认为这时与其称为编码，还不如
称为详细设计或者叫具体实现。确实有一点抠概念了 ：)

根据rup的要求，光分析员就有那么多的分工：业务流程分析员、业务设计员、业务模型复审员、需求复审员、系统分析员、用例阐述者、用户界面设计员。
看来，我们基本没有哪个工程按照这种方式分工，即使生搬硬套，那也不会见的能够成功，软件工程的思想本身就是多人的智慧的总结和结晶，并且见仁见智。本来的目的就是增大工程的成功的可能性，减小开支、增加软件的质量等等。无论如何利用软件工程，只要达到目的，那么就成功了。也就是说‘不管黑猫白猫，逮住老鼠都是好猫’，哈哈。
看来参与此讨论的大都或多或少作过分析，谢谢各位捧场。

各位，大家先休息一下，看看俺写的小说，嘿嘿，提提建议。

http://www.Codefund.cn/expert/topic/1020/1020415.xml?temp=.4313166