新產品開發歷時1年多，總算馬馬虎虎上線試用1個多月了，目前用戶量大概300號左右，租戶大概10家左右。這裏提到一個“新“字，在我沒來到這家公司之前其實已經有自己研發的產品（物流管理系統）在使用了，為什麽還要推翻老的設計架構重新設計呢，總結主要有以下幾點：

• 數據不準確（如 庫存、結算數據等等，數據不準確時還找不到原因，需要手動執行sql直接修改數據庫數據。）
• 維護成本太大（由於開發管理不當、需求不清晰、溝通不充分。導致項目混亂，項目表結構都很混亂，業務邏輯全是存儲過程，動不動上千行代碼的存儲過程。）
• 速度慢（大量數據本地化處理，本地過多的查詢，過多的不必要查詢。）
• 用戶體驗差（用戶不會用，功能隱蔽，反人類設計）
• 安裝成本高（給用戶裝軟件的流程是：準備軟件->安裝軟件->調整參數->培訓客戶 一圈下來好多細節步驟，占據大量時間）
• 用戶隨便點點報錯（開發沒考慮好邏輯或偷懶沒想好一些意外情況，如 數據為null、超出索引等等）
• 數據安全問題（如何做到保證用戶數據的安全）

說實話要解決這些問題難度還是相當大的，當時在公司我能說只有我一個開發。對你沒聽錯就我一個，據說以前的開發經理跑路了~~~哈哈哈。但是作為開發拿到這樣的項目，不對，更貼切的叫法應該叫產品。應該是一個難得的機會，怎麽說也得上手幹一場。剛開始對公司的產品的業務非常不熟悉，許經理給我們進行了大量的業務培訓。縱觀系統其實很簡單就是幾條業務線：業務、財務、回單等等。橫向技術點有：功能授權、數據授權。其實這裏僅僅是表象，內部可不止這麽簡單。

下面我簡單介紹下物流系統中的幾大角色（可以簡單想成在淘寶購物的物流流程）：發貨人、收貨人、物流公司（含網點、部門、 司機、用戶 ）、承運公司。這裏一些名詞還是相對好理解一點，主要解決的就是物流公司這一塊，其實物流公司更像是一個集團，網點就像子公司一樣，這裏的子公司之間呢又存在業務及財務上的往來，所以說裏面業務、功能權限、數據權限錯綜復雜。要解決這些問題並非容易。

為了加快熟悉產品業務，以及理解客戶的需求。一上手並沒有直接就開始開發新版本，而是基於老軟件進行定制開發。現在1年多過去了，我還記得定制的有幾個模塊還是相當復雜的，加上老軟件缺乏文檔，代碼又不規範且沒有註釋，最糟糕的是全是存儲過程，開發起來難度很大，總結起來有一下幾點。

• 看不懂別人的代碼，不明白別人的意圖
• 不熟悉業務，需求理解不透徹，導致不斷返工
• 項目開發中節點不明確，被客戶牽著鼻子走
• 軟件遺留bug多，一邊開發新功能還要一邊解決歷史bug
• 添加新功能，新模塊影響到老功能，導致數據不準確，系統報錯等一系列問題

這個定制項目，斷斷續續持續開發了3個多月才告終，做這樣的項目真的很磨人的性格。但是這個項目做下來對系統的業務更熟悉了及客戶的需求更清楚了，在大哥幫組下對老系統的表結構以及系統設計思想有了進一步的認知，做項目的過程中慢慢把公司中各個同事的職責也弄清楚了。就技術層面老軟件很明顯的用到的技術相對簡單，客戶端直接數據庫，幾乎全部是存儲過程，UI方面用的是devexpress+winform（後面簡稱Dev），數據層用到的微軟提供的企業庫EnterpriseLibrary，嗯....感覺用這個企業庫有點殺豬用牛刀的意思，企業庫太重了，功能非常多，但是我們只用了調用存儲過程的方法。期間對企業庫有過一段時間的了解，由於涵蓋內容較多加上技術比較老，用的人已經不多了，所以沒有刨根問底的學習這玩意，緊緊處在用的層面，有時候想想還不如一個SqlHelper呢。

經過前面的鋪墊終於開始新軟件的開發之路，起初2個開發，沒有項目經理、美工、測試。全部就是2個開發，一個就是我。還有一個是小呆萌（我學弟，剛剛畢業沒有工作經驗的那種）加1個經理，經理就是我們公司的boos（後續稱大哥，還是挺佩服的，集技術、運維、售前、售後、管理於一身，也是為公司操碎了心 哈哈哈）。前期大哥貌似對項目不怎麽上心，雖然參與到項目的開發裏面來了，還是很多地方並不是很關心，只有核心技術點上與大哥有溝通。技術上選型是這樣的，還是沿用老的winform+dev這一套，但是本質有了變化新產品僅僅把winform+dev用作前端UI開發，後端服務采用的是webapi+ef，數據庫采用的是sqlserver（沿用老軟件的設計思想 單數據庫模式即所有的用戶數據用同一個數據庫、同一個數據表存放）。總的技術方向有了、總的需求有了下面就需要對系統進行細化，需要搭建框架。下面就從客戶端、服務器2個方向入手，細談第一版為何這樣設計以及這樣設計有什麽弊端，後續如何把自己埋下的炸彈給挖掉。

客戶端

基本是沿用的老方法，為兼容在XP系統上運行，選用的是基於.Net 4.0開發。由於.Net的版本限制，所以很多高級特性不能使用。簡單封裝了一些基本使用類，如序列化類（基於json.net）、api請求類（基於HttpWebRequest類封裝）、日記記錄（基於log4net）、緩存幫助類（基於mencached）、根據項目需要基本類型如Datetime、Int、String等類拓展了常用方法。客戶端中由於考慮到一下情況，初版我做了如下規範：

• 所有需要調用接口的地方采取配置文件的形式，當時之所以會這樣設計是應為考慮到，萬一服務器控制器名或方法名發生變動可以在變動代碼的前提下通過修改配置文件的形式實現快開發，這個想法出發點是好的，而且非常有利於代碼的維護，但是沒有考慮到代碼不是自己一個人寫，新開發的加入無疑增加培訓成本。而且我自己開發過程發現需要在代碼cs文件和配置文件中2個不同的地方來回切換很不方便浪費很多時間。

挖的第一個坑【采用大量配置文件導致開發效率低、培訓成本大】

服務器

這邊和老軟件相比有了本質的變化，老軟件的設計很無腦，實實在在的CS架構，客戶端數據庫直連的形式再加上存儲過程。這裏談到存儲過程，我談談自己開發定制項目自己的感受，存儲過程最大的優勢無疑是性能強悍，為什麽這麽說呢。主要是存儲過程直接保存在數據庫裏面的，僅僅需要傳輸參數就可以而且sql本身會對其進行查詢優化，就我的開發感受而言，我還沒遇到哪個技術的處理速度能夠高於存儲過程的性能的。但是存儲過程這玩意開發體驗很差，首先需要熟悉sql語法，要熟悉sql基本函數，知道遊標等等。所以說這是需要一個技術相對專業的人維護才行。但是實際情況是，面對小公司想找一個技術全面的人很難得，一般的開發在處理sql層面僅僅處在select、delete、update、add、where的層面，而將更多邏輯放在業務代碼中處理。而且別人寫的存儲過程晦澀難懂，動不動上千行的存儲過程實在讓人看著絕望，嗯...絕望這個詞用得好~~~哈哈哈。這麽分析下來還是能得出結論了，存儲過程這個技術是好的，但是弊大於利，以至於本次開發新系統直接摒棄該技術。但是不用存儲過程帶來的問題就是性能的大幅降低。為解決以上問題，結合自己積累的技術選擇了基於別人一套的快熟開發框架來進行開發。核心技術點有持久層采用的EF 數據庫優先，緩存采用的是Memcache、應用服務層采用webapi。就這樣服務器基本就完成了，亮點技術及坑總結如下：

• 可能自己項目經驗比較少，也有可能沒做過業務有這麽復雜的項目，讓我從開發系統無非是CRUD（增刪改查）的邏輯中脫離出來。為了快速開發（原因是人手不夠、自己開發封裝的水平又不高），在整個應用層面我采用了大量的T4模版結合EF框架實現的超乎想象的快速開發，只要數據庫設計好，接下來只需要簡單的配置，整個服務代碼完全ok。但是這裏需要註意的是需要一些約定，如主鍵的後綴一般采用表名+Id的命名規範等等。這種模式僅僅適用非常簡單的業務代碼開發，拿這個開發產品無疑是搬石頭砸自己腳，隨著項目的進行，業務不斷復雜，我不斷調整T4模版（寫T4模版比寫存儲過程還惡心，這輩子再也不想寫了）不斷的加入各種各樣的參數配置，使得生成的代碼更能符合業務的需要。隨著業務越來越深入，後來幾個版本的叠代中我不斷的把此技術剔除。

挖的第二個坑【采用大量T4模版，代碼寫代碼的模式，然而並不知道，需求無時無刻不在變化】

• 由於幹掉了存儲過程，這裏引入了分布式緩存的概念，在老系統中是沒有這項技術的。為何要引入該技術呢，前面有提到軟件速度慢。在沒有緩存的系統中，數據是怎麽呈現到用戶眼前的呢？數據是讀取硬盤中的文件加載到內存中最終呈現到用戶的眼前，那麽引入緩存的概念呢，直接讀取內存，讀到數據根據緩存鍵直接返數據否則取硬盤數據。由於讀取內存中數據的速度遠大於硬盤，所以說緩存的引入無疑是極大的提升系統的性能。原理雖然是這樣，如何對數據進行緩存。哪些數據需要緩存？哪些數據不需要緩存？如何管理緩存鍵？等等一系列問題撲面而來。在系統開發過程中需要進行緩存的總結幾點：1.不經常改動的數據；2.大量使用的數據。如果在系統中發現這樣的數據，那麽應該將他們進行緩存處理。比如：用戶信息、公司信息、菜單信息、功能信息等等都是需要反復使用而不怎麽修改的數據，我們應該進行緩存處理。試想：每次請求過來要進行身份校驗、權限校驗、數據校驗等等都查詢數據庫的話，數據庫壓力可想而知。
• 由於框架中對數據上下文（ef連接對象）在數據層進行了緩存處理，在後續的開發過程中總是會出現許多莫名奇妙的錯誤，比如：EF常見的報錯，百度一搜一大把的那種、明明修改成功了，再次查詢後卻是修改之前的狀態等等一系列問題。出現這樣的問題，我花費了大量時間去找資料、請教前輩來解決。在搞明白基本原理的前提下，後續幾個叠代開發版本中，慢慢調整框架使他更適用。

挖的第三個坑【最求高大上技術（不是特別熟悉的技術）有時候並不能有效解決問題，往往還有可能存在風險】

• 數據層核心就是EF這裏我對其進行了簡單的二次封裝比如（增刪改查），關鍵點就是微軟推薦我們先把數據查詢出來，再進行數據的更新。但是實際使用的過程中發現這樣效率並不是很高，而且生成的Sql不夠簡潔，比如一個表多大上百個字段時，我只想修改一個字段，ef生成的sql腳本確實更新所有字段。基於以上的分析，對ef拓展了很多實用的方法，以至於到現在，這些方法都是必不可少的核心。
• 寫了個輔助程序，讓實體類能夠自動加載數據庫中的字段註釋。雖然是個小東西，但是能省下非常多的時間，留下更多的時間去做更有意義的事。

數據庫

數據庫是重中之重，軟件設計的好不好就看數據庫了，有時候會多加一個冗余字段你會能夠讓你少寫很多代碼，能夠大幅提升系統性能。在實際經驗下發現，綜合考量下來遵循範式設計的系統要比不遵循範式設計的系統就性能和用人方面而言，相差很大。其實很多時候，記住一句經典的話“把數據庫設計的和excel一樣！”雖然這樣並不是很科學，也許這樣設計在學校裏或其他公司中會成為笑柄，但是實際開發過程中的經驗所得，確實是如此。簡單的設計會免去你很多煩惱。相比較老軟件而言新架構的大變動如下：

• 數據庫主鍵的技術選型，sql標準主鍵3種方案：1.guid類型（優點：全球唯一，速度快，缺點：占資源，冗長，不利於索引維護）；2.自增（優點：自動編碼省心，缺點：主鍵自增的特性 數據遷移可能會有麻煩）；3.用戶自定義（註意不要重復，自己定義規則）。我們選用的是用戶自定義，采用的bigint也就是長整型做主鍵，主鍵統一為18位。用的是SnowFlake，我自己給他起了個別名叫“分布式id生產器”，其實這個方案是大哥極力推薦的，但是實際使用中還是面臨許多問題，首先看他名字就知道不簡單。既然主鍵在客戶端生成那麽他的原理還是先有客戶端請求服務才能拿到一個可用的主鍵，而SnowFlake通過機器碼和數據中心2個產生支持多個服務器部署能夠滿足大並發。SnowFlake原理還是根據時間和那2個產生來動態生成主鍵的。仔細考慮後發現，多多少少會損耗性能的，至少需要網絡傳輸呀。還有一個弊端就是分布式id生產器宕機會直接導致系統奔潰等等一系列的問題會暴露出來。但是幸運的是目前還沒有發現這樣的問題。原理圖參見下圖

• 默認數據表都應該含有的字段：租戶標識、創建人、創建時間、修改人、修改時間、邏輯刪除標識、備註。最初除中間表外我們規定每個表都應該還有這幾個字段。基本每個字段都是比不可少的主要用於數據追溯，如客戶發現數據不對了找到軟件公司，軟件公司應能夠做到數據被修改原因的追溯，從而規避問題，將問題放到指定人身上去。能夠知道最後是誰動數據的。邏輯刪除用於用戶誤刪除數據恢復。然後在後續的開發過程中發現會有同一人修改相同數據，這就沒法保證數據的一致性，由於考慮不周加上自己的懶惰想當然的用修改時間來控制，前期沒問題，很順利，但是忽略了一個細節就是修改時間只是用戶對數據進行修改時才會改變，那用戶不修改數據，數據由於其他模塊導致變動版本怎麽控制？我們發現這個問題時，產品已經上線了。最終不得不把每個表額外加上一個標準字段版本號，這樣才從根本上解決了問題。

挖的第四個坑【不要由於偷懶而忽略一些潛在風險，時間會將問題慢慢放大，如果不及時修改，可能導致產品研發失敗】

基於以上思路帶著小萌新開始了新軟件開發之路，隨著開發不斷深入，把系統中的幾條關鍵邏輯線路全部走了一遍。第一版ui基本就是拖拖控件出來的，沒有太多華麗的設計，也沒有考慮到用戶體驗。期間遇到大大小小很多問題，包括技術上、業務上都有。隨著開發的深入，測試時會發現還會存在的性能的瓶頸，所有模塊還是很慢。期間我看過ABP框架的設計結合老系統發現，如果需要徹底解決問題，只能分庫。一個租戶一個庫，這樣方便系統的拓展及分布式部署。租戶與租戶之間數據隔離，也保障了數據的安全，某個節點數據服務崩潰不會導致全線崩潰等等優勢。凡事都是有利有弊，弊端就是數據庫結構發生變化，子庫需要同步等問題。但是綜合考量下來，分庫的優勢很大。基於這樣的分析，有想法得有行動，很快我就對系統進行重構。數據庫改動較大，分成主庫（也可以理解為路由庫）和子庫；應用服務器首次改動比較保守，沒有傷筋動骨。但是隨著開發的進行問題會暴露出來，問題是何時用主庫上下文？何時用子庫上下文？這麽多數據庫對象如何管理？等等問題全部暴露出來.....真的是牽一發而動全身。起初是通過配置文件進行控制，開發前幾天發現還可以，但是隨著開發的進行會發現真的是各種場景都會出現，同一接口中會出現主庫上下文、子庫上下文....等等一系列讓人頭皮發麻的問題，實在沒有辦法，對應用服務器做了很大的改動，幹掉了2個封裝的dll，直接3層，服務層->業務層->數據層。簡化數據訪問，重新封裝了數據庫訪問接口，采取短連接的形式，一句話概括也就是“及時用，及時放”的策略，這樣的設計架構。清晰明了，免去繁瑣的配置。這次大改動足足化了一周的時間才完成，以至於這樣的架構模式沿用至今都沒有大改動，能夠適應各種業務場景。哈哈哈 一周的努力沒白費。經過這樣的折騰，加上客戶及Boss的壓力明確提出產品要盡快上線。加上之前客戶端不是我著手開發（前期寫了點，後續全部交給別人了），服務端穩定一段時候後，接著著手客戶端的開發。最終系統架構參見下圖

直接上手就是對控件進行一頓2次封裝，免去每增加一個控件時都需要設置一堆屬性的煩惱。基本控件都是很順利的完成。但是有的控件很復雜涉及很多東西，如 gridview控件要做到 樣式的統一、默認右鍵菜單、懸浮按鈕、焦點行 熱點行的數據獲取等等。起初由於開發人員較少，我這邊沒有經過大量測試直接將代碼提交到開發環境供開發們使用。起先封裝的少，代碼也能夠理解，沒有暴露問題。漸漸的隨著不斷有新開發加入進來，會發現封裝寫的太死，引入新功能導致舊功能不能用的事故非常多，而開發總是埋怨我這邊做的不夠好。後續只能先自己做足測試，給開發做好培訓工作之後才穩當的使用自定義控件。

挖的第五個坑【產品叠代開發到一定程度，涉及到核心的封裝代碼改動，一定小心再小心，否則等待的將是拆東墻補西墻，到處改動】

挖的第六個坑【封裝的東西一定要活，寫的不夠靈活，後續遲早要還的】

在第二版本的開發過程中還會發現，在應用層接受數據時和應用層響應數據時，往往不是實體類，而是視圖模型。這裏就需要建立大量的視圖模型，服務器響應好處理，直接返回匿名類。客戶端接受服務器響應的數據直接采用反序列化就可拿到數據。關鍵在新增數據的時候 往往會出現 視圖模型的數據需要賦值給實體模型，這些代碼幾乎無腦，但是他是存在的，無法規避。如果手動編碼會占據大量的時間來維護。這裏用到了對象轉化利器AutoMapper，該組件通過簡單的配置即可實現視圖模型與實體模型之間的轉化，剖析原理可能采取反射或者emit的技術實現的映射，為測試性能，我自己寫反射與用AutoMapper進行性能測試發現AutoMapper性能更快，但是AutoMapper肯定沒有手動賦值速度快，但是和手動寫一堆代碼而言，這點性能還是能夠接受的。

經過這一圈的折騰從服務器寫到客戶端，再加上開發的努力，產品似乎有了點雛形。其實這才是開始，隨著項目越做越大，主要還要面對2個問題。1.新模塊的介入；2.舊需求的改動。其實這是2個很讓人頭痛的問題。你必須全盤考慮，系統各個模塊之間數據的流轉、同步；特別是庫存數據和財務數據必須做到分毫不差。最讓人頭疼的就是舊需求的改動，其實這也是程序員（開發）非常抵觸的，好不容易開發出來的模塊，由於沒有考慮好又被推翻重做內心坑定是崩潰的。做項目還好，需求入口的口徑只有一個，關鍵是做產品，需求來自五湖四海，每一家的需求不一致，除了要考慮軟件的健壯性，數據的準確性之外，還得考慮這個功能其他家是不是也需要，是不是也合理等等。盲目的叠代升級，往往會拖垮軟件的性能，導致軟件顯得臃腫，一個好的產品應該易用，功能全面而又簡單。

在我們設計軟件的時候，我也服務過客戶，很多時候客戶的思維和專業軟件設計人員的思維往往相差甚大。用戶真的是什麽操作都有，真的是喜歡這裏點點那裏點點，如果軟件不夠健壯，面臨的將是到處異常。而且用戶可能會因為少一個字段，多操作一個按鈕而吐槽說軟件不好用。而且使用軟件各個層次的人都有，他們受文化教育程度也不一樣，年齡也不一樣。有的連基本的電腦使用都不順暢（無法區分鼠標左右鍵的大有人在），年紀大的人可能會由於軟件字體小而吐槽說軟件不好用。所以呢，設計軟件你得把用戶當傻瓜對待，操作一目了然、減少用鍵盤、鼠標的操作的次數，這樣設計出來的軟件才能覆蓋到更多的用戶群體。

隨著客戶量的增長、開發團隊的擴張，由於項目急於上線，很多模塊需要開發，系統架構要優化，數據庫表要管理再加上分庫了，表結構同步問題，升級問題，軟件測試等等一些問題。我犯的最大的錯就是所有事都是自己幹，核心代碼自己寫、普通業務代碼自己寫、小工具自己寫（如：輔助升級工具、數據庫同步工具、用戶管理工具等等）。漸漸發現很多事情都做不好，自己很是力不從心。唯一的解決途徑就是，一個要相信自己的團隊有能力把事情做好，而且要相信他們能比我自己做的更好。只有不斷的放權，相信一起開發的夥伴這才是體現團隊價值的時候。

挖的第七個坑【切莫所有事情都自己躬親做，把事情交給合適的人做，效果會更好】

在持續不斷的和同事溝通，安排任務。協同開發過程慢慢發現，其實管人比管項目更難，換句話說也就是“情商遠比智商”重要，不不不，這邊不能用肯定句，應該分條件來區分了，要看自己處在什麽層次，如果自己是剛踏入社會的小萌新，還是要專業知識強硬一點往往會好一點。等自己到管理層，情商遠遠比智商更重要。可以這麽理解，對事用智商、對人用情商。再總結一句話：“情商高、智商高 如魚得水；情商高、智商低 幸福生活；情商低、智商高 懷才不遇；情商低、智商低 路邊乞丐”。我想大部分人都是包括我也是，剛踏入社會，很是任性，天不怕，地不怕。其實這樣很難在社會立足。我本身就屬於情商低，智商也不高的狀態，摸索如何有效的管理公司以及讓公司的產品能夠快速開發上線也很艱難，以至於到目前為止我還是不能夠有效的管理。

挖的第八個坑【切莫認為智商比情商更重要】

到目前為止公司的開發幾乎全部加入到新產品的開發隊伍中了，到目前為止業務上的代碼幾乎全部交給之前提到的小呆萌接手，雖然前期技術很一般，給人感覺能力也不夠，慢慢培養並相信他有能力把事情做好。事實確實如此，基本能夠把問題處理好。這裏提到的基本，也只是基本。效率非常差勁，公司急需一條體系，就像生態圈一樣平衡穩固發展的那種，但是我又沒這方面的經驗，不得不我請教了很多創業的老板、同學以及其他公司的老板等等。發現每家的管理體系都不相同，首先公司有大有小，大公司部門職責劃分明確，部門多，員工績效項目管理等體系完整但是這種模式並不適用，我們公司更像發展中的小公司一樣。而且我們公司一致被我吐槽的一大詬病“非常不願意寫文檔”，期間為管理好項目，協同辦公嘗試過不同的bug系統，在處理問題時效率是有所提升，但是還是不能按時完成任務，我們處理問題的一般流程是：測試測出一個問題->口頭告知開發->開發核實確認->修復問題->升級系統，就是這樣的模式進行，最大問題出在，1.開發不能夠明確的理解錯誤原因；2.開發完成後不測試直接說沒問題升級吧。導致一天升級次數達數10次，很多時間都浪費在系統發布上。由此還開會對開發反復強調這樣的問題，問題還是有所改善的。有時候也會想到扣員工的績效，出現問題追究負責人算績效，我想大部分公司都會有這樣的措施或方案，但是自己想想不到非常不得已還是不要這樣好了，畢竟這些兄弟一起做這個系統，都是經歷過從0走到1的，往往第一步是最難的，我也希望都能做好自己份內的事，我們公司“永遠“不要出現績效考核。

一直保持這樣的節奏，很快項目上到生產環境。產品設計之初是準備有3個獨立環境：開發環境（開發人員使用）、測試環境（測試人員使用）、生產環境（客戶的真實使用環境）。由於頻繁升級，加上自己的懶惰，沒有好好利用測試環境。而是讓測試人員直接在開發環境中測試，我就這樣親手給產品埋下了一顆炸彈，起初升級都很順利。開發環境中測試這樣的隱患非常大，直到有次，我們為加強系統安全性，對用戶的密碼進行密文保護後，開發環境中很順利沒問題，但是提交到生產環境時導致客戶沒辦法升級，後果可想而知，所有用戶無法完成自動升級，以至於化了2天公司客戶、開發全部介入進來手動給用戶升級...這段時間我是天天被老板罵的狗血淋頭。當時就想想要是測試環境中測試就能發現這樣的問題了。在這次事故中主要責任還是在我，沒有保證好產品的穩定發展。除主要責任外，次要責任主要有開發代碼不過關。考慮不全面等等。這次事故中主要總結一下幾點。

• 測試永遠不要相信開發的代碼，在小的功能都要測試
• 不要被上級的壓力，客戶的需求亂了陣腳
• 不確保升級生產環境沒問題，再催也不升級

直到測試環境正式用上後，不同部門的人在不同的環境中工作，到目前為止再也沒出現過類始於上次那樣的大錯誤。之前提到被老板罵的狗血淋頭，這裏老板罵的再兇這個鍋也要接好，千萬不要亂丟。為什麽這麽說呢，不能丟，大家夥都在為產品努力本身壓力很大，在加上任務是我安排的，自然邀功主要人也是我，要是把鍋甩出去，問題就大了，鬧不好可能會出現手下夥伴不滿，導致產品核心開發流失等等更大的問題出現，所以記住“背鍋比邀功更重要”。只有這樣才能讓團隊更好的發展。

後續隨著產品的叠代、用戶量的激增還會面臨更大的挑戰........哈哈哈

......

持續更新

......

後記

期間碰到的許多問題，如果全部拿出來分析怕是3天3夜也寫不完~~，只是挑選一些比較大的問題闡述。小弟不才如有大佬能夠指導如何更好的優化系統以及一些技術的推薦或建議可以給我留言~~~最後真心感謝大哥、公司各個業務員、開發同事的一起努力。

產品開發經驗總結-讓你少奮鬥一年的經驗之談