在處理代碼，我們自己寫代碼的時候，我不知道現在開發人員怎么寫，但是我們自己總結出來以后，我發現要寫一個文件時要先把它主干提出來，然后再給它填枝葉，那怎么寫呢？我們進行了成對編碼，先寫上面大括號，再寫下大括號，然后再加中間的，因為我們實際在以前做過的過程中發現很多代碼最后分配了很多內存，沒有地方去釋放它，最后機器自然被消耗，程序就死掉了，所以成對編碼我認為就比較重要。
小一點程序在環境里面就自己生成，把它拼湊成一塊就把它拿走，我認為這種方式不是很好，應該把它建立成BUILD，把所有文件放在一起寫成TXT文件，然后就輸入BUILD命令，它就能把你所有你要的東西相通的。
我們實際發現使用過程中用CVS做為代碼管理比較不錯，CVS能解決兩個人同時寫一個文件時怎么辦的問題，絕對不是說我在編這個文件別人不能編，在同一個文件里頭，也可以解決，兩個人可以在同一個文件里寫。這個CVS可以直接把這兩個部分合并成一個文件，解決同時編碼沖突的問題。
還有一些開發理念的習慣，我們覺得比如像代碼在教科書里面比較多的，還有實驗性代碼比較多的與assert有關聯，我們實際使用中不要用這個東西，因為這個最后推出產品的時候，有兩種方法，一種可能根本把這一行去掉，另外一種運行時會出錯，彈出一個對話框，如果你懷疑這個地方有問題，就應該有一個相應的處理方法在這個地方，就不要使用assert來取代它。
我們早期版本用過一些MFC的程序，后來我們發現錯誤很多，現在就不用了，MFC可以產生很多廢碼，看起來效率很快，但是問題很多。我們寧愿慢一點，但是要很多東西都可靠，這些代碼可運行性很高。在代碼實際中分層次編碼是非常重要的，在每個行數前面一定要有一個統一格式的注釋，你代碼里面沒一個注釋也是很重要，但是每個函數前面有一個比較完整的注釋，別人看這個代碼時就像這個東西是我寫的。這樣使得這個團隊有一個比較好的協作基礎。
主持人潘加宇：
謝謝梁總的精采發言。
提問：
我想請問一下梁總對代碼的重構有什么看法沒有？它是指一開始的時候就比較快，還是比較規范的很快寫出一些代碼來，不考慮以后的需求變化，等到以后需求發生變化時再去給它想辦法重整這個代碼，在它不影響它的功能的情況下？
梁肇新：
我們使用動態庫設計這些東西，在設計整個軟件的時候，我們也有一些開發人員不了解這個開發性，代碼寫得比較封閉，一個程序用一個大類來實現，最后給這個東西添加功能時非常困難，所以我們就要求實際開發過程中盡量把所有東西能提出來放在動態庫，以免將來改變時的麻煩，再不需要對動態庫進行改變，你只要在需要改變的地方進行測試就可以了。
提問：
您以前是個很成功的程序員了，成立自己公司以后從開發第一線退出來，從第一線到開發人員這需要在思想上有什么樣的轉型。您對軟件工程方面是什么見解？感覺到自己公司在軟件工程上需要有什么幫助？梁肇新：
我們公司現在規模還比較小，我們最困惑的是2000年的時候，當時我們團隊剛剛建立起來，為什么我們會建立代碼規范化，也是因為實際中代碼混亂，所以我們在實踐中建立起來。年底的時候我們聽說CMM，我們去請一些老師過來實際培訓了一下，使我們視野開拓了一些，但是實際上還是按照自己實際需求。朝這個方向做是很有必要的，但是做的過程中我們是很謹慎的，不會把原來東西打亂了，我們主要目的是使我們開發更加可管一些，更加規范化一些。我自己一直定位為程序員，就是開發人員，而且我本身就喜歡編程，我覺得編程就是一種娛樂，而不是一種工作，我一直在做實際編碼工作，所謂代碼規范也是我實際使用中發現它有很多好處，然后再總結出來的。
提問：
您怎么處理編程的身份和總經理身份的？
梁肇新：
像我們公司技術方面我主要負責這方面，還有產品，如果要決定什么樣的東西，比如2000年網絡很火的時候，市場人員要求我們是不是也搞網站搞風險投資，我覺得這跟我們定位于軟件企業根本不同，這兩個相當于跨行的，所以這東西不是我們要做的，所以最終我們還沒有做這方面的工作。我主要是做技術，在技術的前瞻性，看哪項技術能運用到哪些產品里面去，目前最新技術是什么，這些技術我們拿過來以后，我們能做什么樣的產品，我主要考慮這些東西。而實際中我會做一些比較先進的底層的技術，做好后提供給實際項目中使用。
提問：
您是作為程序高手或者程序英雄，我非常好奇，如果您總是編程，您不可能管理好一個團隊，你可能抽出時間進行管理，您怎樣處理編程和管理這兩件事情？
梁肇新：
管理不是我的長項，我們工作的日常管理和其他管理有其他人做，我就相當于技術骨干的角色。
提問：
我問一個問題。我接觸了很多出版界的朋友，我發現國外軟件工程軟件管理在知識資源上非常豐富，但是國內比較少。那我想問一下，大家也是在實踐中去帶團隊，也要鼓勵自己團隊中成員去成長。從知識角度來說，就看他們有什么樣的素質，我希望嘉賓從個人體會來說，如果您希望您團隊成長的話，從知識角度怎么樣來配合？
周之英：
我想這個問題從我們國家來說，應該從教育和工業界共同努力來解決這個問題，某種意義上，國際上包括美國也在重新認識這個問題。從總體來說，軟件工程是超越一個具體項目，但是很多人現在并沒有把軟件工程中間那些思想本質的東西掌握到，而是把它當成很簡單的理解：一個規范，我照貓畫虎就能做了。
我教軟件工程課也碰到這樣的矛盾。有人總說周老師你教的東西太抽象了，我也學不了那么多，只要給我一個樣本就行；我要做可行性報告，有沒有東西給我抄一份。這很典型。當然這個情況可能特殊點，但是對大多數人也一些影響，程度不同而已，就沒有把它作為很重要的、發展軟件工業的基礎來看。軟件工程里面有不同的層次。
國外這方面開展研究很多。我們國家一開始就有一個誤區，就是從80年代初開始搞軟件工程的時候，認為軟件工程一個是規范，第二個是中國開發出自己的工具來就行了，看成非常死的東西�？紤]一個規范，好像什么東西也不需要，就可以照著做、就能解決問題了。第二個誤區，只要開發出一個東西，然后這個東西就能解決一切的問題。實際發展的二十年來，不斷地探索，人做軟件的一些規律性的東西，包括技術的東西。里面有各種不同的層次，包括編碼，需求分析，開發，發展新技術，有很多層次。我覺得今后教育方面有很多工作，比如現在的大學教育中，就像編程問題，沒有一個教科書里寫工業產品的編程是怎么編的，學的編程課程是學語言，就把語言弄懂了，這是面向對象的語言，這是結構化的語言，是學語言而不是學做工業化的東西。
其他層次的都是需要很深層次。我有時候也很困惑。有人跟我說：我對軟件一點不懂，我現在要搞一個軟件項目，你告訴我我怎么去管。我想如果要建造一個房子，沒有一個人會對建筑系的教授說：我明天要設計摩天大樓了，我對建筑什么也沒學過，請你告訴我用什么辦法，我明天投標去。但是你看軟件就有這樣的狀況。當然軟件也有它方便的地方，現在技術使一些軟件很容易編，但是你要做到不同層次的話，就有很多深層次的問題。
所以我覺得一個從工業界怎么不斷總結，一個從教育界怎么能夠改變過去僅關心計算機科學技術，也去關心軟件工程的問題。以后可能對我們國家的長遠發展會有一個比較深刻的改變。
主持人潘加宇：
今天到現場的還有一位，大家知道國內軟件工具有一個叫做“PLAYCASE”，這是一名叫高展的先生基本上是他一個人開發出來的，因為國內軟件工程大家是談的多，做的少，軟件工具方面像青鳥開發了一整套，但是一般公司一般人都見不著，不知道用在什么地方，但是像高展先生，他一個人踏踏實實地把“PLAYCASE”寫出來了。下面請高展先生說怎么把“PLAYCASE”寫出來的。
高展：
書生公司王東臨先生提了一堆問題，我從兩個角度歸納了一下，更容易回答書生公司提出大概幾十條的問題。這兩二個問題第一個問題是軟件工程實踐者的觀念問題，主要是中國的軟件工程實踐者，再一個軟件工程方面自己的原理上是不是也有問題。
首先我們中國軟件工程實踐者自己的觀念問題，我前一段時間曾經發表過一篇文章，說中國軟件公司是沒管理沒技術，大家可能不贊成這個觀點，實際上現實情況是這樣。軟件工程就兩大因素，一個是軟件開發技術本身，像怎么做需求，怎么做編碼；再一個管理問題，再一個看軟件開發管理上。因為軟件開發主體基本上是軟件公司，公司非常明顯的特色就是分工特別清晰，分工問題是在230年就提到這個問題了，我們的軟件公司在去年的時候才提出，這個結論是百分之百的正確，所以我們軟件公司觀念落后了230年了。今年就不同了，有專門的部門了。再一個軟件管理水平的確管理很差，就是量化管理。在傳統行業上，我們整個管理水平也是落后大概一百年左右的水平。因為在二十世紀初的時候，有人把一個建筑工人在彎身、拿磚頭、抹灰這三個動作進行分解，然后再進行測量，最后實行了精確管理。我們國內一般企業都做不了這個管理，不用說軟化公司了。所以軟件公司整體開發水平并不是特別樂觀的，這主要是觀念問題，這方面大專院所也做的也不是特別理想。所以這方面可能從觀念上這方面問題更研究。就是大家首先認為需求不可能做透，好不容易認清楚了做了“coding”。
所以整個軟件開發從生命周期來講，我們每個階段都在犯錯誤，所以我個人理解，我們現在軟件開發，做管理軟件來說在于需求，需求關鍵在于哪兒？我個人認為對于用戶本身業務的建設，這問題最大。所以這里面里頭涉及到軟件工程原理的問題，從我個人從軟件來講，我應該是后外行，我不是學軟件出身的。
我大概在89年90年接觸軟件工程。我們當時學，老半天很不容易學懂，發現很難為用，我們從書上，從國內外書上看做需求分析的方法，太難在工程當中進行操作使用，所以最后我總結出來，可能是軟件工程這門書上對如何做需求分析給教錯了，做設計做其他的可能都沒有問題�，F在最大的在源頭可能有問題，因為軟件開發源頭被污染了，下流再怎么治理可能一點意義都沒有。所以我個人認為軟件開發可能是一個贗品的概念，就照葫蘆畫瓢，這瓢就是軟件，這葫蘆就是應用領域，企業的管理模式，從根本上解決需求分析做的步驟，可能首先把依靠用戶對領域的問題解決掉。這方面我們做的還是有一些成果的。我們提出來一個觀點，全程一體化……就是對用戶領域的分析，做需求分析，然后做概念設計再做總結設計，這樣就會很順暢。這樣某種意義上消除了軟件總體設計時間，包括詳細設計時間也會消除到60到70%的時間。
這都是我個人的觀點，一個感覺是本身中國軟件工程的這些實踐者觀念有極大的問題，現在雖然這些問題在逐漸消滅掉，不過消滅也有很大問題，我大概在97年98年的時候，是我在跟軟件公司在講軟件工程的重要性，到99年這些軟件公司的總經理在給我講軟件工程給我們帶來什么好處。我現在感到感覺最大的難處是如何說服具體開發人員認識軟件工程的重要性，我現在做了很多培訓工作，絕大部分都是總經理技術總監，包括部門經理來推動這件事情，唯一遇到一個案例就是員工做這件事情，總經理不愿意干，可能怕花錢，員工學會了會干別的事情。這是觀念問題。至于你采取什么方法來做，這都是無所謂，主要是觀念問題，大家認為軟件開發能不能按流水線方式來做，這是最重要的。
提問：
全程建模我以前也用過，這有一個問題，這是一個普遍的問題。這是關于UML的，在你的軟件里面我也用過UML，在使用的UML和面向對象的時候你是怎么實現的？UML在整個軟件工程里面它起到什么作用，主要在設計上面的作用？
高展：
用我們一體化如何來體現UML方式，我們做了一些工作，就是我們把面向對象和結構化這兩個做了一個綜合，所以實際上我們兼容了大部分UML，包括它的順序圖，包括對象圖，這是比較主要的，在我們這里都會得到體現。它的圖形語言我感覺我們大概兼容了80%，就是一一對應的方式。
包括對象應用，跟結構化沒有區別。這個結構化對象分解本身就是結構問題，就是對象組成關系本身就是結構問題，所以這兩個完全沒有區別。
提問：
因為我在用你的Playcase建模的時候，我發現還是以模塊化為主，就是面向對象很難加進去，實際上我們軟件公司要求軟件編碼的復用要求程度很高的，所以我覺得你在這方面有一些缺陷或者不足。
高展：
這應該看辦法和工具，從辦法學角度來講我們是沒問題的，如果你用紙和筆來肯定不會出現這個問題，可能我們工具在這方面有一些問題。
還有一點我稍微解釋一下，關于模塊和對象的問題，我個人的理解，軟件工程所有的追求目標就是模塊化，所以實現模塊化的手段構建對象都大同小異，包括用結構來描述，這是我個人的觀點。
周之英：
關于結構化，我想軟件工程的最根本的問題，最主要的就是控制復雜性。你的規模大、特別復雜，整個問題很復雜，所以要分解。不管怎么樣都是用一種分解的方法，就是把大的問題變成小的問題來分別考慮，考慮它們之間的關系�？梢杂胁煌某霭l點。從這個意義上，對象之間的關系也是一種結構，只不過這種結構看你怎么理解。過去的結構化方法主要是指模塊調用圖這個結構。從更深層次，我覺得現在的結構化還解決不了一些復雜的問題。具體說起來，就是現在提出的非功能性需求，比方說性能問題，安全問題。這些問題為什么不能夠解決？按照目前來看沒辦法分解到某個模塊當中，就變成非常困難的問題�，F在如果處理單純功能分解，某種意義上不復雜。用現在的工具來開發一些管理軟件或者什么，有時可以不復雜，因為編程語言很高級，很快就可以學會。需求功能劃分后，大家一起完成。但是你考慮一致性、安全、再加上黑客攻不攻、性能要快，各式各樣的問題加進去，就復雜了。所以要用各式各樣辦法去解決。
還有UML，我想它是很好地刻畫了面向對象的東西，由OMG組織的一大群專家的工作成果，跟CMM也是差不多類似、這種規模�？紤]了各方面提出的各種需求，比方說package包裝的要求，各種部件之間接口的關系會產生什么樣的需求。所以從本質上非常豐富，可以刻畫很多東西，是很好的描述手段。但是描述手段并不等于你能夠解決問題，因為你要建什么模型還是要靠人去解的。并不是說UML來了以后我就行了。它只是代表現在很多領域提出的問題，它怎么來表達。最基本的，還是表達對象的一些關系：相關關系，繼承關系，這是最本質的東西，也就是UML最早的那點東西是最基本的。假如你要更豐富一些，比如大系統、控制很細，你就可以把很細節的東西去描述起來，描述細了也帶來一個問題，你描述越清楚，信息量就越多，主要問題就不突出，可能帶來了其他方面的問題。所以不要覺得很豐富就一定很好，你也得要根據你的問題重點去選擇。
第二個就是，有了UML并不是說你可以睡覺，就可以解決問題了。根據問題的復雜性去建模，這是根本的。這是一個語言。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
