論設計與編程的關系

2019-11-17 04:42:17

字體：大中小

來源：轉載

供稿：網友

　　在IT領域從業(yè)六年中，大大小小的項目已擔負了十幾個。從項目行業(yè)上看，復雜的有大型ERP系統、銀行貸款系統，相對簡單的有OA系統、人力資源系統。從性質上看，既有解決實際需求的應用系統，也有屬于技術攻關的科研項目。從這些項目的開發(fā)、治理中，有很多的感想，我認為是非常寶貴的經驗。比如如何看待設計與編程，如何用好非凡程序員等問題。在項目治理上采取的方式是否是正確的、最佳的，項目開發(fā)成本有幾倍、幾十倍的差別。

　　在一個系統的開發(fā)過程中，作為項目治理者，經常要碰到一個要仔細衡量又極難把握的問題：設計與編程究竟各要花多少比例的時間？碰到這樣的問題有時是由于項目組的成員水平參差不齊，有很多程序員只能開發(fā)簡單的定義明確的程序，而不能就一個問題進行解答性的設計，這使得項目治理者經常考慮安排專門的人來進行設計；有時是由于項目治理者主觀就認為設計與編程是相互獨立的工作，理應該分配不同的人來承擔。做設計的認為設計工作要占60%以上的工作量，是主要工作，做編程的認為編程工作要占80%以上的工作量，才是真正主要的工作。到底怎樣的比例才是公平的呢？我們很難作出回答。

　　軟件生存期在大部分項目中可以概括為如圖的形式：

　　論設計與編程的關系（圖二）

　　毫無疑問，開發(fā)過程的成本是項目的核心成本，其成功與否實際就代表了項目的成功與否。開發(fā)過程中最主要的工作就是設計與編程。

　　怎樣確定設計與編程的工作量

　　確定的可衡量的工作量是文字，設計成果是通過文檔表示的，程序是由代碼組成的，兩者的共同點就是由文字來表示成果。一個系統，設計文擋比如是10萬字，編寫的程序代碼是90萬字（不包含通過開發(fā)工具生成的代碼），則可明確衡量的工作量之比是1：9。肯定有很多人口頭上反對這種衡量方式，認為這是機械的、呆板的。假如只計算最終通過確認的設計文檔、通過測試驗收的程序代碼，會發(fā)現這種方式經常是最客觀地反映了項目組各成員的工作業(yè)績。

　　做設計要思考，做編程同樣需要思考，而且還要反復調試，可以說寫同樣多的文字，編程需要的時間決不比設計需要的時間少。公司招聘設計人員與招聘編程人員花的代價是不相同的，作為設計人員自然要求具有設計的水平和能力，作為編程人員同樣要求具有編程的技術和能力。所以兩者不能說自己的工作性質不同，寫同樣的文字需要的時間不同。否則，企業(yè)就太虧了。

　　從經驗看來，在一個項目中，假如設計與編程人員都努力工作，沒有松懈的時間的話，設計人員與編程人員的比例大概為1：5，設計人員與編程人員的個人工資比例大概是3：1，項目中工作時間之比大概是1：5。可計算設計與編程的時間成本之比為：

　　1*3*1：5*1*5=3：25約為1：8的比例

　　這個比例應該是比較公平符合實際的。而很多企業(yè)的軟件項目盲目夸大設計工作的比重，如人員比例安排為1：3，工資比例為3：1，工作時間比例為2：1，兩者最終成本之比為：

　　1*3*2：3*1*1=6：3=2：1

　　這就體現了不少人認為的設計占絕大比重的觀點。而實際上，按這種比例帶來的結果是，設計人員輕松得要命，但表現出來也很累，因為他們要不斷地催編程人員的進度、等編程人員的結果。而編程人員卻累得要命，拼命加班加點，還是很難應付過來，并且到頭來還老挨設計人員的教訓。

　　設計所需的工作時間實際是很少的，因為它主要在于設計者的經驗、文字表述，而不需要調試。一個大型的ERP項目，假如設計者得其人，一人即夠，而編程卻需要上百人--真正的花時間的工作是編程與調試。為什么一些企業(yè)有那么多IT失敗的項目，一個原因就是他們盲目的看重了設計的比重，在設計上投入了總預算的60%以上的成本，結果發(fā)現真正的主體工作是編程，到那時才發(fā)現剩下的預算成本已遠遠不夠。邊設計邊編程是提高效率的捷徑

　　在設計與編程上，用得上一句老話：說一千句，不如做一件。實際上設計與編程是很難分開獨立進行的，首先光做設計而不及早進入編程，項目極可能流產。邊設計邊編程，甚至以編程催動設計，是使項目成功的捷徑。

因為只有編程了，才真正明白哪些內容需要設計，哪些是簡單的。實際中我們也經常發(fā)現，花了好幾天工夫設計了一個方案，結果編程者根本不需要理會你的設計，他只要幾分鐘時間就做好了。

　　在一個大型信息系統中，項目經理安排了三個人花了四天時間做一個客戶可定制的菜單系統的設計，同時安排一個程序員鉆研相關編程上的實現方法，四天后，設計人員拿出了設計，但總還感到不放心，當他們去和程序員交流時，發(fā)現程序員已經把菜單系統做好了，實際的功能還超過了他們的設計，這讓三名設計者無地自容。假如項目經理據此認為編程工作簡單，那必定又大錯特錯。設計，需要與當時的技術，程序員的水平與經驗結合考慮，大部分情況下需要在編程中摸索，才能決定究竟是否需要獨立設計，究竟有多少工作量。

　　這樣說，并不是說設計就不值得一做了，設計仍然是相當重要的，非凡對于延續(xù)性的開發(fā)項目。但我們要看到，有時候，效率、速度是高于一切的，而且，在我們的IT隊伍中，有不少程序高手，他們的確能制造奇跡。

　　一個朋友告訴我，當他在學校的時候，有一個機會參加了國家重點實驗室計算機語音合成技術的研究。在他加入該課題時，課題組已有不少人研究超過一年以上，其中有博士和碩士。他們將設計看得很重，哪怕是漢字音節(jié)的錄音，都幾經計劃，并錄了好多次。在給他分配任務時，根本沒認為他可以為研究項目提供什么幫助，只是泛泛的要他看看書、嘗試做一些小程序。設計固然非常重要，但過分強調，就成了研究人員，非凡是“主要設計人員”狀態(tài)松懈的借口，他們可以一周兩周漫無邊際地翻閱書籍，可以一月兩月就某個“重要問題”進行“深入地、細致地”探討。我們不能指責他們探討交流不應該，但在那方面花費太多的時間已使得工作效率極其低下，課題進展非常緩慢。朋友參與課題研究后，沒有象他們那樣先設計然后再編程，而是一開始就編程，有任何一點想法就立即通過程序實現。因為有了想法后假如不實現，就不會有進一步的思考，而實現了則可以非常明確的對前一想法進行修正或進一步往前思考。在研究開發(fā)過程中，他也很少與同組人員進行討論，因為一個明顯的理由告訴他，對于不太復雜的問題，有討論的十分之一時間，自己也能通過程序試驗出來了。結果，他只花了三個月時間，就將語音合成的主要技術問題如音節(jié)/音素合成、詞組處理、多音字處理、語音數據壓縮、句式處理都解決了，并開發(fā)出了一個簡單的但具備完整功能的語音合成程序。這在其他人看來是不可思議的。

　　另一個例子是，一個對自動控制完全外行的IT工程師，參與一個大型的自動控制項目。該項目屬于國家重點工程。在那位工程師加入項目組時，該項目已開始半年多了，項目組原成員都是名牌學校自動控制專業(yè)的，都是碩士以上的學歷。他們按部就班，安排了先分析后設計再開發(fā)的步驟。分析是一種比較虛或籠統的東西，哪怕在一個月的計劃中已花掉二十九天沒有成效也能在最后一天拼湊出一份分析說明書交差。設計就需要一定實力了。兩個月的計劃時間過去了，設計沒有出來；再增加兩個月，設計仍然沒有出來；又拖了一個月，設計仍然沒有解決根本的問題，項目組處于失望的狀態(tài)，成員都已灰心喪氣，這期間編程人員也隨著浪費了大量的時間。那位工程師進入后，先預備花兩周時間學習自動控制方面的知識和PLC的編程。第三周開始看需求。他是一邊看一邊編一些小程序來嘗試的，結果就在第四面拿出了一份完整的設計方案，并在隨后的兩個月里全部實現了系統。他并非神奇，而是主要得力于他的編程經驗和對程序控制方面的深入鉆研。對于編程并不精通的人，假如讓他們做設計，既是對程序員的欺侮，也是對公司資源不負責任的浪費。

　　優(yōu)秀的設計者來自優(yōu)秀的程序員

　　一個真正的設計者是從出色的程序員中產生的，一個好的項目經理也是從優(yōu)秀的程序員中產生的。

　　認為只要學歷高、名氣大就可以招來做項目設計或項目治理的想法，大部分情況下都會導致失敗。--除非公司的錢多到沒處花，或者公司需要花哨的包裝，才可以那樣做。

　　一位已到日本做了四年IT的朋友告訴我，他所在的公司接到了一個保險公司的大單，約有兩千萬美元。他們的軟件開發(fā)過程是非常正規(guī)的、工程化的，軟件的分析、設計已做好，所花的成本約為五百萬美元，公司計劃開發(fā)工作交給中國的企業(yè)做，預算為三百萬美元。項目的總時間約三年。他告訴我，他們公司很多項目確實都是這樣做的；但他也告訴我，那樣的項目假如是他原來在國內的企業(yè)接下來做的話，總的開發(fā)成本（包括分析、設計、開發(fā)）不會超過一百萬人民幣，總的項目時間不會超過一年。他們分析設計花的成本大，是因為里面做的“文章”太多了，在中國的IT企業(yè)中，那些工作幾乎會全部被省略或者壓縮到開發(fā)工作中。我們不要批評某些國內的IT企業(yè)開發(fā)過程不規(guī)范，要知道中國的IT技術曾經落后于國外發(fā)達國家?guī)资辏覀円s上去，就不能采用國外常規(guī)的方法，不能和他們一樣的效率，我們要以他們幾倍、幾十倍效率的方法趕上去。正是我們國內一些IT企業(yè)，非凡是一些中小企業(yè)采用了高效率的做法，才使我們與世界的差距迅速縮小。

　　我們需要高效率，IT需要高效率，這是沒有錯的，只要在我們追求高效率的時候，保證了軟件質量。程序精英對項目成敗至關重要

　　在我治理的一個銀行項目中，很明顯的顯示了程序精英對項目的非凡作用。

XX銀行為了提高新時代下的競爭力，要開發(fā)一套整合了各種貸款業(yè)務的貸款治理系統，因為系統的復雜性，他們先請國外公司做分析設計，花了大量的時間，花了一千萬美元，得到了一份厚厚的系統需求與設計說明書，但那家國外公司不肯再做開發(fā)工作，該銀行在國內找了好久也找不到愿意承擔該項目開發(fā)任務的公司。他們最后放棄了該設計方案，重新在國內尋找項目的設計與開發(fā)者，預備先做一個簡單系統，然后步步演進，逐步達到期望的目標。最后確定由我所在的公司承擔該項目，項目總金額只有不到二百萬人民幣。接手項目后，我組建了一個只有四個程序員組成的項目組，但四人中有兩個是很優(yōu)秀的程序員。從分析，到概要設計，我擔當了，花了兩周時間。在客戶的參與下，我讓四個程序員各自獨立地擔當模塊任務，包括具體設計、編程、測試及與客戶的交流。結果，項目的進展相當快，兩個優(yōu)秀的程序員，他們雖然一開始沒寫什么設計文檔，但他們與客戶直接進行交流，充分地理解了客戶的意圖，他們幾乎天天都能提交一個模塊。只花了四個月的時間，基本系統出來了，又花了三個月的時間，系統在該銀行的一個試點分行全面啟用了。可從一些數字來看系統的開發(fā)成果：

　　數據庫存儲過程--1253個

　　操作界面數--1303個

　　報表數--320個

　　邏輯功能項數--278個

　　客戶的反應是：沒想到有這樣的速度，也沒想到系統能做到這種深度--已經達到了我們的最終期望。他們認為系統基本上已經一步到位，原來花一千萬美元還只買了個設計，現在只花了不到兩百萬人民幣，連設計帶系統全部出來了。這種效率和成本是無法比擬的。

　　項目之所以能獲得如此成功，非常要害的因素是項目組有兩個非常優(yōu)秀的程序員，而且充分發(fā)揮了他們的潛力。在七個月的工作中，他們幾乎沒有休過假，日以繼夜是常事；他們雖然以前沒做過銀行系統，但他們對銀行系統有很強烈的愛好，把成功和超越當作對他們聰明的挑戰(zhàn)；他們實際承擔了項目總開發(fā)工作量的80%多。他們是當之無愧的軟件精英。

　　在一個新技術的起步和初始發(fā)展階段，精英人才起著決定性的作用；在一個高難度高復雜的項目中，精英程序員同樣起著決定性的作用；即使在大眾化的階段，精英也在各種場合下起著至關重要的作用。在當前我們的IT產業(yè)仍處于追趕狀態(tài)的時代，我們需要精英人才。在IT行業(yè)，我們已經有了一批精英人才。在企業(yè)中，在項目開發(fā)過程中，重視精英，采取方式讓精英人才充分發(fā)揮作用，效率可以成幾十倍、幾百倍的提高。

　　在這個銀行系統的開發(fā)中，我并沒有要求程序員一定要先拿出具體設計然后才能動手開發(fā)。因為設計工作已蘊涵在他們的編程思考中，也許設計方案在他們的頭腦中會變化五次五十次，他們通過編程測試可以在幾分鐘幾小時內確定可行的和最佳的方案。而一定要他們先寫出來的話，寫出一次變化的方案恐怕就得要一兩天的時間，這又怎么能保證高效率、高進度呢。

　　一種好的項目人員組織方式是：確定項目組的相對精英，讓他們作為主程序員，設計、開發(fā)一手負責，水平相對較低的程序員機動調配或劃撥給主程序員安排。不要安排獨立的設計者，只設計不開發(fā)的設計者最終會發(fā)現那是浪費（他們在項目過程中同樣會讓治理者覺得他們是很努力甚至很累的和不可缺少的，而實際上他們的工作對項目進展情況在大多數情況下是可有可無的）。

　　這樣的組織并非表達一種設計沒有必要的觀點。只是表達設計工作的大部分是與編程交織在一起的，雖然詞語上我們將軟件開發(fā)過程劃分為：設計、編程、測試，但實際的人員組織上并不需要明確地進行對應。

上一篇：談談軟件開發(fā)中的調研對象與被調研對象

下一篇：軟件的架構與設計模式之什么是架構