電子商務網站的可持續發展

轉載自javaeye。作者的切身體會。

[@more@]

電子商務網站的可持續發展

2007年終於過去了，從焦油坑裡爬出來倖存的人們，互相握手慶幸，喜極而泣，紛紛在部落格上寫工作總結與來年展望，而我終於厭倦了期權的精神鴉片，難得的坐下來，遠離自己負責的網站，想一想來年的佈局。

在國家大力宣揚環保，可持續發展的時候，從企業，從網站，就我個人，都要講一個可持續發展，一夜暴富的思想只會浪費精力，沒有方向，而只有平時注重積累，厚積薄發，終會有從量變到質變，扭轉局面的時候。

我們發力在向前奔跑的時候，也要適時的停下來，倒掉鞋子裡的沙子，讓自己的步伐更輕快。

我所經歷過電子商務網站都面臨的下面的問題，如何讓自己步子慢下來，解決這些問題，持續發展，是一個從管理和技術層面上，都比較有挑戰、讓人興奮的問題：

1.膨脹

公司業務向好，程式碼越加越多，原來一個人寫一個類時，只是完成一兩個單一的功能，隨著需求的變化，一個核心類的程式碼，不知不覺膨脹到一兩千行，有的Action程式碼，也會超過1000行。接手的人，一般不敢動，也不願意動接手的程式碼，也就是說，他不會去重構以前的程式碼，一般就是線性的隨著需求的增加，程式碼也不斷的增加，同時在開發時，總是八股文開發，很機械、迂腐的套用一些重型的、所謂的J2EE設計模式，如Factory, DTO, Proxy等等，程式碼量和程式碼複雜度最終是線性增加。

則程式碼複雜度和行數的膨脹，會是負面迴圈，反過來影響你面對需求變化時態度。

舉一個例子，從使用者角度來講，訂單上增加一個欄位的小需求，應當是很簡單的一件事，但是對開發人員來說，增加一個欄位，則要確認所有與訂單相關的頁面（相關的介面可能有十幾個）都要修改、重新佈局，這個工作量可不小，而且容易漏改。這不是一個容易避免的事情，不僅是頁面，類也要修改。很多人寫的關聯查詢，結果放在DTO類而不是Map,扔到頁面上的話，則DTO類也要修改。

一般的效能問題，總是由開發人員的程式碼造成的，而不是由架構的Scalability瓶頸所造成的，累積的程式碼，就像電器上日積日厚的灰塵一樣危險，隨時會短路。以前的殭屍程式碼，會在資料量和訪問量慢慢增長到某一個臨界值的時候，突然復活，搞得你灰頭土臉。 如果你只會批評開發人員不小心，那種永遠也解決不了問題，讓誰寫，都不能保證不會踩上地雷。領導不出BUG，只是因為他們不寫程式。

3. 鐵打的營盤，流水的兵
第一個人下棋，下到中途，離開了，第二人接手，接著下，以後可能會有第三個人，接手的人，怎麼下怎麼不順，這時總想重新下一盤，但沒有選擇，只能一邊問候著前人的老媽，一邊繼續走。最後，我們再把這盤棋覆盤來看，做成一個棋譜，會有什麼的感覺？

這一般不是兩個人能力差異的問題，是一個心理的問題，每個人都不願意看別人的程式碼，都覺得別人的程式碼寫的爛，不願意花點時間，來review同事或者前人程式碼，他們認為這是考古學家的事情。這樣的結果，如果不瞭解別人的程式碼，就無從重構，在此基礎上增加功能或修改，只能說是亂上加亂。

要包容別人的程式碼，現在不是找出是誰造成的，而是要從自己接手這一刻，開始改進。

打江山的人，所基於的環境，是非常惡劣的，是非常不容易的，從無到有的建立一個網站的老員工，一個人做三個人的活，是非常值得尊敬的，接手別人，再怎麼說，也是站在別人的肩膀上考慮問題。其實讓你先下，讓第二人再接手，他也會這麼有同樣的思維，我們需要的是寬容，寬容與諒解應當是自上而下的，而不是自下而上，不然就變成，專案經理說：我體諒你們，可領導不體諒我啊。

4.新來的員工不是考古學家

新來的員工抱怨個不停，確實是很討厭人，另一方面，從他的角度上來講，沒有選擇的權力，必須在別人程式碼的基礎上增加新的功能或修正一些BUG，你不能用你最擅長的東西，當別人的程式碼是JSP+Servlet，你就用這個，你必須要遵守這個規則，同時也要遵守別人的開發習慣。

新員工就像一個考古者，站在一段象形文字的文物面前，來想出前人的意圖，確實非常的艱難。

所以每個公司的每個專案組，都應當向HR部門學習，制訂一個良好的新員工入門索引，這個索引有什麼內容，每個人根據自己的專案，自己來考慮。這樣的索引目錄可以重用，不用來一個要講一遍，佔用專案經理的時間。

一般的人，都是被動的，8個小時，怎麼過，都是過，平時不會去看別人的程式碼，只是在自己承擔一個任務時，才會去看那些相關的程式碼，這樣就會時間太緊了，手忙腳亂的，容易出錯。所以在平時，就要強制性的review程式碼，是必須要的，你不能信賴別人的主動性，否則的話就是自食苦果。

5.脆弱的測試體系

長期膨脹，得不到改進、重構的程式碼，每有新功能開發，測試的代價非常、非常的高，因為非常容易犯錯。

很多的公司並沒有一個良好的自動化迴歸測試體系，所帶來的人工成本就是非常高，測試人員所做的工作，就是民工扛水泥包，又髒又累，測試覆蓋的效率又差。

頻繁ReOpen的BUG，會牽累process當中每個環節的人，配置管理員，測試人員，開發人員，TeamLeader，也會影響到考核。帶來的眾多的參與其中的人，隨著運轉，打標籤，提交測試，打回，修改、再打標籤、再提交測試（此時所有開發人員的BUG都要改完才能提交），測試人員重新測試（原來已經測試透過的功能，還要再測試一遍），重複N次。

其實我們自己從開發，到測試部門，都可以不要對立，坐下面交流，來去考慮如何改進。測試部門可以指導開發樹立測試的意識、思想、技巧，開發人員必須要承擔測試，不僅要寫單元測試，也要做功能測試，也要會自動化測試，這些除了可迴歸的單元測試，很艱難，不容易做，但可以一步步的改進，其它的比如自動化的介面測試，其實是很容易的，花個兩天時間，把成員關在會議室裡，搞Win runner介面測試，編寫可重用的測試指令碼，定製有效的、覆蓋關鍵路徑的、可重用的資料來源，還是能收到成效的，這樣當需求變化時，那些沒有變化的功能，其指令碼也不變，都可以在短時間內迴歸的測試一遍，而不要把成本直接轉嫁到測試部門。

關鍵是要不要走出第一步。 不知道為什麼領導總是願意相信冶百病的偏方，相信永動機，相信不會犯錯，專案不會延期、百戰百勝的神人。 不要再花錢找一些天橋說書、賣大力丸的QA了。其實沒有一個人可以驅動一個龐大的團隊，還是要靠團隊中的核心都行動起來。

5.缺乏從宏觀層面技術標準的概念統一和定義

隨著業務的發展，有很多的合作型的專案，子系統越來越多，同時要外接的系統越來越多， 做為一個分銷的平臺，可能要和外接的B2B系統對接，即要給別人在公網上釋出介面，又要從第三方的系統獲取產品資料來源，這種系統與系統之間的資料交換，缺乏統一的標準，各種各樣的技術都可能有，又有不同的專案組負責，各自為政，這不是他們的問題，他們不是CTO，不是架構師。

從全域性的基礎上，對系統的服務基礎設施建立一套共同的抽象規範，從架構師的層面，進行控制。

主要有：

1.服務的分類（支付閘道器、訊息閘道器、中央工作流引擎、中心快取服務、外部資料來源對接服務、B2B訂單預訂介面服務等），以及各類服務的設計原則和建議

2.服務的技術標準定義與約束，耦合關係和原則的設計規範等

3.服務呼叫的介面詳細定義與約束，如此服務所支援的併發數的限制、超時呼叫的限制等。

4.統一技術標準和約束（如統一使用spring, ibatis, struts2, jquery等），不濫用，注重有效積累， 減小對後來的人增加維護難度，但確定下來的技術，新來的人都要強制先學習，從心理上接受這些技術，先期消化這些技術曲線，避免臨陣磨槍，好事變成壞事。

5.被動的迎接變化,缺乏主動

規劃是很重要，但總有跟不上變化的時候，不可能有一勞永逸的架構和平臺，初期業務和業務系統都是不成熟的，你在做一個系統時，可能只有兩三個人的團隊，所做的也只是一個初期的業務，你不可能想到，未來我的系統可能要與114合做，要與某某網站合做，當這個變化來時，你才能去做這個設計。

例如你只知道大陸酒店的業務，當你的業務要擴充套件到香港、海外的時候，他們的業務規範與國內的差別非常大，新的業務有可能在推翻你前期的設計。

你的系統要和某某網站一個合作業務，要個某某銀行合做一個信用卡聯名卡業務，這些合做型的專案，對方都是強勢的，你不是規則的制訂方，你是接受規則的一方，你在欣喜公司的業務蒸蒸日上的同時，恭喜你！你的系統的複雜度，也在蒸蒸日上。

唯一的辦法，就是要去主動的重構，對系統和程式碼的複雜度降維，輕裝上陣，在一個更有利的位置，擁抱變化。當然重構不是陽春白雪，不慎會帶來新的不穩定因素，只要是對程式碼進行變動，都會引入風險，特別是遺留程式碼, 你在擦拭灰塵的時候，卻不小心把桌上的瓷器給打破了，這時候主人肯定不會表揚你的勤勞。不管怎麼樣，這是你負責的專案，你跑不了，主動一點，總比束手待斃強。

6.人力的焦油坑

人月神話這本書，只是給出版業帶來了繁榮，平時的我們總是一遍又一遍的從一個焦油坑出來，又掉到另一個焦油坑裡去，可見看書是沒有用的。

由於難以維護的系統，總是拖累正常配置的人力，使你感覺到人手總是他媽的緊，連正常的需求開發、BUG修正都滿足不了，那有時間重構。所謂人力惡性迴圈，就是好不容易一個熟悉程式碼的人，培養起來，他也厭倦了，拍屁股走人了，再招人，就得招兩個人，因為系統的複雜度又增加了，需求又增加了。

這樣的結果很可怕，沒有時間來與時俱進，沒有時間做提高使用者體驗、有價值的、增強使用者粘性的功能了，沒有創造性的工作，那些有創造力的人最終會含狠而去。

增強人力資源的儲備和技術儲備，是一個有效的措施，在平時做，而不是到關口了才想起，手忙腳亂的。

招聘人，要招self-proactive的人，能夠帶來變化，能夠解決問題，而不是抱怨的人，等著媽媽把飯嚼完送到嘴裡的小鳥，否則就是效果相反，就造成了，加人，越加越累，因為你所加的，都不是解決問題的人，而且加人的時機也不對，平時，都沒有儲備，關鍵時候，才想起要人，太晚了。

考慮一下，隨便招一個普通的程式設計師，對於周圍關聯人的影響和所帶來的成本：
增加一個測試人員的工作量（可能他的BUG增多），增加美工的工作量（他不會寫頁面，不懂JS,不懂CSS），增加專案經理的工作量，增加TeamLeader的工作量（做培訓計劃,講需求，講技術)，增加DBA的工作量（因為他不懂資料庫，老寫一些讓伺服器心臟博起的SQL 程式碼）。

7. 鬆散的組織架構

一個網站，大的網站，幾十個頻道，一般的也有十幾人專案組，他們在維護同一個網站，彼此之間的聯絡很多，共同點也很多，看起來應當統一，都是自己人，也不難統一，但是現實卻是非常的艱難，卻如此的鬆散。

任何東西，自下而上，所帶來的必然是混亂和無序，考慮一下從組織架構上來改變，建立CTO team，從全域性的範圍內，自上而下的推動、控制，加強全域性控制力，改變各個頻道或專案組各自為政的情況。將複雜的東西控制在上層，而不是程式設計師中間，任由其蔓延。

改變架構師缺位，吃白飯的現狀，公司不是養著架構師，學習新技術的，滿口之呼者也，酸腐的人，誰都要學習，但要去一線解決問題。

架構師要有責任，要有技術領導能力，要去Push別人，當開發人員在造輪子的時候，首當其首，責任就是架構師，如果開發人員在重複，還要你架構師做什麼？很多開發人員自己寫，是因為沒有辦法，他也不想寫，但是現有的程式碼庫當中，沒有，或者沒有他適合用的東東。