程式員接私活經驗

（一）項目确立

一年前，CSDN的外包頻道，一家貿易公司尋求開發業務系統。我注意到這家公司和我正好在一個城市，索性就跟了一帖，寫了點簡要的個人開發情況，當然最重要的是附上了自己的手機号碼（當時CSDN外包頻道還不限制這個資訊的）。第二天就接到那家公司總經理的電話，這讓我多少有點意外，電話中，雙方客套兩句後，約定好周末面談。

和以往面試一樣，我帶上個筆記本（上面有以往開發的項目示範版）按照約定好的時間，準時去洽談。地點是在對方的辦公室，一進會客室，給我第一感覺整齊、清新、優雅、綠色；窗外則是甯靜的半島和微瀾的海浪，心情頓時感覺非常暢快。

電話中那位非常紳士的總經理，年紀大概45歲左右，我們的談話直奔主題。我先簡單介紹了一下自己的情況（工作和開發經曆），用筆記本示範自己以前開發過的兩個類似項目情況，他則不時地提幾個關心的問題。然後，他簡單地将自己公司的需求告訴我，并把現行的系統的主要功能示範給我看了看。

整個談話過程中，我印象最深刻的是他最後時刻說的話：“我看了你以前開發的系統示範，認為你完全有能力開發我們的系統；我也不打算再尋找其他人來面試，因為我的時間不允許我這樣做。你如果覺得剛才我們談到需求内容和開發價格都合适，那麼我們就此開始合作。”

我是個程式員，他是個商人，我們的合作就此開始。 

正文：（二）需求确定1

有了第一次的面談，我對這家公司的整體印象不錯。說起來，我以前去過不少公司（自己工作過的公司或談項目去過的公司），尤其是從事貿易的公司，還是第一次見到辦公室這樣讓人感覺如此舒服的。

簡單說一下我需要開發的系統，其實并不複雜，就是一個典型的貿易系統，主要功能是管理公司的産品、客戶資訊，然後給客戶報價、生成合同、給廠家下生産單等等。當然，這每一個子產品中都會有很多特定的需求，例如，産品的價格組成，當某些價格組成發生變化時，系統需要自動更新到所有可能産生影響的部分去。

（那位非常紳士的總經理，為了叙事友善，給他取個名字吧，就叫Gentleman吧）

Gentleman把他們現在使用的系統，發了一份給我，在我看來這個系統簡直就是一個學生的實習作業。無論從系統的性能上，還是操作的界面上，邏輯的條理性上，都存在很多的問題。但就是這樣的系統，Gentleman居然使用了近7年的時間，這讓我感到很驚訝，甚至于難以了解。而Gentleman經常在需求的溝通過程中，提到他們原先的系統如何如何實作，我心中總是會非常不舒服，覺得拿這樣原始而粗糙的系統來與即将開發的系統相提并論，我認為是對我的輕視或者說低估。

對了，需求中有個重要的部分，那就是資料同步。因為Gentleman長期定居在國外，每年隻回國兩次，每次大概一個半月，平時他都是通過IM和Email來管理他的公司。

正文：（三）需求确定2

我用2天時間，把他們原先的老系統的所有功能，都'學習'了一遍，在自己大腦中已經有了一個比較清晰的輪廓。其實行業軟體，大家隻要熟悉其業務流程，就會感覺非常簡單。因為從程式實作上來看，主要工作就是資料庫的表結構設計，以及相關前台界面的操作合理性。

Gentleman在他回CA國之前，約我再見一次面，并給我發來一份他自己整理的需求文檔（20頁左右）。因為我白天要正常上班，而他的返程機票已經訂好，是以我們隻能約定好晚上見面。這次，他約我的地點是一家五星級酒店的自助餐廳。用他的話說，他不知道該去哪合适，隻知道這個地方吃飯還比較自在，他喜歡這的環境。這家自助餐廳給我留下的印象，就是用餐的外國人比中國人多，當然Gentleman給我的感覺也有點像個外國人，隻是和我說話的時候還是用中文而已。

我們邊吃邊談系統的需求，他把自己需求檔案中描述的内容，再給我講述一遍。而且講得非常仔細，生怕我有不明白地方。其實他說的大部分内容，對于一個有8年開發經驗的程式員來說，完全沒必說得這麼細緻。當然，我也不打斷他的思路，隻是默默地聽着，因為我不想讓他以為我很狂妄。我看着他認真的神情，思想反倒有點走神，腦子裡尋思這一個問題：我什麼時候能像他這樣工作和生活？

就系統的需求，我們聊了大概有3-4個小時，從自助餐廳到酒店大廳的會客區。Gentleman想把他所有能想到的想法和問題都告訴我，因為他明天就要飛回CA國，這半年内，再也沒有這樣好的溝通機會了，畢竟Email中的描述隻能停留在字面上。

那夜，我回去後，腦子裡并沒想任何系統需求，隻是一直在想：我什麼時候能像他這樣工作和生活？

正文：（四）系統整體設計1

需求大緻上了解以後，我開始着手系統的整體設計工作。

首先，從應用角度上來看，這個系統是準備在一家30人左右的公司運作，而且Gentleman需要在自己的筆記本上安裝一套系統，并與國内公司這邊進行資料同步。另外，他們公司在每年的春秋廣交會期間，都會帶産品去參展，期間有5-6台筆記本需要使用系統，以便随時給客戶報價。是以說，各個資料庫之間的同步，是這個系統的一個非常重要内容。

其次，我開發系統有個習慣，即在完成系統功能的同時，比較注重界面的設計。這個習慣，也讓我在這個系統上多花了30-40%的時間（Gentleman對于界面并未做任何要求）。但我認為是必要的，我們程式員在寫程式的時候，都使用IDE工具，我個人的感覺，如果這個開發工具非常醜陋或看起來别扭，在開發系統的時候，是會非常不舒服的。同理，業務人員每天都是使用這套系統來工作，如果系統的界面非常差，操作起來很别扭，那工作簡直就是遭罪。

還有，系統的整體架構。我沒有采用以前開發過度系統架構，雖然這樣能節省我很多時間。但我仔細考慮了一下，由于這個系統對于時間要求并不緊迫，而我也想積累更多的系統架構，是以最終決定在原架構的基礎上做許多更新改良，以便更試用于這套系統。

（不少程式員開發系統，是一套架構多處使用。我認為如果時間不是很緊張的情況下，完全可以設計更好的方案。這樣在接下一單項目的時候，就可以有更多更好的系統示範給客戶看）

系統的功能就像人的五髒六腑，界面則是人的長相和外衣；長相雖然不影響身體健康，但絕對影響找對象，呵呵，是以說，界面是個不大不小的問題。

正文：（五）系統整體設計2

Gentleman回CA國後的一個月内，他仍然每周都給我發過來最新的系統需求，其中有專題性質的（例如：某處的價格算法，以及價格調整的系列影響），也有系統整體性的需求調整。我則有條不紊地地分析着每份需求檔案，從這些需求檔案中，我能感覺到Gentleman對這個系統的期望值很高，因為他不僅是在提需求，甚至是在做程式設計工作，哪些部分需要加按鈕，這些按鈕完成什麼功能，具體某個字段是下拉清單顯示，還是彈出視窗等等。

在此期間，我并未急于做實質性的業務程式開發工作。我從Gentleman的衆多需求檔案，逐漸整理和設計出系統的幾個核心表結構，在這幾個核心表結構還沒有相對穩定之前，我是不會寫一行業務程式代碼的，這是原則。當然，我的程式架構的改進工作是一直在同步進行的，因為程式架構部分和業務程式部分幾乎是平行的，隻需要在架構中考慮到幾處重要的StatusBar和ProgressBar，以及系統的整體顯示風格即可。

（即便如此，在後續的開發過程中，還是出現了需要調整核心表結構的情況，當然這是後話，暫且不提）

随着核心表結構的設計過程，我的腦海中正在一步步地形成整套系統的資料脈絡（主業務資料流和輔助資料流）。與此同時，Gentleman經常在發送新需求檔案的同時，詢問系統的進度情況。而此時的系統進度隻是在我腦海中，在一份資料庫表結構檔案中（我沒去寫非常詳盡的設計資料，因為一個人的系統沒必要把過多的時間放在文檔上，文檔工作是對于協同開發小組比較重要的），我無法讓Gentleman感覺進度的情況。我隻是告訴他正在做系統的設計工作，我也沒發送改進好的程式架構給他看，我認為把一個半成品給對方看，還不如不給對方看。

Gentleman很了解我的工作，雖然我的目前的工作彙報隻是停留在口頭上。噢，又忘交代了，Gentleman在成為商人以前是學計算機專業的，不過，我至今還不知道他是否當過程式員。

中間插一讨論篇《程式風格》，本篇與這個項目開發有些關系，但并不納入到正文中。 

歡迎各位程式開發高手積極讨論一下。

讨論篇1：程式風格

程式是什麼？不同的角度有不同的看法，比較經典的論斷是 程式=資料+算法。資料是一套系統的核心，他的地位是不可動搖的，好比人民的溫飽問題。算法是什麼，算法是系統的引擎，算法的好壞優劣決定了程式執行的效率。但随着現在硬體技術的提高，很多程式員已經淡化了算法的重要性，以完成功能為标準，這是可悲的事情。

依我的看法，程式不光是資料+算法，那隻是程式的行體部分；程式還需要有風格，這才是程式的神态部分。隻有形神兼備的程式，才是一個優秀的程式。程式風格又包涵哪些内容呢？在解釋這個問題之前，我們先設想一下，如果一個閉月羞花的美女，出口就是髒字；如果一篇行文灑脫的文章，字确寫得東倒西歪；如果一座雄偉的山峰，上面确寸草不生。那樣是不是很煞風景？

程式風格是什麼？程式風格就是一個程式中，在資料内容以外所展現出來的内涵，它表現在程式的各個方面。從使用者的角度：主要展現在程式的整體顯示風格（顔色基調、圖示風格、字型大小）和互動風格（資料組合方式、功能區劃分、操作流程）；從程式開發者的角度，它包括項目的管理、源檔案的組織、代碼的風格、注釋的寫法。

對于一個人的項目，程式的風格就取決于你的個人風格。程式員在鍛煉開發技術水準的同時，應該同時培養你的程式風格。

恭候拍磚！ 

正文：（六）Coding 1

程式的風格和核心資料庫表基本确定後，我開始了系統的子產品設計和編碼工作。我的基本思路是，按照程式子產品的重要性，逐個子產品實作。單個子產品的設計和編碼同時進行的，完成好一個子產品，就發送給Gentleman稽核，以子產品程式為交流載體，友善雙方溝通。

夜晚22:00後，靜夜孤燈下，一杯水，一個人。時而低頭沉思，時而握筆繪圖，時而指走鍵盤，這就是我平時工作的畫面。一行行代碼，一個個畫面就這樣躍然螢幕上。

系統中最先做到是産品管理子產品，大家可能會認為這樣的子產品應該是比較簡單的。是的，如果隻是實作建立、編輯、删除功能的話，肯定很簡單，但我确故意要将簡單的東西複雜化。廚師的水準高低，不在菜上，而在于做菜的功夫上。

我在實作産品管理子產品時，考慮到很多問題。如何将主貨号和詳細貨号關聯？主貨号中的哪些字段應該與詳細貨号中的相同，兩者之間應該怎麼顯示和編輯最合理？程式實作的過程中，哪些子產品可以共用，哪些字段需要備援？編輯某個貨号的時候，應該怎麼顯示其他貨号的詳細内容作為參考？怎麼讓業務員輸入最少的資訊即可完成操作？

上面這些問題，有Gentleman提到的，更有Gentleman沒提到的。我認為系統的開發過程，就像一段外語的翻譯過程，有人是直譯，有人是意譯，孰高孰低，明眼人一看就知道。至于其中多付出的勞動，雖然隻有自己知道，但同樣可以展現在你的勞動成果中。

在我的觀念中，開發系統不僅僅是為了開發而開發，應該再提升一個高度，至少要讓自己滿意。後來證明我的思路是正确的，Gentleman對于我的程式實作方式，很滿意，或者說贊賞。以至于他總是說我聰明，能準确地了解他的意圖，并恰當地實作出來。具體展現在他的需求文檔中，以往那些瑣碎的、近似設計的描述少了，他隻提他想要的結果，具體實作他已經不用操心了 - 這正是我的目的。

我和Gentleman的關系，開始有點像Partner了。

正文：（六）Coding 2

自從編碼開始後，項目開發工作似乎進入了正軌。

這套系統的編碼過程中，有一個十分麻煩的地方，那就是貨号價格的變化，需要更新多非常多的地方。這些都是Gentleman在常年的工作中總結出來的，他心中非常清楚。他隻要一看這些價格數字，就能知道哪些是正确更新後的，哪些是未更新的。可我在短時間内确是很難做到的這一點的，是以，我單獨寫了一份價格更新對照表，雖說整理着份檔案花了不少時間，但磨刀不誤砍柴功，這份檔案在後續的工作中發揮了重要的作用。

是以，我認為在開發過程中，對于那些容易混淆或需要非常仔細的地方（例如：本系統中的各種價格組成、公式、更新對照等），應該單獨寫份文檔作為項目參考資料（這份文檔一定要準确無誤），即便是一個人開發系統，也有必要。就像Windows API參考文檔一樣，當程式需要調用具體API函數的時候，隻要查一下參考文檔就可以了，完全沒必要去記住那些具體參數，因為短時間内去記住那些參數，是不現實的。随着開發的過程，對于那些經常調用的部分，自然就熟悉了。

編碼的過程，是對設計的逐漸修正的過程。設計時了解不準确的部分，在Coding的過程中，都會逐一發現。

很多人羨慕一個人開發系統，其實一個人開發系統的優勢和劣勢同樣明顯。優勢在于整個開發中，省卻了所有的開發溝通時間，因為整個系統（哪怕是非常細小的環節）都了然于胸；劣勢就是孤單，遇到任何技術問題都必須自己一個人去解決，解決問題後的快感也沒人分享。

這個劣勢在後續的開發中，給項目帶來了一點問題。

正文：（六）Coding 3

編碼的工作是辛苦的，遠沒有程式設計時的天馬行空，需要的是嚴謹的工作态度、良好的編碼習慣和相對完整的開發時間。對于Part-Time開發者來說，很多人覺得非常辛苦，主要是因為沒有完整的開發時間。

項目的開始階段，一般開發者都能保持相對高的開發熱情，但一旦進入編碼的中期，這種熱情支撐下的開發進度就開始疲态盡顯。我也是遇到了同樣的問題，項目進行了3-4個月左右的時候，開發進度明顯比預期的低了很多，就連大洋彼岸的Gentleman也能明顯感覺得到。

Gentlman開始有些着急了，經常在Email中詢問開發進度（其實就是催促開發進度），并主動提出快速開發獎勵。我非常清楚Gentleman的心思，首先，他是想在下一次的廣交會之前使用上這套新的系統，以便提高工作效率；其次，他是認為我目前的系統開發品質比他原先預期的要好，是以很樂意提高開發費用。面對相對優厚的額外獎勵（這是Gentleman高明的地方），我也很想提高效率，但由于種種原因我很難進入快速開發狀态。

多說兩句當時的情況，權當為自己開脫吧。其一，項目進展到3-4個月左右的時候，我老婆正到預産期，我可愛的女兒來到了這個花花世界；其二，在去年轟轟烈烈的A股牛市中，我這新股民懷着快速發财的夢想，在5500點的高位殺入了大量的資金，結果虧損嚴重，緻命的是這些資金有大部分不是自己的存款。這讓我承受了巨大的精神壓力，幾次出現失眠的情況。僅此兩點，大家就可想而知我當時的狀态了。

心态上無法進入工作狀态，時間上無法保證開發時間，一個人的戰鬥，孤立無援，我把項目帶入到了最艱難的境地。 

正文：（九）Coding 4

面對Gentleman的額外獎勵，我深感慚愧，雖然内心很想加快開發進度，但當時的心思确又很難聚焦到項目開發上來。這樣渾渾噩噩的狀态大概延續了一個月左右，項目的開發進度比預期已經差了一大塊。我幾次想在Email中告訴Gentleman我的痛苦，但炒股導緻的心理失衡問題，怎麼能讓他去承擔後果。我問心有愧啊！

即便在如此情形下，程式的代碼品質還是我把握的第一要素。要麼不寫，要寫就一定要保證品質，我絕對不會做殺雞取卵這樣的事。盲目上線帶來的一定是後續更大量的補救工作，同時也會影響客戶的信心。這一點，應該也是Gentleman欣賞我的地方之一。

随着春季廣交會時間的日益臨近，Gentleman已經感覺到項目無法在此之前完成，但他表現得非常大度。不僅沒有過多地責怪我，相反還繼續鼓勵我，額外獎勵依然有效，隻是要求我全力把程式開發好。Gentleman的做法，讓我非常感動，我時常自己在問自己：如果我不能及時調整好心态，不能堅持把項目開發好，對得起Gentleman這樣的好人嗎？

我的名言：生命就是折騰與被折騰的過程。

這渾渾噩噩的一個多月，其實就是我個人心态的築底過程，而這心态鑄底成功的因素中，我清楚，有Gentleman一份功勞。伴随心态的調整成功，項目開發也重新步入正軌。當然Gentleman也從CA國飛回到本市，開始籌備公司的春季廣交會的展覽。

準确的說，此時此刻，系統的編碼工作已經完成了80-90%

正文：（十）資料庫選型

個人項目中，心理層面的問題需要自我調節，技術層面的問題同樣隻能獨自解決，下面就寫點技術問題。

在這套系統的資料庫選型中，我是經過一番思考的。從我個人技術熟悉程度上來說，是對DB2和Sql Server比較熟悉。但對于30人規模的中小型公司，沒必要選用過大的資料庫，Oracle、DB2這類首先被PASS掉了，在Sql Server、MySql、Sybase ASA中，MySql中，到底應該選用哪個呢？

可能很多人認為Sql Server應該是首選，最初我也在重點考慮它。但是Sql Serverd資料庫，部署起來有點麻煩，考慮到Gentleman是長期在國外生活，在系統開發的過程中，我時常需要對資料庫的結構進行調整。是以，資料庫一定要便于打包和部署。其次，考慮到資料同步問題，因為這個系統最終資料庫的部署，是需要在公司本部放一個中心資料庫，另外幾台筆記本上各放一個遠端資料庫。而這些資料庫之間，要能夠非常友善的進行資料同步。此時Sybase的Mobilink同步技術就進入了我的視線。（在這個項目之前，我并未做過資料同步方面的工作）

綜合上面兩個主要問題，我最終選擇了 Sybase Asa 資料庫，這款資料庫，非常友善部署。更新資料庫的時候，隻需要直接替換資料庫檔案和日志檔案就可以。而且我從Mobilink的資料中了解到，它是基于偶連接配接的同步技術，專用于中心資料庫與多個移動資料庫的資料同步的解決方案。我心想：Mobilink技術簡直就是為我們這種應用而設計的。

同為Sybase的産品，ASA資料庫理應與Mobilink無縫銜接。

讨論篇2：技術與應用

很多在校的學生和入行的新人，總是最關心開發技術，而且最關注流行技術。就好像流行時裝一樣，看哪些語言或工具流行，就學哪樣，有甚者把市場主流的應用開發語言都學了個遍。其實大家會發現一個問題，即便學習了所有的開發語言，仍然不可能就此成為開發高手，因為他們學到的隻是外在功夫，而非内功。

關于技術的内功和外功問題，大家隻需要在開發的過程中，稍微用心體會一下，就可以找到練内功的方法。寫代碼的時候是不是頻繁 Ctrl+C 和 Ctrl+V ，而不去琢磨複制過來這段代碼或算法的基本原理？函數中的參數設定，是否僅僅滿足功能就可以，還是需要預留下某個擴充？哪些功能代碼可以抽象成一個類來實作，而非在程式中到處Copy同樣的代碼？等等！

（書法作品中一筆一畫即能展現深厚的功底，想成為行家，就應該在程式的每個地方有自己的心得）

同樣的程式，從客戶角度，他們關注的側重點是完全不同的。依據我的開發經驗，客戶基本上不關注系統采用的技術架構，哪怕你說得天花亂墜，那最多隻是談價格的一點小資本而已。他們關注的是系統功能，能否設計出他們認為最快捷、最安全、最實用的系統。“落後”的技術，同樣有廣闊的生存空間。因為對于客戶，适用的就是最好的。

一個人做項目的時候，請記住：技術不是越新越好，而是越适用于項目越好，越熟悉的技術越好。在技術上你站得越高，項目的成功率就越高。（想學習和鍛煉新技術，最好請到其他的項目組中學習，因為一個人的項目，新技術意味着無數未知的問題）

恭候高手拍磚！

正文：（十一）項目中期收款

Gentleman回國後的這一個多月時間，幾乎一直在忙于春季廣交會的事情，很少和我聯系。隻是約定等他從廣交會回來後，讓我去他那領取部分項目款。

（在第一次面談的時候，Gentleman就問過我項目收費方式的問題。現在一般公司的付款方式是361方式，即30%作為項目啟動款，60%在項目驗收後付款，10%的尾款最後在确認系統運作正常後付清。而我給Gentleman的答複是，項目開發前我不收任何款，等系統基本成型後（即客戶可以認同開發品質和效果後）付60%的項目款，正式上線運作後，再付40%的項目款。

我之是以采取這樣的收款方式，首先，我對自己的開發實力有信心，相信客戶在見到系統後，會樂于付款；其次，我考慮對方是一家公司，而我是個人開發者，讓對方提前把錢付給個人，這其中的風險明顯大于付給一家公司。而我關心的是項目款的多少，并非付款時間。）

這次，我們見面的地點是Gentleman在本市的House，我按照約定好的時間準時到達。他的房子位于本市一段黃金海岸線上，從室内就能看到浩瀚的大海，總面積約有160平米，價值至少兩百多萬。屋子以淺色調為主，家具并不多，顯得非常整潔。用Gentleman的話說，他常年定居在CA國，這房子基本是空着，隻是回來的時候住這，是以陳設簡單了些。

我們的話題，始終圍繞着房子，而并沒有說太多關于項目的事情。那天，我才了解到，Gentleman在做生意之前，也是工薪族，居住在一套30平左右的老房子中。後來公司逐漸地發展壯大，他家的房子也随之換了三次，地段一次比一次好，面積一次比一次大，而他現在在CA國的家，是一棟獨門獨院的木房子。

從Gentleman家出來的時候，我已懷揣着剛收到的項目款，心中雖說有幾分成功的喜悅，但同樣有幾分抹不去的惆怅。

正文：（十二）意譯的煩惱

在整套系統開發的過程中，我一直采用‘意譯’的模式，對Gentleman所提出的需求進行改進設計，但也有例外的情況。系統中有一個子產品是給工廠下生産通知單，在這個子產品的處理上，就出現了問題。

公司目前的做法是依據合同中的産品數量，給工廠下達生産。一份合同由多種貨物組成，每種貨物的訂購數量和外銷價是不同的。實際工作中都是将一種貨物中所有的訂購數量都制定一家工廠生産，當時，我從邏輯角度上分析，認為存在這種可能，即一種貨物分交給兩家以上的工廠生産。

是以我在設計中提出了改進子產品的設計思路，并彙報給Gentleman，他當時的反應顯得有些猶豫。因為現在的實際工作中是不存在這樣的情況的，如果系統能實作到這種程度，肯定是更靈活，是以他就準許了我的設計思路。

這個子產品的設計和實作過程中，由于要實作到同一種産品配置設定給多家工廠，并且訂購數量要動态配置設定和回收。是以需要考慮到情況就複雜了很多，時間自然也多花了N倍。最終實作出來的效果是非常不錯的，操作員可以清楚地看出每份合同下達的生産通知單，以及每種産品的生産數量。

但以上所認為到的程式最佳實作效果，都僅僅是我個人認為的狀态。當把這個子產品拿到具體業務員那測試操作的時候，問題就顯現出來了。他們都反映麻煩，第一，從思路上和現狀有點差别，感覺别扭；第二，在操作步驟上又多了一步操作，耽誤時間。最後，Gentleman在考慮再三後，讓我把這個改進子產品功能去掉，依舊實作最原始的需求。

後來我總結此次教訓，雖然子產品的功能更靈活、更強大，但客戶隻需要他想要的，改進子產品一定不能成為畫蛇添足。

正文：（十三）測試之痛1

程式編碼工作逐漸接近尾聲，接踵而來的就是功能測試、子產品測試、內建測試、系統測試等。對于系統測試，開發人員大都不願意去做的，因為這是一項既繁瑣、又無成就感的工作。

一套沒有經過嚴格測試的系統，就像一匹沒有缰繩的野馬，誰也不知道它發飙的時候，會跑到什麼地方去。再繁瑣的工作也要做，初步的功能測試和子產品測試工作自然是由我自己來完成。可我發現個問題，我隻要輸入一些資料到系統中，開始做測試工作，就會自然地進入到一種自我欣賞系統的狀态中，一圈資料測試下來，隻能找到少量的程式錯誤。

Bug大體上可以分為兩類，第一類是程式錯誤，例如：由于資料邊際校驗不強而引起系統異常當機，程式顯示不正确等；第二類是算法錯誤，即程式中某些資料的計算方法不正确，或資料更新不完整。對于第一類錯誤，我還好測試些，畢竟出現問題後，一目了然。但對于第二種錯誤，我根本無法察覺，例如一套産品的最終價格是58，我很難直接判斷出這個價格是正确計算結果，還是有問題。但對于有豐富經驗的業務員來說，他們是很容易做到的，因為這些價格他們太熟悉了。

考慮到我在測試過程中很難發現第二類錯誤，是以就和Gentleman商量，看能否找人來協助我做這部分的測試工作。（當時我以為Gentleman的日子過得很潇灑，身在國外，遙控公司，自己則周遊列國，好不自在。）而他也沒含糊，一口就答應下來，我真是喜出望外。

其實我的想法僅僅是，讓他找個心細的業務員來做系統的測試工作，但出乎意料的是，他居然親自上陣，自己一個人來做測試工作。 

正文：（十四）測試之痛2

Gentleman是一個辦事認真仔細的人，他每次測試完一個子產品後，都會詳細地記錄下錯誤的具體情況（效果、他估計的原因、在什麼資料輸入流程下出現錯誤等等），然後發一份錯誤報告給我。有時為了描述一個錯誤，需要要寫上百字，并配以螢幕截圖。我見過他在電腦上輸漢字，基本上是二指禅的功夫，輸入速度非常慢。是以我可以想象，他在做完測試後，敲上一篇上千字的錯誤報告需要多少時間。而且，後來我從Gentleman那也證明了自己的猜測，他花在寫Email的時間，遠多于測試時間。

雖然我多次建議Gentleman将測試工作交由下屬去做，但他一直都沒有同意。他說，系統的需求和設計過程，都是他全程參與的，換了誰都沒有他這麼清楚。其中有很多地方都是與原系統不相同的，如果換由其他人來做測試的話，是測試不出問題來的。他堅持測試到基本可用的狀态，再交由其他人來做後續測試。

我真的為他這種認真的工作态度所感動，是以他每次發送新的錯誤報告後，我都會盡快把這個錯誤修改好。我們就這樣合作，他一有空就測試程式，然後把錯誤報告發給我，我将修改好的程式發送給他，他最後再做一次錯誤修正後确認測試。為了我們的測試能基于相同資料，我們之間還經常交換資料庫，固定以某段資料為測試基礎。初略估計，這個測試階段他的工作量應該是我的2-3倍，因為大部分的Bug，都很容易修改，隻有少量幾個需要調整較多的地方。

看着系統一天比一天強壯，這種感覺真的很美妙，就像練健美的人看着自己的肌肉越來越發達，喝酒的人感覺自己酒量越來越大一樣，都是很享受到事情。

同時，Gentleman也基本上切換到新系統下工作了，隻是用老系統來查以前的資料。因為有了新系統的比較後，他已經無法忍受老系統的低效率了。

正文：（十五）測試之痛3

系統經過Gentleman和我的多次測試和修改後，健壯性得到了顯著的提高。在測試期間Gentleman想從CA國飛回來，專程為系統上線前做最後的實戰測試。我是不贊同的他這麼做的，當時正好趕上萬衆矚目的北京奧運會，他的簽證上也遇到了些麻煩，是以也就順利成章地取消了這一臨時計劃。

雖然Gentleman自己沒回來，但他專門安排了他的助理（本文中稱呼為MissLee）來協助我做上線前的最後測試工作。我和Gentleman協商後，制定的計劃是：測試資料庫放在MissLee的電腦上（以後再配備專用的資料庫伺服器），首先在營銷部的5台電腦上安裝用戶端程式。即本套系統先由營銷部來做實戰測試，因為他們的業務中使用到的子產品最多，資料所走到流程也最全。當系統測試沒有問題後，再全面推廣到公司的所有機器上，這個過程預計2-4周。

系統安裝到營銷部後的那些天，他們馬上就有很多資訊回報。依據Gentleman的要求，營銷部所有的回報意見都統一發到MissLee那兒，再轉交給Gentleman本人。Gentleman和MissLee會對這些資訊回報進行分析，例如：哪些意見是非常正确的，系統的确需要在某處添加資料項、添加功能或資料導出。然後他們會整理好，發送Email給我。我越來越覺得Gentleman真是個Good Partner，他的事先安排，讓我的工作井然有序，而不是面對嗡嗡作響的各種嘈雜意見，這應該是很多人值得學習的地方。

當然，這期間系統也有很多'莫名其妙'的錯誤，例如，他們在導出一份報表檔案的時候，進度條總是停在30%處就不動了。而我在自己的電腦上，和Gentleman的電腦上都測試不出這樣的問題（這些問題大多是因為，産品庫中缺少了某些産品的圖檔啊，或金山詞霸的自動取詞功能引起系統中特效按鈕顯示不正确等等）。類似于這種情況的問題大概有五六次，我都是需要及時到現場測試，然後逐一排查原因，最終找到問題所在。

解決這些疑難雜症的話說起來很輕松，但在實際找尋錯誤的過程中，沒有交流，隻有自己一個人琢磨。都是在結合程式源代碼的基礎上，仔細排查錯誤，這個過程既曲折更痛苦，需要相當的開發經驗。以至于後來Gentleman開玩笑，說我無所不能，在我這所有問題都不是問題。

經曆了半個多月的系統測試後，營銷部人員，也由最初的對系統很不放心，到享受系統帶來的高效工作。

讨論篇3：項目之上的情感

在本文前面的若幹節中，我已經多次提及Gentleman身上的特點，認真仔細，善待員工。原本我以為他平時的工作很輕松，可後來才知道，他每天工作都在十小時以上。國内與CA國有八個小時的時差，這邊白天上班的時候（他那就是17:00-01:00），他基本上都挂在IM上，随時與公司這邊保持着聯系，而且還要處理大量的客戶Email。

現在回想起測試階段，我把大量的測試工作都交由他來做，真是于心不忍。系統安裝到營銷部的時候，MissLee和其他同僚也都說Gentleman非常辛苦，希望系統能給他減少負荷。我當時心中就在想一個問題，當今社會，有幾家公司的員工會這樣為老闆說話？大家為什麼會這樣向着老闆說話？如果Gentleman身上沒有特殊的品質，員工又是會怎麼樣？看到了這些，我就不難了解，為什麼一家30人不到的貿易公司，每年的貿易量卻能達到2000标箱以上。

這封Email之後，我能明顯感覺出我們的關系更親近了，已經超出項目範疇了。一個人的成功不可能是偶然的，Gentleman身上有很多值得我學習的地方，在後續的Email中我直言，項目的收入對于我來說是次要的，能跟着成功男士學習優秀的品質對我來說更為寶貴。

系統從一開始設計的時候，就有資料同步的需求，即公司區域網路的電腦都通路中心伺服器的資料庫，而各台筆記本都通路本機上的分資料庫，兩者是完全同構的資料庫。