在处理代码，我们自己写代码的时候，我不知道现在开发人员怎么写，但是我们自己总结出来以后，我发现要写一个文件时要先把它主干提出来，然后再给它填枝叶，那怎么写呢？我们进行了成对编码，先写上面大括号，再写下大括号，然后再加中间的，因为我们实际在以前做过的过程中发现很多代码最后分配了很多内存，没有地方去释放它，最后机器自然被消耗，程序就死掉了，所以成对编码我认为就比较重要。
小一点程序在环境里面就自己生成，把它拼凑成一块就把它拿走，我认为这种方式不是很好，应该把它建立成BUILD，把所有文件放在一起写成TXT文件，然后就输入BUILD命令，它就能把你所有你要的东西相通的。
我们实际发现使用过程中用CVS做为代码管理比较不错，CVS能解决两个人同时写一个文件时怎么办的问题，绝对不是说我在编这个文件别人不能编，在同一个文件里头，也可以解决，两个人可以在同一个文件里写。这个CVS可以直接把这两个部分合并成一个文件，解决同时编码冲突的问题。
还有一些开发理念的习惯，我们觉得比如像代码在教科书里面比较多的，还有实验性代码比较多的与assert有关联，我们实际使用中不要用这个东西，因为这个最后推出产品的时候，有两种方法，一种可能根本把这一行去掉，另外一种运行时会出错，弹出一个对话框，如果你怀疑这个地方有问题，就应该有一个相应的处理方法在这个地方，就不要使用assert来取代它。
我们早期版本用过一些MFC的程序，后来我们发现错误很多，现在就不用了，MFC可以产生很多废码，看起来效率很快，但是问题很多。我们宁愿慢一点，但是要很多东西都可靠，这些代码可运行性很高。在代码实际中分层次编码是非常重要的，在每个行数前面一定要有一个统一格式的注释，你代码里面没一个注释也是很重要，但是每个函数前面有一个比较完整的注释，别人看这个代码时就像这个东西是我写的。这样使得这个团队有一个比较好的协作基础。
主持人潘加宇：
谢谢梁总的精采发言。
提问：
我想请问一下梁总对代码的重构有什么看法没有？它是指一开始的时候就比较快，还是比较规范的很快写出一些代码来，不考虑以后的需求变化，等到以后需求发生变化时再去给它想办法重整这个代码，在它不影响它的功能的情况下？
梁肇新：
我们使用动态库设计这些东西，在设计整个软件的时候，我们也有一些开发人员不了解这个开发性，代码写得比较封闭，一个程序用一个大类来实现，最后给这个东西添加功能时非常困难，所以我们就要求实际开发过程中尽量把所有东西能提出来放在动态库，以免将来改变时的麻烦，再不需要对动态库进行改变，你只要在需要改变的地方进行测试就可以了。
提问：
您以前是个很成功的程序员了，成立自己公司以后从开发第一线退出来，从第一线到开发人员这需要在思想上有什么样的转型。您对软件工程方面是什么见解？感觉到自己公司在软件工程上需要有什么帮助？梁肇新：
我们公司现在规模还比较小，我们最困惑的是2000年的时候，当时我们团队刚刚建立起来，为什么我们会建立代码规范化，也是因为实际中代码混乱，所以我们在实践中建立起来。年底的时候我们听说CMM，我们去请一些老师过来实际培训了一下，使我们视野开拓了一些，但是实际上还是按照自己实际需求。朝这个方向做是很有必要的，但是做的过程中我们是很谨慎的，不会把原来东西打乱了，我们主要目的是使我们开发更加可管一些，更加规范化一些。我自己一直定位为程序员，就是开发人员，而且我本身就喜欢编程，我觉得编程就是一种娱乐，而不是一种工作，我一直在做实际编码工作，所谓代码规范也是我实际使用中发现它有很多好处，然后再总结出来的。
提问：
您怎么处理编程的身份和总经理身份的？
梁肇新：
像我们公司技术方面我主要负责这方面，还有产品，如果要决定什么样的东西，比如2000年网络很火的时候，市场人员要求我们是不是也搞网站搞风险投资，我觉得这跟我们定位于软件企业根本不同，这两个相当于跨行的，所以这东西不是我们要做的，所以最终我们还没有做这方面的工作。我主要是做技术，在技术的前瞻性，看哪项技术能运用到哪些产品里面去，目前最新技术是什么，这些技术我们拿过来以后，我们能做什么样的产品，我主要考虑这些东西。而实际中我会做一些比较先进的底层的技术，做好后提供给实际项目中使用。
提问：
您是作为程序高手或者程序英雄，我非常好奇，如果您总是编程，您不可能管理好一个团队，你可能抽出时间进行管理，您怎样处理编程和管理这两件事情？
梁肇新：
管理不是我的长项，我们工作的日常管理和其他管理有其他人做，我就相当于技术骨干的角色。
提问：
我问一个问题。我接触了很多出版界的朋友，我发现国外软件工程软件管理在知识资源上非常丰富，但是国内比较少。那我想问一下，大家也是在实践中去带团队，也要鼓励自己团队中成员去成长。从知识角度来说，就看他们有什么样的素质，我希望嘉宾从个人体会来说，如果您希望您团队成长的话，从知识角度怎么样来配合？
周之英：
我想这个问题从我们国家来说，应该从教育和工业界共同努力来解决这个问题，某种意义上，国际上包括美国也在重新认识这个问题。从总体来说，软件工程是超越一个具体项目，但是很多人现在并没有把软件工程中间那些思想本质的东西掌握到，而是把它当成很简单的理解：一个规范，我照猫画虎就能做了。
我教软件工程课也碰到这样的矛盾。有人总说周老师你教的东西太抽象了，我也学不了那么多，只要给我一个样本就行；我要做可行性报告，有没有东西给我抄一份。这很典型。当然这个情况可能特殊点，但是对大多数人也一些影响，程度不同而已，就没有把它作为很重要的、发展软件工业的基础来看。软件工程里面有不同的层次。
国外这方面开展研究很多。我们国家一开始就有一个误区，就是从80年代初开始搞软件工程的时候，认为软件工程一个是规范，第二个是中国开发出自己的工具来就行了，看成非常死的东西。考虑一个规范，好像什么东西也不需要，就可以照着做、就能解决问题了。第二个误区，只要开发出一个东西，然后这个东西就能解决一切的问题。实际发展的二十年来，不断地探索，人做软件的一些规律性的东西，包括技术的东西。里面有各种不同的层次，包括编码，需求分析，开发，发展新技术，有很多层次。我觉得今后教育方面有很多工作，比如现在的大学教育中，就像编程问题，没有一个教科书里写工业产品的编程是怎么编的，学的编程课程是学语言，就把语言弄懂了，这是面向对象的语言，这是结构化的语言，是学语言而不是学做工业化的东西。
其他层次的都是需要很深层次。我有时候也很困惑。有人跟我说：我对软件一点不懂，我现在要搞一个软件项目，你告诉我我怎么去管。我想如果要建造一个房子，没有一个人会对建筑系的教授说：我明天要设计摩天大楼了，我对建筑什么也没学过，请你告诉我用什么办法，我明天投标去。但是你看软件就有这样的状况。当然软件也有它方便的地方，现在技术使一些软件很容易编，但是你要做到不同层次的话，就有很多深层次的问题。
所以我觉得一个从工业界怎么不断总结，一个从教育界怎么能够改变过去仅关心计算机科学技术，也去关心软件工程的问题。以后可能对我们国家的长远发展会有一个比较深刻的改变。
主持人潘加宇：
今天到现场的还有一位，大家知道国内软件工具有一个叫做“PLAYCASE”，这是一名叫高展的先生基本上是他一个人开发出来的，因为国内软件工程大家是谈的多，做的少，软件工具方面像青鸟开发了一整套，但是一般公司一般人都见不着，不知道用在什么地方，但是像高展先生，他一个人踏踏实实地把“PLAYCASE”写出来了。下面请高展先生说怎么把“PLAYCASE”写出来的。
高展：
书生公司王东临先生提了一堆问题，我从两个角度归纳了一下，更容易回答书生公司提出大概几十条的问题。这两二个问题第一个问题是软件工程实践者的观念问题，主要是中国的软件工程实践者，再一个软件工程方面自己的原理上是不是也有问题。
首先我们中国软件工程实践者自己的观念问题，我前一段时间曾经发表过一篇文章，说中国软件公司是没管理没技术，大家可能不赞成这个观点，实际上现实情况是这样。软件工程就两大因素，一个是软件开发技术本身，像怎么做需求，怎么做编码；再一个管理问题，再一个看软件开发管理上。因为软件开发主体基本上是软件公司，公司非常明显的特色就是分工特别清晰，分工问题是在230年就提到这个问题了，我们的软件公司在去年的时候才提出，这个结论是百分之百的正确，所以我们软件公司观念落后了230年了。今年就不同了，有专门的部门了。再一个软件管理水平的确管理很差，就是量化管理。在传统行业上，我们整个管理水平也是落后大概一百年左右的水平。因为在二十世纪初的时候，有人把一个建筑工人在弯身、拿砖头、抹灰这三个动作进行分解，然后再进行测量，最后实行了精确管理。我们国内一般企业都做不了这个管理，不用说软化公司了。所以软件公司整体开发水平并不是特别乐观的，这主要是观念问题，这方面大专院所也做的也不是特别理想。所以这方面可能从观念上这方面问题更研究。就是大家首先认为需求不可能做透，好不容易认清楚了做了“coding”。
所以整个软件开发从生命周期来讲，我们每个阶段都在犯错误，所以我个人理解，我们现在软件开发，做管理软件来说在于需求，需求关键在于哪儿？我个人认为对于用户本身业务的建设，这问题最大。所以这里面里头涉及到软件工程原理的问题，从我个人从软件来讲，我应该是后外行，我不是学软件出身的。
我大概在89年90年接触软件工程。我们当时学，老半天很不容易学懂，发现很难为用，我们从书上，从国内外书上看做需求分析的方法，太难在工程当中进行操作使用，所以最后我总结出来，可能是软件工程这门书上对如何做需求分析给教错了，做设计做其他的可能都没有问题。现在最大的在源头可能有问题，因为软件开发源头被污染了，下流再怎么治理可能一点意义都没有。所以我个人认为软件开发可能是一个赝品的概念，就照葫芦画瓢，这瓢就是软件，这葫芦就是应用领域，企业的管理模式，从根本上解决需求分析做的步骤，可能首先把依靠用户对领域的问题解决掉。这方面我们做的还是有一些成果的。我们提出来一个观点，全程一体化……就是对用户领域的分析，做需求分析，然后做概念设计再做总结设计，这样就会很顺畅。这样某种意义上消除了软件总体设计时间，包括详细设计时间也会消除到60到70%的时间。
这都是我个人的观点，一个感觉是本身中国软件工程的这些实践者观念有极大的问题，现在虽然这些问题在逐渐消灭掉，不过消灭也有很大问题，我大概在97年98年的时候，是我在跟软件公司在讲软件工程的重要性，到99年这些软件公司的总经理在给我讲软件工程给我们带来什么好处。我现在感到感觉最大的难处是如何说服具体开发人员认识软件工程的重要性，我现在做了很多培训工作，绝大部分都是总经理技术总监，包括部门经理来推动这件事情，唯一遇到一个案例就是员工做这件事情，总经理不愿意干，可能怕花钱，员工学会了会干别的事情。这是观念问题。至于你采取什么方法来做，这都是无所谓，主要是观念问题，大家认为软件开发能不能按流水线方式来做，这是最重要的。
提问：
全程建模我以前也用过，这有一个问题，这是一个普遍的问题。这是关于UML的，在你的软件里面我也用过UML，在使用的UML和面向对象的时候你是怎么实现的？UML在整个软件工程里面它起到什么作用，主要在设计上面的作用？
高展：
用我们一体化如何来体现UML方式，我们做了一些工作，就是我们把面向对象和结构化这两个做了一个综合，所以实际上我们兼容了大部分UML，包括它的顺序图，包括对象图，这是比较主要的，在我们这里都会得到体现。它的图形语言我感觉我们大概兼容了80%，就是一一对应的方式。
包括对象应用，跟结构化没有区别。这个结构化对象分解本身就是结构问题，就是对象组成关系本身就是结构问题，所以这两个完全没有区别。
提问：
因为我在用你的Playcase建模的时候，我发现还是以模块化为主，就是面向对象很难加进去，实际上我们软件公司要求软件编码的复用要求程度很高的，所以我觉得你在这方面有一些缺陷或者不足。
高展：
这应该看办法和工具，从办法学角度来讲我们是没问题的，如果你用纸和笔来肯定不会出现这个问题，可能我们工具在这方面有一些问题。
还有一点我稍微解释一下，关于模块和对象的问题，我个人的理解，软件工程所有的追求目标就是模块化，所以实现模块化的手段构建对象都大同小异，包括用结构来描述，这是我个人的观点。
周之英：
关于结构化，我想软件工程的最根本的问题，最主要的就是控制复杂性。你的规模大、特别复杂，整个问题很复杂，所以要分解。不管怎么样都是用一种分解的方法，就是把大的问题变成小的问题来分别考虑，考虑它们之间的关系。可以有不同的出发点。从这个意义上，对象之间的关系也是一种结构，只不过这种结构看你怎么理解。过去的结构化方法主要是指模块调用图这个结构。从更深层次，我觉得现在的结构化还解决不了一些复杂的问题。具体说起来，就是现在提出的非功能性需求，比方说性能问题，安全问题。这些问题为什么不能够解决？按照目前来看没办法分解到某个模块当中，就变成非常困难的问题。现在如果处理单纯功能分解，某种意义上不复杂。用现在的工具来开发一些管理软件或者什么，有时可以不复杂，因为编程语言很高级，很快就可以学会。需求功能划分后，大家一起完成。但是你考虑一致性、安全、再加上黑客攻不攻、性能要快，各式各样的问题加进去，就复杂了。所以要用各式各样办法去解决。
还有UML，我想它是很好地刻画了面向对象的东西，由OMG组织的一大群专家的工作成果，跟CMM也是差不多类似、这种规模。考虑了各方面提出的各种需求，比方说package包装的要求，各种部件之间接口的关系会产生什么样的需求。所以从本质上非常丰富，可以刻画很多东西，是很好的描述手段。但是描述手段并不等于你能够解决问题，因为你要建什么模型还是要靠人去解的。并不是说UML来了以后我就行了。它只是代表现在很多领域提出的问题，它怎么来表达。最基本的，还是表达对象的一些关系：相关关系，继承关系，这是最本质的东西，也就是UML最早的那点东西是最基本的。假如你要更丰富一些，比如大系统、控制很细，你就可以把很细节的东西去描述起来，描述细了也带来一个问题，你描述越清楚，信息量就越多，主要问题就不突出，可能带来了其他方面的问题。所以不要觉得很丰富就一定很好，你也得要根据你的问题重点去选择。
第二个就是，有了UML并不是说你可以睡觉，就可以解决问题了。根据问题的复杂性去建模，这是根本的。这是一个语言。
文章来源于领测软件测试网 https://www.ltesting.net/
