提高软件水平从底层做起——编程模式
　

---

编程模式定义为：使用特定的实现技术解决特定的实际问题时，比较清晰、简洁、合理的编程思路和实施步骤。编程模式的内容包括命名规范，数据结构定义方法及规范，通用程序结构，通用程序处理流程等。编程模式和设计模式比较：设计模式是针对某种特定问题的通用的设计思路，而编程模式是针对某种特定问题的通用的编码思路。可见设计模式是针对设计的模式，编程模式是针对编程的模式。设计模式在现在已经受到软件界的广泛关注，使用设计模式，可以提高系统设计的效率、质量和可读性。但是编程模式一直以来没有受到人们足够的重视。新手程序员往往得不到这方面的培训，需要自己花费很大的精力来寻找一种编程模式。这样降低了开发效率，使程序代码晦涩难懂，可读性差，而且代码隐藏BUG的几率很大，影响了系统的稳定性和质量。经验丰富的程序员和编程高手们，掌握了大量的编程模式，但是这些模式都作为个人技巧，很少拿出来交流。这种状况使高手们的编程模式各不相同，所以他们编写的代码可读性也不高。而且由于缺少系统的交流和整理，高手们的编程模式也难免存在一些不尽合理的地方，甚至可能潜伏了一些影响系统稳定性的错误编程步骤。
软件工程是当前最热门的讨论话题，很重要的一个议题就是质量控制。印度软件业因其质量过硬，成为我们的偶像。静下心来比较一下，印度和我们的主要区别之一在于软件业的基础——程序员。让一群印度程序员用同一种编程语言解决同一个问题，会发现他们的程序几乎一模一样，变量命名、程序结构、处理思路等就象是抄袭下来的，可以说他们在使用相同的编程模式。如果让一群我们自己的程序员做同样的事情，会发现基本上找不到两份相似的代码。印度人的平均智商不可能比我们高，这方面是举世公认的。但是印度人在软件业上踏踏实实的心态，就不是我们能比的了。站在软件工程的角度看，所有的程序员都以相同的编程模式作为模板编码，是保证代码质量的一条重要途径，毕竟所有的软件系统都是建立再代码之上的，基础不牢，上层建筑再花哨，也没有太多实际意义。软件工程是一个侧重应用和实践的领域，国外的工程方法更多地来自实践经验，所以可操作性很强。但是传到国内以后就变味了，许多人更愿意把它抽象成纯理论去研究，最后出来的理论，看上去非常完美，用起来却没有效果。
我们的现状是缺少对基础问题的关注，业内一些人寻找各种高深抽象的理论想走出困境，另一些人对国内软件业彻底绝望，只有极少数企业在关心这些实实在在的问题。编程模式应该被明确地提出来，系统地交流、讨论、整理。每个项目组在编码之前，都应该归纳总结出一组针对自己开发环境的编程模式，要求程序员以这些模式为模板进行编码，质量检查人员以这些模式为标准进行质量检查。当然编程模式需要不断地补充和完善，这个不断改进的过程需要项目组所有人员的共同智慧。关注这个问题，我们的软件代码的质量和可读性将大大提高。我们就可以在软件开发水平上迈出踏踏实实的一步。

的所谓杰出的质量吗。
印度软件业的成功是因为有机器程序员的缘故？
去学点商业基本知识吧。

 回复: 提高软件水平从底层做起——编程模式
　

---

不太同意、

 回复: 提高软件水平从底层做起——编程模式
　

---

我也没碰到过印度方面的程序，据有关资料讲，美国注重分析、设计方面，而印度注重编程方面（工程外包），这也是为什么印度在软件工程方面领先的原因，和通过CMM领先于其他国家的原因。提高软件水平到底要不要从底层做、怎么做？首先我想你的态度无疑是非常正确的，这点无任何疑问。但是怎么做？我觉得，不一定非要从编程一步步做，至少不需要每个人都这么做，想一下，是否所有的建筑设计师都从瓦工开始一步步做的，也许比喻不太确切。但设计师必须了解瓦工是怎么完成的，好像构架设计师一定要熟悉编程，单不一定要精通，当然不了解编程的设计师无法想象（请注意了解、熟悉、精通的不同含义）。我说想表达的东西很简单，软机水平的提高需要各个层次的人，各有精通，而且并非“编而优则设或分”，每个人应根据不同的情况，做取舍。

 美印的区别是有原因的
　

---

美国人力成本昂贵，必须通过关注分析和设计降低项目开发成本。
印度人力便宜，关键不是再降低多少成本，而是确保项目能够完成。能够收到开发费。

都说国内开发差，但如果同样的项目，经费能再增加3，4倍完成情况还会这么差吗。试想一个小项目能给客户节约两个人工，以国内1000元月收入计客户企业一年可以获利24，000元，能给多少开发费用？美国年薪以最低的3万计，客户企业可以年获利6万美金，合人民币约50万元，又能给出多少开发费用？

看看赞扬印度模式的文章，真正在开发上和印度有接触的也就华为的那篇文章。我以前的项目中见过一次来自印度的源程序，现在的项目又和印度一个外包公司的项目管理人员email接触了6个月，我个人的感觉是，如果我有决策权，选择印度开发的基本前提是投标价格不超过竞争者的1/3。说实话我正在考虑从目前项目辞职，因为受不了印度人的办事。不是一个差可以形容的。

当然，印度和美国的工资差价可以保证它用低价竞标，所以它全是外包欧美的项目。印度的成功是商业模式上的成功。个人的提高当然从编程细节，设计模式，全局观念等等都要考虑。但是作为一个行业的成功，不是依靠少数明星程序员。首先是很现实的商业问题。不能把商业成功和个人能力提高混为一谈。
好像很多人都喜欢以万金学屠龙之技，却不考虑何处有龙。

 中国也存在印度模式！
　

---

不知道大家所在的地方有没有，上海就有好几家比较大点的公司（200人以上，算大吧？），接日本的订单做。人家给我们的是详细的设计，我们所要做的就只是代码而已！以前我在其中一家任职过，据我所知，他们从来没有做砸过，其他几家也是。这些公司很愿意做这种事情，风险小，收入稳定，所以他们的公司发展得比较快，4年前还是不到100人，现在基本上都在200人以上。他们通过认证也应该不是很困难的事情，量化也不是难事，但是他们的国内项目，照样一塌糊涂！
所以印度模式没什么好的，只是一种商业模式的成功，并不能说是软件工程的成功。
中国的软件工程要发展，就要给程序员灌输软件工程的概念，在设计和编码的时候考虑到全局，而不是搞一帮子只会说不会做的人来做所谓的分析设计！

 呵呵，这是当然。
　

---

在日本，不考虑最近几个月的不景气。一般最终用户为开发支付150万日元/人月的费用，然后IBM，NEC之类的大公司将项目以100-120万之间的人月费转包给下一层公司，层层转包之后，最终开发公司实力强的还有80万左右，一般是大约50万的人月费，转给中国国内开发是大约30万日元/人月，折合人民币近2万。事实上，日本的人月计算是比较宽松的，我个人观点是有1/3到1/2是被无能的所谓开发者浪费的。国内公司的员工素质远比日本为好，而且项目经理可以安排充足的员工在开发测试方面。一般而言，会从日本交给国内开发的项目是需求比较固定，日本方面也安排真正熟悉业务的SE来设计，因为交流问题，一般事先准备比较充分。所以开发难度不大。真正的难度在于要在日本有足够的承接项目渠道。如果能把上流设计也接下来，利润还能大幅度提高。
做国内项目的时候，没有这么多经费可以安排足够的员工，对员工的个人能力的要求就提高了，出问题是正常的。其实就是同样的人才，同样的项目，人工费不一样，整个项目能投入的人数就不一样，效果当然也不一样。软件工程只是用来帮助确保项目能顺利完成而已。能否高质量是看员工本身的素质，实施软件工程不会提高员工能力，只是降低出错概率罢了。

日本有这样专门接外包的公司，我看过日本人开发的一些程序，也是错误百出。
（可能我看到的程序员水平比较低），正像上文说的，主要靠资金，人力保证。

还有一句话, 那真是屠龙之技吗? 屠龙之技是这样学得到的吗?

 充分证明了我国古代就有了市场营销的天才
　

---

现在的培训业者应该好好学学当时的手法。
呵呵。

 这种模式在国内普遍存在，最典型的是服装行业
　

---

苏南、浙江、福建和广东等地的服装企业，有些你根本没有听说过，但是他们的产品在美国销量很大。因为他们自己只有加工的本事，品牌是别人的。同时在国内品牌市场开拓真正成功的，就寥寥无几了。印度的情况跟中国的一样，只不过中国是服装和家电，印度是软件，仅仅换个行业而已。中国在IT这方面也做起来了，上海给日本人写代码的，起码有上千人

别人先实践总结再出理论，中国是先研究理论再往下推。
政府部门对技术的支持不利，信息产业部都忙着和微软合作捞钱。

 各位如果参与过多个项目的底层编码工作,大概会明白我的感受吧.
　

---

写这些东西,确实不是我无病呻吟.不成熟的地方,各位也不用客气.目的只有一个,把自己的想法写出来,希望能对大家有点帮助.
人云亦云,我并没有什么不好意思.别人好的观点,吸收过来没有什么不妥吧.
当然并不需要每个人都来用编程模式作为模板写代码,只是希望项目中的每个角色都能关注这个问题.软件水平的提高需要各个层次的工作,我只是对编码这方面提些建议.
各位大虾从不同角度提出的观点,相当精辟.印度软件业也不是全能的,但是至少他们编代码的方式还是有可取之处.
政府部门对技术的支持很难落到实处,要等到这种情况出现,感觉遥遥无期.我想企业领导的理解和支持更实际一些.

 中国软件的出路
　

---

中国软件的出路不是一部分软件人员说说就能走出去的,关键是在于政府和社会的支持,前段时间看到我们自己开发出CPU之龙芯,感觉很是高兴,可是就像有识之士所说得,我们更需要自己的软件,这样就离不开政府的支持,你想象一下,象开发的操作系统,只凭个人的力量是不可想象的,这需要政府的投入和支持,(在政府部分使用自己的操作系统等软件),这样才能给软件开发人员带来良性循环,包括资金和软件的性能,只有有人用了才能发现不足,
　

良好的编码风格对项目成败有很大影响。但缺乏完善的设计则影响更大。
个人提高需要学习编码风格，提高语言掌握程度，了解设计模式等等，但对项目开发，是另一回事。软件企业的运作，又是另一回事。
能看到缺乏编码风格带来恶果的项目，基本上都能看到管理混乱的表现，而且设计混乱也是八九不离十的。因果不要搞错。
维持一个统一的编码风格，和RUP之类的软件工程一样，是软件企业在市场竞争中的要求，在单个项目中的开发上作用没有你想象的大。当然，在企业还在梦想政府支持，企图成为温室里的花朵时我不认为企业会有足够的动力为了市场上的优胜劣汰增强自身的实力。于是不是出于实际，而是所谓理论研究和做秀的目的搞几个认证，能不带来反效果就不错了。如果企业领导对开发能力提高没有兴趣的话，那这种企业的破产倒闭没有任何值得惋惜的地方。
印度的开发，你如果没有见过，最好不要先羡慕起来，等到你能允许一个程序员一个月只出300行代码再说。而且到了这个时候，也只是能完成项目，而不是能优秀得完成项目。不要因为大家都说印度软件了不起就人云亦云，这和我们的服装占领欧美低价市场是一回事。
话说回来，从项目开发的角度，能否获得足够的合格人员，士气，分工，能否合理分配工作，调整设计以符合人员能力，使人员能在各自能力范围内人尽其用是最优先的。如果没有足够的合格人员，再多的书说不好也只有copy/paste，为了完成项目，而不是完美但完不成项目是理所当然的。有高手在场就完全是另一种设计，更快更好。所以人的因素是第一位的。
软件开发不过是一个行业而已，和别的行业没有太大区别，不要想的过于神奇。当然，合格项目经理的缺乏是软件企业最大的隐患，同时程序高手也远比想象中少。个人要成才，但企业不能指望每个项目都有一流高手坐镇，当然我指的不是那种所谓高手。

 作者应该注意学习
　

---

编程PROGRAM是从包括需求设计编码测试等各种对程序开发工作的总称，所以这里说什么编程模式显然是某些人理解有误。
印度的软件工程水平大大落后于世界，即使是中国这样的原始开发方法也要比印度的好。通过CMM5不能说明任何问题，就像不能以DoD规范还是瀑布方法，我们就认为瀑布方法是好东西一样。一个没有设计思维的软件工程根本就谈不上软件工程，最多就是软件操作工程。
印度的代码可读性非常差。总的来说如果是他们自己设计，那么基本不具有可读性，事实是如果从一段代码来说，他们写的都很明白。但是你只能明白的就是他们的这些代码片断，总体而言你不能知道他们在程序中是起什么作用的，以至于有些程序你都不知道是做什么的。他们被我们一直赞扬的文档 由于我最近的接触，看来基本也没有什么可读性，基本上就是一种流程产生的无用废物，充满了由于各种规范和格式带来的对可阅读性的障碍，根本就没有考虑到人的阅读习惯。而他们一直被人所称道的价格优势，随着各种工具的发展，将不复存在。
印度的做法规范而不正规，是软件工程领域的怪胎。如果不是由于人力资源的优势，他们将一事无成。
软件行业的基础不是那些编码员，而是软件的设计人员。而看一个企业是不是实行了软件工程的方法最直接的标志就是看他们是在设计软件还是在编写软件。
国外软件工程领域的进展主要来源于实践，所以CMM这类来自于学院背景的东西从来就没有被主流的接纳过，被称为上一代程序员的标准。如果不是由于U.S.A.的参与，它的下场也可能和ISO没有什么两样，类似的标准还有很多。如果大家有心情去看，可以到NASA的那里去浏览。
软件行业的发展在于大量小企业的合理生命周期，而不是向大多数人以为的是大企业的长生不衰。从这一点来说，我们的环境在这几年极度恶化。现在政府采取的措施更是火上加油，从现在地趋势看再过五年，我们将谈不上有什么软件行业，而更多的是一些软件概念，或者成为美国日本的附属。看看我们现在还有什么，原来有那么多优秀的软件richwin wps......现在他们都怎么样了。那么多优秀的程序设计者他们都哪里去了，为什么没有新的优秀的人才出现，填补他们的空缺。不是我们不能产生这样的人才，而是环境的恶劣，使这些人才根本就成为不了市场的胜者。
软件行业不需要政府的支持，需要的是政府的公平。

否则哪来什么 " 1,2,3,4 用 UML 开发系统只要四步" 云云

我觉得重视编程的规范是很重要的。可以增加可读性，便于交流。很多问题都源于沟通的问题。这是一个方法。方法用的好不好，还要看使用的人。设计得好，编码时晦涩难懂，也不一定是好事。不能一概否定。

在编程时就主要是小片断了，只要不是碰上用a1作变量名，func1作函数名的主，这种小型的循环分支不会对理解有太大障害。
另外，政府支持破坏的市场的调节功能，使软件企业脱离现实，是软件业的最大危害。

说的极其有道理。目前一个公司是否能够接下一个项目完全是关系在起作用。没有人关心你的开发和设计规不规范。工期紧经费少必然会造成软件质量差可维护性差等特点。
对于开发产品的公司，更是只要功能完成即可哪里有什么设计，完全是码字。所以中国作软件只是急功近利的多，踏踏实实的少！最终的结果是水平日渐下降沦落为不入流的水平。

可是一般详细设计和编码都是同一人。有些编程不只是小片段，可能有一些重要算法；还有在程序头不做一些说明，如果设计文档又不及时更新，那还不是有点猜谜语似的猜这些。现在很难有这样的集成环境，将设计文档与源代码建立链接。一般配置管理工具（除了CLEARCASE）很难自动做到这一点。就是CLEARCASE也不能与所有开发环境无缝连接，它不是支持所有开发平台。如果上游都规范了，还好说。（那是比较难的）。

一批公司倒闭也不要紧，留下来的就是精华。
就怕没有一个公平的市场，劣币驱逐良币。但是这个大环境不是我们能控制的。只能盼望了。

 回复: 这个不怕。只要市场的优胜劣汰还能起调节作用
　

---

在中国，从有软件以来就没有公平！最早是崇洋媚外，现在又加上了政府乱指导。只能是越管越乱越来越差。

能满足这个条件，才有编程风格可以放松的说法。

软件编程规范，设计模式，分析模式，软件工程等等，庐山中的一切因素，对中国软件行业的损害，远远没有商业风气败坏带来的损害。
有多少软件项目是为了显示政绩而立项？
有多少软件项目是因为私利而立的公项？
有多少软件项目的单子是因为关系而获得？
这样的软件项目有多少会遵循软件开发，乃至做任何一件事的常识：先搞清需求。
这样的软件项目有多少不会盲目追求进度？
可爱而可怜的软件人，在努力提高自己的水平的同时，对做人模式能做点什么？
地球在向东转，你产生向西的位移吗？
对不起，我把问题扩大化了。

 回复: 作者应该注意学习
　

---

不知道评判一种观点的标准是什么呢,如果因为某个局部缺陷就否定整体,感觉有点偏激.把需求设计编码测试叫编程,这种定义也许合理把,但是现实中这么理解的人并不多.感觉现在各种术语的定义越来越混乱了.
也许印度阿三的软件业确实不值一提,但是大家都认同他们的程序代码是规范的,很容易明白.程序员的职责就是完成自己那部分代码的,软件的总体结构是设计人员的事情,只有每种角色都出色完成自己的工作,才能产生优秀的软件.程序员确实是基础,没有好的程序员,再优秀的设计也会变成一堆晦涩难懂,充满BUG的代码.
我想没有完全没有用的东西,存在就有它存在的理由,就有它的可取之处.十全十美的软件工程,大概我们这一代等不到了.软件业在不断积累经验,在不断吸取教训,在不断发展.更好的工程方法的提出,都是在那些老的理论之上.
对软件业的分析我很赞同,政府的作用确实没有到位.

你要从这里着手当然可以，事倍功半估计是在所难免的。
好的程序员和合格的程序员是有区别的。
一个优秀的设计由若干名合格程序员用各自不同的编码风格完成各个部分，最后的效果肯定好于这些人用统一的风格完成一个拙劣或者一般的设计。这个和算法比技巧更影响性能的道理是一样的。算法决定性能的数量级，技巧改变性能的百分比。
你说“大家都认同他们的程序代码是规范的”，我不知道这个大家是谁，你大段引用了华为的文章，我不知道为什么一篇文章被流传，引用就变成了大家认同。还是这句话，你最好先和印度人接触一下或问一下有过接触的人再下这个结论，或者你查一下是不是这个大家最后的来源都是华为这篇文章。在这个坛子里，ozzz老兄和我是和印度人的项目打过交道的，我们的态度也很明朗。你不妨问问还有没有谁在真正和印度人的软件项目接触过继续对印度的软件工程赞不绝口的。也许真的印度人的程序代码是规范，管理很完善，在我看到的两个印度项目言，那只能说明规范的代码，完善的管理对软件质量没有影响，拙劣的设计把一切优势都抵消了。

我觉得从这里入手比较现实。因为由于进度等各种各样的原因，设计文档不马上提交可以。但是编码是必须做的。那就可以考虑从这里入手，在往上游走。其实项目管理的理论都比较经典，企业往往缺的是如何下手，如何实施。道理再好，推行不了，或推行难度大，都不能改善软件项目管理。

如果没有设计，程序员又都是乱七八糟的菜鸟，项目失败不是理所当然的吗。
除非项目规模小，不觉得有任何编程规范能帮助这样的项目成功。
从个人角度，可以是提高自身能力。从项目角度是完成项目。从公司角度则可能以一个项目为代价为其他项目积累经验。侧重点就看你的角度了。可能从个人角度看优先的对项目不考虑，但到公司层面优先度又能提高。

我是说不提交设计文档。不是说没思路。不知道你是否在一个项目管理起点很低的企业做过，我就做过。那些技术人员都说设计都在脑子里。要赶进度，领导都没办法。但是代码总得写，是显形化的东西，只能从这里先入手。习惯了，往上游推就方便了。知道重要，没办法推行，还是没用的。我是具体在做项目管理，整个企业的，就我一人。我必须争取技术人员配合。从这里将好办一些。

 回复: 提高软件水平从底层做起——编程模式
　

---

我对设计模式和编程模式之间的差别有异议，难道编程模式真的和设计模式分得这么严格吗？现在流行的UML工具ROSE就是一个对编码模式和设计模式较好融合的例子。你可以在UML设计构建模块，同时你也可以通过正向工程向编码转换（当然不是大部分），所以说我对两个模式的划分有异议。另外，我们以前所作过的CMM项目管理里，对设计模式和编程模式划分也不是很清楚，在其软件开发生命周期中，所有的工作几乎都是在设计阶段做好，编码其实涉及时间都是很少，一般大概只有三个星期吧，程序员都快沦为打字员了！你能说这是对编程模式的不重视吗？所以，保持对你的文章的异议。

 呵呵，您成功了吗？
　

---

设计都在脑子里，没有什么不正常的。（个人观点）
问题是您知道这些程序员的能力吗？他们的设计值得信赖吗。
如果你的进度已经是从编程开始，我不知道你还会有什么上流可以推。你所要做的不是项目管理，而是尽力去招你所知道的最好的程序员。

项目管理起点很低，为什么不是加强管理，一句赶进度就能打倒的管理能要求程序员按规范编程吗，如果程序员用赶进度作为理由拒绝执行规范，如果有对策的话为什么不能用在最初的管理时？你的程序员都是这么不可替代吗。

至于工期太紧，开发费太少，有两种原因。一种是不应该承担的项目被接下来，公司不考虑开发部门的意见承接了过于困难的项目，那么不是项目经理能解决的。另一种则是开发能力薄弱，原本可以完成的项目工期被延长了，每个人也同样在大叫时间太紧。项目经理能够分辨自己的情况属于哪一种吗。

至于我有否在项目管理起点很低的项目里干过，很难说。
我曾经参加过一个项目，需求只有5页纸上的五张用户界面图，4个月，15个人。边开发边确认需求。从来没有人检查我的程序用什么风格，没有任何要报告的，没有人问过某个功能完成了百分之多少，他们只是到了预定时间将模块拿去测试功能而已。所有开发者（15人中有8人）都是如此。结果这个项目是该公司3000人的开发部门中被评为当年度最佳项目。公司还发了奖金。您说这个项目管理算弱算强？我说不上来。
我也参加过一个NTT的项目，每天确认上一日进度完成情况，本日预定，然后和每周日程安排对照，50个人，全是30岁以上，8年以上开发经验。需求的WORD文档有几个M，培训手册400页，管理如何？开发半年后因为一个关系到全体功能都不能执行的问题，全员调查一个月，无周末，每周二个通宵。没有结果。我的公司派我从工作中脱身临时去协助他们一个星期，查源程序，只要加一句话，他们继承了一个管理类，却漏了调用父类的初始化函数。然后他们终于可以开始测试功能了，结果发现80%的功能需要重写，因为他们的程序员将编译能无错误通过作为该功能100%完成的指标。这个不说，我没事干就看他们的培训手册玩，结果发现在手册里那个管理类如果继承，必须要调用父类的初始化函数的注意事项白纸黑字写在上面。一个星期后我离开这个项目，据我所知，这个项目最后用了1年半，NTT对他们评价很高，因为他们在开发现场经常就是没日没夜的干，最后NTT是认为自己的要求过于无理，但在开发商的努力下终于完成了。这个就是功夫在诗外的道理了。您想学这样的管理吗？

要技术人员配合，自己多掌握一点技术是没错的。光依靠死的规范，上有政策，下有对策，是没有用的。

1.充分证明过度工程是极度有害的. 在50人以上的项目里，详细的需求文档和一定的培训手册是必需的，但如果文档易读性很差的话，尚不如一个几页纸的摘要好。

2。为什么半年后才开始测试？没有单元测试吗？从这一点看，可能或者项目采用的工程方法执行时有点过于僵硬，或者管理有点迷失目标。出现那样的问题几乎是必然的。呵呵，不知贵公司有多少个老兄这样的救火队员。

3。每天review进度实在过细了，在项目攻关阶段是可以的，但作为日常手段则不太对。我很惊讶最后这样的项目1.5年后完成了，项目过程中人员流失率不知是多少？

4。强调编码风格本身没什么错误，但如果把它作为管理的起点确实太低了。作为持续改进的起点，应该选那种阻力小，有共识，效果显著的来做。选一个阻力又大，见效又小又慢，就是在论坛上说说都会招来这么多反对意见的起点，不是自寻死路吗?:)

顺便问一句，那个项目delay了多少个percent?
　

我想争论的起因更多地源于所站的角度.项目管理员,更偏向于站在项目外部,从旁观者的角度,全面把握影响项目的外部因素.影响项目的某些内部因素,尤其是技术方面的,我想设计人员和程序员更清楚.你说的项目组,虽然有培训手册,但是很明显项目成员包括管理员没有结于足够的重视,结果很关键的一个技术点大家没有弄清楚,编出来的代码隐含了一个BUG,影响了项目的进度.
需要说明的是,我提的东西不只包括一个编程规范,还有关键技术点的编程思路.集合大家的智慧总结的编程思路,应该是更合理,更完善的.

我想它们的区别在于工程的不同阶段,针对不同的方面(设计与编码).如果详细设计做得非常细,那么设计人员掌握的编程模式也会影响他的设计内容,参与过设计的人都会有这个经验.
另外我发现这个问题更适合做设计和编码的人员讨论.因为这是影响软件的底层因素,只有直接和代码打交道的设计人员和程序员,才有更实在,更深切的体会.

是公司出面在我原来工作的地方请了一个星期的假，再去NTT的。是因为我们公司有两个人也参加这个项目，被逼急的缘故。呵呵，最初公司想派我参加，不符合30岁以上8年工作经验原则被刷下来了，只能再派到另外的地方。
项目原本预计是一年，中期时就开始测试在日本已经算早的了。另外，这个系统是基于WEB的，使用Weblogic，有全套带source的工具箱，这套工具箱很不错。可惜硬生生被糟踏了。基本原则是将页面上各按钮的操作执行函数和按钮编号在一个映射表中对应，程序员只要直接写各个函数即可。但是初始化的问题让映射表没有被加载，所以当时的问题是没有一个页面的按钮能响应操作。自然也无法测试了。他们一直坚信函数写法没有错，只要这个响应操作问题解决就一切都好了，事实上，加了初始化函数后他们才发现对工具箱的调用方法几乎没有一个正确的。
人员流失率倒是好像不高，50个人当中上层设计人员和各级管理人员有近20人，编码的30来号。据说他们成功的把项目延期的理由推到了需求变动上。水平还是不错的。
1年半结束，举我同事的说法和带回的source，最后结束的时候情况是这样的。所有的页面类都是继承一个共同父类，然后在所有的页面类中都有一个一模一样的logmessage函数，本体三行，函数说明8行，当然写法绝对符合编码规范。不把这个函数写到基类的理由是当时写共同基类的程序员人工费单价太贵，写完基类后项目经理认为白养这么个昂贵的人没价值就离开了项目。然后就没有人愿意担责任改这些公用类，反正每个人负责2-4个页面类，从一个模版copy也不是大事。性能方面，这个系统有一个检索，显示人员简单情报列表，然后选择某个人可以观看详细情报，这个功能很正常吧，问题是详细情报极其复杂，他们是把检索结果中所有人的详细情报在检索结果列表时就全部读入。结果在512M内存的测试机上检索一个有100人的部门，需要6分钟以上才能出结果，知道怎么解决的吗？技术组长称一则以部门为单位检索比较少见，这么高级的领导一般只检查手下几个经理的情报，不会去看整个部门成员的情报，二来实际运行时，数据库和web服务器是分开的，各自有2G内存，所以性能不会太慢，结论不用考虑。就这么留下来了。别的就不用多说了吧。诸如数据库里的冗余数据等等。
嘿嘿，这个项目，仅仅是Oracle数据库的license就是接近200万美金。每人每个月的平均工作时间是300小时，最忙的5个月达到400小时，我估计开发商最后会亏在加班费上。
另外，每天review进度倒也不花多少时间，是以5，6个人的小组为单位让小组长负责，也就是2，30分钟的事，对他们言花得起这个时间。
每个程序片断倒都是符合编码风格，其实编码风格光说命名规范，是太小了。说到什么时候应该用引用，什么时候应该用指针，又太大了，掌握这个规范难度和理解thinking in c++也就只差一点了。管理，设计，需求，测试，人员能力等非要分个先后还有点困难，但都在编码风格之先应该是没有问题的

每天review进度确实花不了多少时间，不过我认为从管理角度看不好，除非是项目组长只是自己观察做纪录，做到自己心中有数，如果每天去追着程序员问进度，要是我被问上一年半，非疯了不可。所以我问你人员流失率有多少。呵呵。：）我估计这个项目是在日本做所以人才能留住，如果在国内做，超出一年的项目估计部分人员已经换了好几拨了。
　

一个月300小时的工作也不是我能承受的，但他们都坚持下来了，呵呵，还是很了不起的

这个就有很多要考虑，要平衡的东西了。没有一个绝对的标准。
而规范需要一个显式，简单的判明标准，否则无法执行，需要的是诸如1+1=2之类的固定形式。
比如说在C++里用类的实例做函数参数，是用引用还是指针，如果规范写成在参数不可能为null，且不会在函数体内修改时用const的引用，在参数可能为null且可以在函数体内修改时用指针，以此类推等等，知道的人是知道，原来不知道的人一样要去学了C++这一段的内容才知道，如果类似的内容一多，这个规范和ISO14992也差不多了。
如果你干脆在规范里限定必须用引用，那么语言的功能就受限制了，迟早你会面临是改变规范还是用一个更繁复的设计来完成一个简单功能。
最后，真正可行的规范就只剩下命名，空格数，注释风格，括号是在if后面还是下一行之类的小问题了。这当然增加了可读性，但如果设计良好，都是小函数，那么在不同的小片断处对类Object的变量有aObject/aObj/objTemp之类的不同写法不会对项目造成太多困扰。

但是如果对于公司来说，程序员流动频繁，就意味着经常需要接手残余代码，而且没有培训价值。程序员人数众多，意味着无法充分了解各个人能力。程序员工资便宜且大量制造，意味着能力不能太过信赖。承接项目能力强=项目众多意味着没有一个项目重要到不能失败。可以忍受人海战术完成项目意味着不用太考虑设计，复用等等，只要完成项目即可。这个时候引入规范就是必须的了，在不培训的基础上可以尽可能保证正确率，即便用繁复的设计完成语言固有的一个简单功能也不要紧，只要能完成。我想知道有几家国内软件公司能达到这个标准呢

其实一个是胡说八道，一个也就只关心有没有按时完成，所谓的70%，80%完成度也不在意。但所有人都一本正经。最后这个项目能完成我也的确很佩服他们。能坚持这一点他们比我们强。

 路漫漫其长远兮，吾辈当上下而求所！
　

---

从自己作起，能起多大用就起多大用吧！

佛说UML，即非UML，故名UML，呵呵