產品開發經驗總結-讓你少奮鬥一年的經驗之談
新產品開發歷時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夜也寫不完~~，只是挑選一些比較大的問題闡述。小弟不才如有大佬能夠指導如何更好的優化系統以及一些技術的推薦或建議可以給我留言~~~最後真心感謝大哥、公司各個業務員、開發同事的一起努力。