程序員接私活經驗談[轉]

程序員接私活經驗談[轉]

 

關鍵字：程序員 私活 經驗 外包 做者： row@csdn 標題：我的外包項目全記 - Best Partner

地址：http://www.cnblogs.com/txw1958/archive/2012/11/06/programmer-personal-work.html

正文：（一）項目確立

一年前，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標箱以上。

今年一場金融危機幾乎席捲了全球，我因爲炒股的緣由，因此很是關注全球各股市的走勢。我能意識到這場危機對於出口型公司的衝擊會有多大，因此在9月18日的時候，冒昧地給Gentleman發了一封與項目無關的Email。全文以下：

「您好！

不知您最近是否關心全球經濟動向？如今能看到的狀況已經很是糟糕。美國五大投資銀行已經倒閉和被他人收購了三個（貝爾斯登、雷曼、美林），另外兩個（高盛、摩根士丹利）也是關注的焦點，昨天高盛股價下滑23%，摩根士丹利股價大跌44%。

上週我和一個高中同窗（他是耶魯博士畢業，就任於美國雷曼兄弟公司紐約總部）MSN上聊天，他說美國遇到1929年以來最大的金融危機。上週末雷曼即宣佈破產，美聯儲前主席格林斯潘在接受採訪時也說，美國遭遇千載難逢的金融危機，經濟回退很難避免。美股最近3天出現了2次4％以上的跌幅，這是美國911事件以來單日最大的跌幅。

我不清楚會對全球經濟產生多大的振動，如今全球的股市（美洲、歐洲、亞洲）都是一片暴跌。波羅的海航運指數也從高點12000點，跌到如今不到6000點，這些都說明全球經濟可能面臨萎縮。個人一個朋友，是青島一家4S店的總經理，他們最近2個月的汽車銷售量爲0，搞得他壓力很是大。前天就是去他公司看套行業軟件去了，和他聊了一下上面這些話題。他前期忙於生意，都不太清楚原來全球經濟發生了這些事情，感受他聽後心情很沉重。您公司是作外貿，應該對這更敏感些，我也不瞭解這些變化會對我們這個行業產生多大的影響，提早作有些準備老是有益的，但願個人擔憂是多餘的。」

下面冒昧地將Gentleman的回信公佈於此，但願他不會所以責怪我。

「謝謝你的關心！很是感謝，真的。我天天都在關注這些事情。一句話，冬天快要來了！

1929年美國發生了大蕭條，稱爲GREAT DEPRESSION.最近2－3年內，極有可能會發生GREATER DEPRESSION.

格林斯潘說，美國遭遇千載難逢的金融危機，並無誇張－－雖然這是他一系列政策埋下的種子。

對於咱們生意的影響有多大，如今還很難說。一種多是：覆巢之下，焉有完卵？另外一種是，滄海橫流，方顯出英雄本色。

（這話說的有點大了，我並無把握。勉勵本身而已。）謝謝！」

這封Email以後，我能明顯感受出咱們的關係更親近了，已經超出項目範疇了。一我的的成功不多是偶然的，Gentleman身上有不少值得我學習的地方，在後續的Email中我直言，項目的收入對於我來講是次要的，能跟着成功男士學習優秀的品質對我來講更爲寶貴。

正文：（十六）數據同步1

系統從一開始設計的時候，就有數據同步的需求，即公司局域網的電腦都訪問中心服務器的數據庫，而各檯筆記本都訪問本機上的分數據庫，二者是徹底同構的數據庫。

因爲在接這個項目以前，我沒作過任何數據同步的項目。所以，一開始我還設想着本身寫程序來實現數據同步功能，即設定時間點，而後經過程序導出每一個數據庫某段時間內的數據（新建、修改、刪除），而後再將導出的數據進行比較，最終求出數據合集。可稍微考慮點詳細的實現過程就以爲頭大，狀況太複雜了。若是要實現到應用的程度，可能單寫數據同步程序所花費的精力，就遠遠超過了寫業務程序，因此，最終放棄了這種不現實的想法。

（在校時，個人一位同窗接了個進銷存項目，可當時咱們所掌握的技術主要集中在C++操做文件上，即全部的數據都是存儲在二進制文件中。這老兄完成這個項目，楞是沒有用數據庫。全部的數據全用二進制文件來操做，讀寫刪查都是本身寫代碼，沒有用一句SQL。用他的話說，簡直就是本身寫了個數據庫啊，累得快吐血，效果還很通常。）

一樣的道理，若是我本身去寫數據同步程序的話，我估計效果確定和我那位同窗當年同樣。因此斷然不能本身去寫數據同步，即使我真有這能力寫出來，那也不能這樣作。由於若是業務發生變化或系統擴展，須要對數據庫表進行調整（新增表或字段），那個人數據同步程序還要本身去從新完善，我想那必定是個場災難。

數據對於任何公司來講，都是最寶貴的，因此我要選用成熟而安全的方式來實現數據同步。

正文：（十七）數據同步2

肯定選用數據庫同步工具來實現數據同步後，我就開始Google數據庫同步工具，其中Sybase Mobilink進入了個人視線，它的主要功能介紹以下：

「MobiLink 同步容許在符合 ODBC 標準的統一數據庫和 Adaptive Server Anywhere 或 UltraLite 遠程數據庫之間進行復制。在本教程中使用的是 Adaptive Server Anywhere 遠程數據庫。統一數據庫可以是使用 Sybase Adaptive Server Anywhere、Sybase Adaptive Server Enterprise、Oracle、Microsoft SQL Server 或 IBM DB2 生成的數據庫。

MobiLink 適用於將一個統一數據服務器和大量遠程數據庫進行同步（一般包含多個移動數據庫）。遠程站點的管理和資源須要已降到了最低限度。此係統是基於偶鏈接的，而且遠程站點可隨時進行鏈接。在每次進行鏈接以後，數據庫是徹底同步的。

MobiLink 的工做方式是：將遠程數據庫上的多個事務的結果合併成一個更改集，而後應用到統一數據庫中。由於同步始終在事務邊界進行的，因此保持了參照完整性。不保留在組件事務過程當中所作的各個更改的順序：由於從不復制未提交的數據，因此保留了數據完整性。」

乍看到這些介紹的時候，我簡直是喜出望外，這些同步功能簡直就是爲本項目需求所設計的啊。

我趕緊連夜下載了一套 Sql Anywhere 9 開發版（其中包含Mobilink同步工具），依據一些文檔資料，我開始測試起數據同步功能來。先新建好一箇中心數據庫和兩個遠程數據庫，而後按照文檔中提供的例子，啓動同步服務器和同步客戶端。沒想到進行得異常順利，遠程數據庫和中心數據庫的數據很快就實現了同步，我有點找不到北了，心想本來覺得麻煩的問題，原來就是層窗戶紙啊！

可高興勁還來得及過去，就發現一個問題，其餘全部的同步都正常，就是刪除操做的同步出來點問題。遠程數據庫中的刪除能夠正常同步到中心數據庫上，但遠程數據庫之間卻沒法同步刪除操做。具體狀況的描述以下：

中心服務器取名CenterDB(Server)，兩個遠程數據庫分別取名RemoteDB1(Client1)和RemoteDB2(Client2)，當你在RemoteDB1(Client1)中刪除某條記錄後，Clinet1執行同步語句後，能同步到CenterDB(Server)上，即CenterDB中也刪除了這條記錄。接着在Client2上執行同步語句後，卻發現這條記錄依然存在於RemoteDB2(Client2)中。

這是我在MobiLink使用過程當中遇到的第一個麻煩。

正文：（十八）數據同步3

爲了刪除沒法同步的問題，我處處Google解決方法，可網上幾乎沒有什麼討論MobiLink的文章，僅有的幾篇都是介紹性的文章，逐漸地我開始有點毛爪了。可Gentleman在得知這個問題後，確表現得很是大度，他對我說，若是實在解決不了刪除同步的問題，那系統在使用的過程當中，就採起行政手段來同步。即須要數據刪除的時候，你們就記錄下來，而後互相發Email通知。

我很難想象在系統使用過程當中，你們互相發Email通知刪除的時候，會順便暗自問候我這個程序開發者多少次。我沒得選擇，必須找出辦法來。在翻了不少資料和搜索大量網頁後，終於在Sybase網站上一個英文的幫助文件上，找到了這個問題的解決方法。

原來MobiLink在實現數據同步的過程當中，中心數據庫的刪除就是沒法同步到遠程數據庫上，而遠程數據庫的刪除能夠同步到中心數據庫上。若是想實現這種刪除的數據同步，有兩種解決辦法。第一種方法是創建影子表，即對每一個表都新建一個影子表，某條記錄刪除的時候，都在其對應的影子表中記錄下刪除行的主鍵；第二種方法是邏輯刪除，即在每一個表中建一個刪除標識字段。

考慮到實現的複雜度，我最終選用了邏輯刪除的方法。但緊接着另外一個問題又來了，此時的程序編碼工做差很少完成了70%左右，如今把程序中全部的真實刪除都改爲邏輯刪除，源代碼中須要修改不少的地方。如何以最快最全的方法實現邏輯刪除？我整整思索了半天，忽然靈光一閃，想到了一個最佳方法。即從數據交互的父類中修改真實刪除所調用的函數，把真實刪除改的SQL語句改成邏輯刪除所對應的SQL語句。這樣只修改一處代碼，即把系統中全部的真是刪除都搞定。

我暗自詡獎本身：你怎麼這麼聰明啊！

正文：（十九）數據同步4

在解決了MobiLink數據同步的中心數據庫與遠程數據庫的刪除同步問題後，我又開始測試數據同步的速度問題。發現局域網內和Internet網上MobiLink的數據同步速度差很少，這讓我非常高興，可接着另一個問題又開始困擾我了。

開始作數據同步測試的時候，因爲數據庫中的數據量很小，每次數據同步的時間大概在2-5分鐘。而隨着數據庫中的數據逐步增長，發現同步所需的時間愈來愈長。MobiLink資料上，都說數據同步的原理是依據日誌文件中的數據庫操做語句，對數據進行增量同步，即第二次同步的數據是第一次同步後的數據修改。這就讓我很不理解了，爲何隨着數據庫的增大，同步的速度愈來愈慢，並且從同步服務器的滾屏顯示上，明顯是在掃描第一次同步之前的數據。

Google了N多的地方，都沒有發現有討論這個問題的地方，我又得本身摸黑前進了。憑藉以往的經驗初步推斷，有兩種可能緣由，第一種是數據庫的日誌出來問題，第二種是數據庫的MobiLink同步設置出來問題。

首先從第一種可能性考慮，我把ASA數據庫的日誌刪除掉，從新構建日誌。但願全新的日誌能給我解決這個問題，可發現同步速度依然是老牛拉車。重構的新日誌不行，我又遍查方法，但願能有日誌整理的方法，把原先的日誌從新整理。光折騰日誌就花了我一個多星期，頭也大了兩圈，最終自認爲是進來死衚衕。

而後又考慮Mobilink同步設置的問題，把《Mobilink同步用戶指南》《Mobilink同步參考手冊》都翻了個遍，還查幾乎全部能找到的資料，也都沒查出因此然來。光前面兩本書加起來就一千五百來頁，真是鬱悶得夠嗆。此時的Gentleman又給了我鼓勵，說如今也能將就着用，無非就是速度慢些而已。可我心中明白啊，系統正式上線後，數據庫會迅速加大，若是每次同步都是全掃描，那真是慢得跟頭驢同樣。

通過半個多月的查找，就在我幾乎快絕望的時候，一次隨意翻查《MobiLink Developer Resource Kit》的時候，竟然發現裏面有一篇「Mobilink數據分區」，詳細地記載瞭如何設置實現數據的增量同步。這真是踏遍鐵鞋無覓處，得來全不費功夫啊。我都感動得想喊出來，按照裏面的設置方法，對數據庫進行了相應的調整後，一測試，OK, No Problem。

那天，我感覺到久違了的勝利喜悅，彷佛一會兒把我拉回到了讀書時代。

正文：（二十）最後一次大考1

通過屢次的數據庫同步測試，我自認爲已經大致上掌握了MobiLink的數據同步方法；同時，系統程序通過營銷部的實際測試也日趨完善。與Gentleman商量後，決定系統在秋季廣交會前全公司範圍內上線。

因爲前面的系統測試工做作得很是充分，因此係統上線後並未遇到任何技術上的問題，僅是某些部門和我的提出了一些小的功能修改意見。至此係統算是基本上線成功，但還有最後一次大考，那就是秋季廣交會。

Gentleman和他的同事們，很是重視廣交會，他們會在此前作好最細緻的準備，其中包括參展的樣品、名片的準備、筆記本、業務系統、打印機的調試等等。給我感受就像上前線打仗同樣，這比喻一點都不誇張。Gentleman說他們在以往的廣交會上就是神經一直緊繃，來了客戶之後，須要迅速給客戶報出各類產品（或依據客戶的需求組合的產品）的價格。其中容不得半點差錯，價格報高了，會讓客戶失去興趣，價格報低了，則公司蒙受損失。因此廣交會期間，只要客戶一來詢價，你們就處於緊張狀態，須要反覆覈算價格。

固然Gentleman此次去參加廣交會是準備好了兩套方案的，他們分別在新老兩套系統中都輸入好了參加廣交會的新貨號，若是新系統在廣交會期間出現問題，他們就立刻切換到老系統下使用。（這些是我過後從其餘員工那兒得知的）

這次廣交會，Gentleman他們租用來兩個展廳，因此帶去的六臺筆記本組成2個局域網，分別在兩處使用。整個廣交會參展期間（大約10天時間），新系統不負衆望，運行高效穩定，報價準確迅速，極大地減輕了Gentleman他們的工做量和精神壓力。看着你們回來時對系統滿意的神情，我心中甚是開心，說明新系統徹底達到了預期的目的。

可就在廣交會回來後的數據庫同步過程當中，我又捱了一記‘悶棍’——其中一臺筆記本上的數據庫與中心服務器數據庫的同步過程當中，出現了只下載數據不上傳數據的奇怪現象。

正文：（二十一）最後一次大考2

因爲全球金融危機的緣由，今年的秋季廣交會市場比較清淡，珠江三角洲附近以出口爲主的傢俱和玩具企業紛紛倒閉。但從Gentleman那瞭解到，今年他們公司的狀況還算不錯，雖然比春季廣交會的成交量差一些，但已經比預期的情況好多了。加之這次廣交會上，因爲新系統很是好用，因此在現場感受工做比較輕鬆，並未出現手忙腳亂的現象。在這次廣交會臨近結束的時候，他們還特地舉行了一場小型的慶功宴會。

你們從廣交會上回來後，紛紛說新系統很是好用。得知這些喜人的消息，我天然也是很是高興，在他們回來的次日，我就去Gentleman公司那，幫他們把筆記本上的數據同步到服務器上。我本來預計最多一兩個小時就能搞定的事情，可沒想到竟然整整耗了近十個小時（16:00 - 02:00 晚飯也沒吃）。

由於出現了一個奇怪的現象，即其中一臺筆記本與中心數據庫同步的時候，只能下載數據，卻沒法上傳數據，這讓我一頭霧水。由於這檯筆記本上的同步語句和其餘的都是同樣的，MobiLink中的確提供了單向同步的設置，可我並未加上這個參數啊。問題出在什麼地方呢？

我仔細梳理着每一步環節，回想起來這檯筆記本上的數據庫與其餘數據庫不一樣在於，它的數據庫是從另一臺筆記本上覆制過來的。由於在廣交會上，Gentleman是分兩個展區的，而這第二個展區的開展時間比第一個展區晚兩天，因此Gentleman當時在獲得個人許可後，就把第一個展區用的數據庫複製到了這檯筆記本上。

而MobiLink數據同步的原理是，每一個遠程數據庫都對應一個同步用戶的，即每檯筆記本都須要對應一個不一樣的同步用戶。最初我認爲MobiLink的數據同步過程，只要我不設置單向同步，即確定是即上傳又下載的。可那天通過我反覆測試，發現對於一個新的同步用戶，在初次與中心服務器作同步的時候，數據是隻下載不上傳的。

一開始，我覺得是設置出來問題，可反覆檢查設置，並未查出問題。我再仔細琢磨MobiLink爲何這樣處理？雖然我並未在任何MobiLink資料中印證個人猜想，但我最終認爲這是MobiLink特地這樣處理的。即對於一個全新同步用戶，初次同步過程當中，MobiLink的執行方法是隻下載不上傳的。其實這也很好理解，因在一箇中心數據庫和多個遠程數據庫發佈的時候，只有默認這種方式才能最快完成同步，不然數據只有輪詢同步兩遍以後才能實現徹底一致。在想明白了這一點後，我趕忙改變了方法，即採起手工SQL語句導出的方法，將那臺沒法上傳數據的筆記本中的數據導出到文件中，而後再將這些文件數據導入到中心服務器內。

那晚，就這樣琢磨後測試，測試後又琢磨，一直折騰到凌晨2點才把數據所有導入到中心服務器中。由於我清楚，若是不把數據整理好，Gentleman的公司明天就沒法正常工做，因此必定要在那晚把數據整理好。

正文：（二十二）煮酒論英雄

那天爲了將筆記本數據導入到中心服務器，我工做到凌晨兩點，Gentleman爲此深受感動。但我認爲，一個值得我尊敬的合做夥伴，我就應該盡我所有的能量，將系統功能開發好，將數據同步完善好。

在這近一年的交往過程當中，我深感Gentleman身上有太多值得學習的地方。因此每次Gentleman回國的時候，都是我抓緊學習的機會。爲了有更好的交流時間，我火燒眉毛地在秋季廣交會以前，就邀請Gentleman單獨慶賀一翻。

Genteleman是個很是理性的人，在他的思想中，開發一套系統，不管投入多大精力和財力，只要系統能創造出更多的效益，那全部的投入都是很是值得的。而對於我來講，當前的新系統僅僅是第一步，只是簡單地提高了業務的執行效率，並未給公司帶來更多的利益。在個人頭腦中，正在思索下一步的工做重點，如何能從繁瑣的工做中解放出更多的人員？如何能讓Gentleman站在全局的高度上，分析出公司的利潤髮展點和成本控制點？如何能有效地將營銷部、海運操做部、財務部等各職能部門更有效得協同工做？我相信，心有多大，舞臺就有多大。

借單獨與Gentleman慶功的機會，我將本身成熟的與不成熟的想法都拋出來了。咱們邊飲酒邊暢談，對於新系統的下一步建設作了整體的規劃，從這個規劃中可見在Gentleman的心中，有更宏偉的藍圖，他但願建設的不只僅是一個單純的貿易公司，而是一個既有活力又有深度的集團性公司。

 

BEST PARTNER 全劇終