沙場秋點兵---走出軟件做坊：三五我的十來條槍 如何成爲開發正規軍（二十七）

前幾個月，公司旁邊的寫字間又搬進一家公司，好似也是作軟件的，並且好像是剛成立的公司，程序員們每天加班，神情很年輕，頭髮很油，穿着大背心大褲衩人字拖，男的女的都有，常常站在通道里成羣的吸菸，或者乾脆席地而坐圍成一堆開會，都不下食堂吃飯，都訂盒飯，中午晚上都是如此，我常常晚上下班，看見他們不時有人捧着一個盒飯從辦公室走出來把吃完的飯盒扔進垃圾筒，不知道他們會工做多晚。

近來發現，他們開始有人正常下班了。他們也不多聚在一塊兒抽菸開會了。通道里有的只是單個的人在打電話，聲音很低，神情普通。偶爾看見他們在外面通道里開會，也是個個神情緊張或肅穆或很累或木然或沉默。

我想起了一句話：Boy，Slowly，Slowly。

新的產品，新的夢想，你們都很但願可以把多年積累的知識都用上去，作一個業界一飛沖天的產品。可是，這這個新的團隊呀。

我想起了我剛出道的時候。我如今仍然很慶幸我能經歷一個產品的從萌芽規劃到實現到銷售到規模銷售的整個過程，讓我看到了一個產品是如何成長起來的，在成長過程當中會遇到哪些問題，是如何克服的。不少程序員沒有這樣的機會，每每一出道，就加入了一家運行N久的公司，團隊是現成的，產品是現成的，本身就是作維護開發而已，沒有完整經歷一個產品生命週期。因此一旦遇到新開發一個產品的時候，就很茫然，不知道如何下手，並且心情很激動，過去一直維護別人的代碼了，不少弊病想推翻重作都不行，如今終於本身能夠一展身手了，這回要把本身的想法都加進去，不能留有遺憾，不能重蹈覆轍。因而撲入了本身所有的心血，就連睡覺也不踏實，每日心情澎湃。但時間不長，兩個多月，各類問題就都來了。新技術、新團隊、新產品，一切都是新的，不少交叉出現的問題讓解決異常困難，團隊也出現了煩躁，看淡，疲憊的情緒，你們想盡快結束，但開發纔到中間，正是關鍵攻堅要命的時候。

我剛出道的時候，加入了一個新成立的研發中心，才成立四個月，我是第六人。產品還在規劃當中，團隊還在建設當中，技術還在學習摸索當中。

當時的技術總監作了兩件我如今也認爲很對的事情：1、他讓全部人閱讀上一代產品的源代碼，整理上一代產品的功能，而且得出上一代產品的功能所映射的客戶業務流程。而且要求指出上一代產品業務流程中的漏洞和矛盾。2、他讓你們經過改造源代碼來學習新技術。

他不只僅讓你們整理業務，還要畫出來詳細的流程圖，整理出詳細的數據結構。而後安排集中會議讓你們講，講的時候，以流程圖爲主，走到哪一步，就進入軟件界面講解，而且講明背後的數據存取究竟是處理了哪些字段標誌， 表之間是怎麼關聯的，到底從哪些表中取出來，表結構設計的有什麼不合理的。

此次沒講明的，此次提問沒有確切答案的，下次繼續講，而不只僅是講一回。我發現，不少團隊缺少這種不斷追根到底的魄力。老是有始無終，第一次講的很起勁，講的期間出現了本身也沒有理解透的東西，領導只是安排下去再去研究一下，但就沒有了下文。本身下去了看了一下，認爲找到了答案，但就沒有再次校驗的機會了，因而最應該細究的地方被這樣放過了。咱們知道，編寫程序，每每是最細節差別的地方最容易出現問題，並且不多能被測試到，並且維護代碼的程序員每每不清楚這塊是幹什麼的，一旦出現問題很難閱讀懂。

技術總監還讓咱們改造源代碼。但這個也是有目標的，就是把控件都修改爲一個統一的體驗風格，沒有DB的控件，就去尋找。尋找到了，就把這部分代碼摘出來，而後造成咱們本身的控件包，力求不要爲了一個小小的控件，就安裝整個的控件套件包。實在尋找不到，就本身開發控件。

學習新技術，我認爲這種方法是最好的一種方法。我如今也是這樣指導個人下屬的。

學習新技術，爲了怕誤導，一是閱讀官方的例子，如JAVA的寵物店或.NET的寵物店。但我後來我明白了，不能這麼學。由於原本就對新技術陌生，一開始入主的就是這樣的代碼，那麼之後的編寫程序的風格就每每會像這些例子同樣。其實，咱們編寫業務應用程序，並不須要這樣的架構風格，也不須要秀那麼多代碼模式。照貓畫虎把咱們畫的很累，還扭轉不了已經固有的思惟。咱們不須要這種看上去很美的代碼。

學習新技術，第二種方法就是找一個網上開源的什麼系統，如某些新技術嚐鮮者作了論壇系統或什麼什麼管理系統。但這種方法也有個弊病，就是他本身寫的代碼有他本身的風格，並且他還處於嘗試期，寫這個東西多是他爲了學習這個技術，而非目標是開發這個管理系統。原本我們對於新技術就是一張白紙，這下被他帶到溝裏去了。

學習新技術，第三種方法就是閱讀這個新技術自己的源代碼。惋惜原本就對新技術不熟悉，而新技術自己的源代碼更是複雜，看的雲裏霧裏，吃力看不到進展，欲想放棄。

因此，學習新技術，最好是學習基於新技術的第三方的外國開源源代碼。他們對新技術理解快理解深刻，他們應用新技術不是爲了嘗試新技術或者秀新技術，他們是爲了完成他們的一個實用產品。咱們當時爲了摘出某個控件，幾乎閱讀了那個控件套件包的全部源代碼，而且理出了源代碼的結構思路，不然咱們沒法肯定咱們遺漏了什麼，會不會有BUG。

可是，如今回過頭來看，方法是對的，時機倒是錯的。

咱們是新團隊、新產品、新技術，不少咱們還沒有了解清楚的，咱們卻把咱們學習新技術後獲得的控件應用到了咱們之後的正式產品中，而且做爲基礎應用。這給之後的發展帶來了幾乎是災難性的打擊，我最後費了好大的勁纔算把基礎重構而且穩定住，不然基礎崩盤了，上面的應用就不可收拾了。

因此，我如今都是儘可能限制使用新技術。也就是說，不會讓新產品、新團隊、新技術這三個新都同時出現，風險太大了。並且堅定不使用新技術做爲基礎技術。

咱們還犯了一個錯誤，就是正式開發的時候，咱們一上手就開發基礎框架。你們都知道一個系統的基礎框架的重要性。可是咱們卻用剛剛學會的新技術開發咱們之後業務模塊都要深度依賴的基礎框架。我想起了某公司一套戰略性的大型產品的開發：用的是新技術JAVA，你們都仍是新團隊，作的也是新產品，全體程序員都已經封閉開發了，竟然有人提出了一套本身也未通過商業規模應用驗證的基礎框架，而且本身實現了一個小DEMO。你們一看這個小DEMO很是有思想，就決定讓整套產品線都應用這套基礎框架。

我想象他們的痛，和我很神似。因此，我如今若是面臨新產品、新團隊、老技術，我都不會讓你們一上手就開發基礎框架。

去年，我就面臨了一個老團隊、老技術，可是是全新一代產品的開發。

具體狀況是這樣的，通過幾年發展，咱們的現有產品漸漸老化，因此決定要開發新一代的產品。上一代的產品是C/S結構，並且是適合單客戶使用的。此次，咱們要開發B/S結構，並且是適合集團客戶使用的。

讓上一代產品的開發團隊繼續維護上一代產品。讓新一×××發由新的開發團隊去執行。因此，咱們就招聘了新的團隊（當時公司對開發新產品有不一樣的利益衝突團體，尚未達成一致，招聘新團隊既有爲新一代產品開發作準備的目的，也有其餘的目的，形成這支新團隊的打造過程當中每每出現兩種極端：要麼好幾我的都管，要麼三無論）。剛開始並無去動手設計與開發新一代系統，而是爲客戶定製開發了一兩個其餘IT項目。因此說還算接觸了客戶行業，你們彼此在一塊兒工做也快八個月了，算是一個老團隊。

可是這支團隊對客戶、對現有的產品並不深入瞭解，雖然我給團隊屢次講解過業務，也讓你們分析學習現有產品，閱讀現有產品的說明書，根據新的業務模式也組織你們一塊兒分析業務設計功能、編寫功能設計說明書，但理解上確實還不夠使人滿意，大部分人仍是似懂非懂。遺憾的是，在老闆的規劃下，新一代的系統開發必須啓動。

若是這時候開發基礎框架，你們根本不理解之後這個基礎框架之上要編寫什麼樣的應用代碼，那麼這個基礎框架就會變成形式，之後的應用代碼怎麼都以爲這個基礎框架沒什麼用，用起來也是格格不入，不像是螺絲對螺母那樣合縫。

因此，我先安排團隊開發了系統管理工具。這是個沒有具體業務的，並且通用的，並且也是基礎框架的一部份的開發工做。可是，因爲系統管理工具，涉及到了新的組織結構模式，新的權限控制模式，這是你們不太熟悉的。並且編碼架構風格和他們以往的開發不太同樣。因此開發起來也是疑問不斷，須要實時複查代碼，實時解答問題。

終於開發完畢，咱們開了一個總結會。你們都總結了對此次開發的體會，而且討論出來之後再遇到這樣的問題要如何解決，每一個人的分工和人員配合流程再次肯定，功能和功能的用意再次給你們講了一次，對於新的編碼架構風格再次講了一次好處和用意。你們都說：若是在開發前就把這些講清楚了，那麼開發就不會遇到這麼多問題了。我說：開發前我就是這麼講的，可是你們都不理解。此次經歷過來了，就明白了。

接下來該怎麼辦？

我說：從新開發一次系統管理工具。時間爲期十個工做日。

你們都啊了一聲。幹嘛要從新開發，好不容易開發出來就這麼廢了？

我對你們說了個人經歷，我說：系統管理工具是基礎框架的一部份，是之後用戶很經常使用的工具，而這個工具倒是咱們在不清晰不熟練的階段開發的，咱們如何能把這麼重要的基礎功能交付給客戶呢？尤爲之後這個工具要和須要系統結合，這個工具的數據結構目前還沒法支撐之後的衆多鏈接，大家也看到了許多遺憾，咱們不能一塊兒步就是個瘸子。

你們又問：那過去的代碼咱們還能用麼？

我說：大家本身看須要。我既不贊同大家儘可能使用過去代碼，也不贊同所有從新編碼。若是大家想把一個有殘疾的代碼上改形成一個優秀的代碼，我說不可能，過去的不少缺陷會牽絆着你。你爲了保留過去的代碼，你就會向過去妥協，而把絲絲缺陷帶了進來。每一個人每一個功能都留了一點點小尾巴，那麼全部開發的功能總和出來的缺陷就是一個大問題。因此你們本身看着辦，先從新寫，須要用的時候本身就COPY出來。

果真，理解了清晰的功能和功能用意的程序員，開發起來很快，畢竟都寫過一次系統管理工具了，也是老技術、老團隊了。半個月完成工做。

我問：上一次大家編寫的系統管理工具代碼用了多少？

他們回答說：不到20%。明白了思路，重寫起來很快，反正沒有什麼高難度技術。原本想COPY舊代碼，發現老有關聯，摘不乾淨，還不如從新寫一個來的快。

我說：好。我們下一步就實現一個我們系統中最簡單的也是比較邊緣的一個業務子系統。在開發中你們重點發現須要什麼公共功能，我們都提煉出來，就會造成我們的基礎框架的一部份。

這個簡單的業務子系統開發了出來，我又開了總結會。

你們此次都發言熱烈：我如今終於發現了系統管理工具和業務子系統之間的關聯關係了，他們有不少代碼可以共用。因爲此次開發業務簡單，並且通過上次系統管理工具的開發，開發方法和代碼方法都已經熟悉，對於系統管理工具的認識也深入了許多，因此此次我開發業務系統的時候，還順便把過去的系統管理工具的代碼進行了重構，發現了很多能夠共用的部分。我發現，這些基礎代碼總結了出來以後，好像系統管理工具也是從這些公共代碼基礎之上開發出來的一個特殊的業務子系統了，全部子系統都依賴這個基礎代碼框架。過去原本系統管理工具的風格和業務子系統不一致，此次重構，一會兒都統一了。

我笑的很開心，彷佛我過去的心結終於能夠解開了。