離開XXX項目已經快半年時間了，其實早就想寫點什麼分享一下在這個項目中作爲SE的一些感觸，但又總是不太想再提及這個項目，也許就是那麼一點沒有達成而不甘的情緒吧(在這個項目轉驗收測試階段後，被安排一個出差任務，從而脫離了該項目)。現在半年時間過去，回過頭來再看這段經歷，心裏更多的是幸運和感激。其實一直蠻幸運自己能有機會參與這個全新的開發項目，更加幸運自己能擔任SE這個難得的角色，也是這個項目讓已經5年多沒有接觸代碼和項目開發經歷的我又重新燃起了對技術的熱情，也是這個項目讓我那點部件/模塊級的開發經驗初步提升到了系統產品級。總而言之，機遇難得，獲益良多。
其實在這個項目之前自己在SE這個角色方面並沒有什麼經驗，所以這個項目中自己其實是有不少教訓的。其實犯了錯並不是什麼可怕的事，我相信經歷過纔會快速成長。
1，作爲SE，不要迷信或者輕易相信自己不熟悉的技術方案
這個項目是由一家合作方按照我們的需求來開發，憑藉合作方十幾年在這個領域的經驗積累和知名度，我們之前非常看好他們的技術實力。合作方自己積累的兩個基礎開發平臺（一個是電信領域的底層基礎平臺，一個是IT領域的應用開發平臺）也曾經一度被當成他們技術方面領先其他廠家的一個重要因素。就這樣，在項目設計和開發階段，很自然的認可了合作方基於原有架構和平臺進行設計和開發的思路，儘管在討論方案的時候對此也出現了一些質疑的聲音，但卻沒有誰否決掉這樣的思路，畢竟項目初始階段大家對合作方技術和架構的瞭解都非常有限，而且項目的技術主體是合作方他們自己。而正是這樣的輕信，導致了項目後期出現了架構調整和重構問題。
爲什麼會出現這樣的問題呢？ 其實原因也很簡單，十年前左右做軟件產品其實還較難找到第三方的開源框架和基礎庫借鑑，要做產品就得自己封裝，注意技術積累的公司就會形成自己公司內部的基礎開發平臺或開發庫。然而這些年開源項目的飛速發展已經改變了這種局面，大量優秀的第三方開源項目涌現出來，並被廣泛應用，無論從結構合理性，規範性，穩定性方面一般都強過這些公司的私有技術。
所以SE對技術方案一定要有自己的瞭解和判斷，需要積累豐富的技術經驗，迷信或者輕信自己不熟悉的技術方案實際就等於是放棄了SE在項目中最關鍵的職責。
2，設計環節不可缺失。作爲SE，要確保設計和方案切實落實到具體的實現中去
以項目的方式運作，很多情況下都是強調短頻快，把需求分析完，把模塊一劃分，開發人員就領着自己負責的模塊去Coding去了。然而有意思的是，在開發過程中如果你和開發人員去深度交流，往往發現那個模塊的設計是缺失的，即很多開發人員在自己沒有想清楚，甚至需求都還沒理解透徹的情況下就開始憑着直覺和經驗動手去實現了，也不管原來的經驗是否適合現在這個項目，這樣做的風險不言而喻。
設計不一定要求是詳細的設計文檔說明，但設計一定要能夠表述出來，交流其實也是一種方式。架構師也不是把系統架構一定，把設計規格一寫就完事了，作爲架構師必須要確保設計和方案切實落到具體的實現中去，所以開發過程中架構師必須多和開發人員交流，甚至根據開發人員的代碼實現反過來評估是否符合設計要求。
在這個項目中的開發階段，雖然自己一直也在參與，但都主要精力都分配在輔導需求理解，具體產品要求，開發質量方面，誠然這些關注點也是保障項目成功必不可少的，但這其實都只是過程保障，和SE最核心的職責還是有些偏離，這也多多少少導致自己缺少精力深入到具體實現中去。直到發現設計環節的缺失問題，開發人員自己都講不清楚實現方案(經不起推敲)的時候，自己纔開始深入一個核心模塊，根據代碼實現反推那個模塊設計（其實這個過程也很快），得到的結果讓自己一下涼了一大截。這個項目的實際情況也是那個原來用C++開發的核心模塊後來第一個被用Java倉促地重構了。
所以SE需對系統模塊的重要度，技術風險有清楚的認識，雖然這些模塊不是SE去親自實現，但SE必須要對這些模塊的實現瞭若指掌。在開發階段，SE需按照模塊的重要/難度順序，多和各個模塊的開發骨幹進行深度交流，瞭解開發人員的設計思路和實現方法，只有把設計定下來了，實現纔不會偏得太遠。某定而後動，就是強調一次把事情做對，這樣纔是高效的做事方法。
3，作爲SE，往往都希望追求完美，但SE卻要清醒的認識“羅馬不是一天建成的”
因爲將這個項目的第一個版本就定位成產品的商用版本，而商用版本除了基本的功能特性要求外，對於電信級產品還要滿足可服務性和可靠性要求。其實這麼多要求放在一起是很難保障這些要求都能按時實現的（實際度量第一個版本代碼量達到15W行），架構師必須對這些要求進行關聯和優先級排序。對於產品或者版本當前沒有能力做好的特性，架構師要敢於砍掉或者重新規劃，寧缺勿濫。
這個項目中合作方因爲具備十幾年電信級產品的開發經驗，其產品的可維護性理應是他們的優勢和亮點，也許也是我們要求較多然而投入有限（只有1人負責），在項目後期雖然已經察覺到管理模塊的粗糙問題，但錯在自己沒有去決策，而是把這個問題提出扔給了合作方的項目經理，結果版本在測試階段可維護性方面成了重災區，本該成爲優勢和亮點的產品可維護性反而成爲了雞肋，而不得不砍掉幾個不太重要的特性
這個項目的問題其實還遠不止上述這些，這裏就僅從SE的角度總結了一下，這些問題導致的後果就是這個版本在3輪驗收測試後又不得不安排一個月的時間進行結構調整和重構。那麼，這個項目中又有啥正面的經驗值得總結呢？
1，吸取成功經驗。
雖然這個項目在一些模塊的設計上出現了一些問題，但整個系統的設計在項目初期借鑑了一些專家提供的經驗和建議，所以在系統層面的設計沒有出現大的失誤，後續的重構和調整基本也沒有涉及到系統的核心和基礎設計，系統的業務流程，處理性能方面符合設計目標
2，採用正確的解偶方法
該系統的業務邏輯要求比較高的定製性，那麼很容易想到的一種做法就是把這塊獨立出來，即解偶。在討論設計方法的時候有兩種意見，一種意見是把這塊業務邏輯封裝成jar包，然後部署到各個模塊中去，各個模塊利用這個jar包即可獨立完成一些相關業務邏輯處理，但這個方法有個問題就是升級的時候涉及的模塊較多；還一種意見是實現一個獨立的模塊集中提供業務邏輯服務，這樣升級的時候只需要更新這一個模塊即可，但這個方法有個問題就是多了一層交互通訊，業務處理流程也變長了，相應可靠性風險也大了。這個項目還是聽取了一些專家的意見，採取了第一種方式，畢竟這種方式模塊部署簡單，集成度高，而只是少許犧牲了一些可維護性方面的代價。
3，設計原型驗證
這個產品設計爲滿足上千萬用戶的系統，對數據庫的性能要求比較高，所以在項目初期有考慮採取內存數據庫的方式，減輕物理數據庫的壓力。但引入內存數據庫無疑也增加了系統的複雜性，所以在項目初期就針對這個設計安排進行了一些原型驗證，結果發現效果其實並沒有預期那麼管用，於是果斷放棄了這個設計，現在想想這個決策非常關鍵。
4，測試打造設計
其實在敏捷開發中就非常強調測試驅動，肯定有其道理。這個項目也是深刻體會到了“測試打招設計”的含義，這個項目中也正是單元測試的要求在開發階段早期就發現了原平臺和架構方面的問題。爲何這麼說，這個項目我們從啓動開發就要求進行單元測試，但卻發現這個單元測試很難做起來，開始還以爲只是開發人員的意識問題，後來深入瞭解才知道原來是使用的原平臺太厚重了，層層依賴導致測試一個單元函數都非常困難。測試手段其實就像模擬一個用戶來檢驗這個系統，同樣也能檢驗這個系統的設計，所以測試不是在開發完成後交給測試人員再開展的活動，SE和開發人員需多從可測試的角度來設計和實現。