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

新產品開發歷時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控件要作到 樣式的統1、默認右鍵菜單、懸浮按鈕、焦點行 熱點行的數據獲取等等。起初因爲開發人員較少，我這邊沒有通過大量測試直接將代碼提交到開發環境供開發們使用。起先封裝的少，代碼也可以理解，沒有暴露問題。漸漸的隨着不斷有新開發加入進來，會發現封裝寫的太死，引入新功能致使舊功能不能用的事故很是多，而開發老是埋怨我這邊作的不夠好。後續只能先本身作足測試，給開發作好培訓工做以後才妥當的使用自定義控件。

挖的第五個坑【產品迭代開發到必定程度，涉及到核心的封裝代碼改動，必定當心再當心，不然等待的將是拆東牆補西牆，處處改動】

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

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

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

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

隨着客戶量的增加、開發團隊的擴張，因爲項目急於上線，不少模塊須要開發，系統架構要優化，數據庫表要管理再加上分庫了，表結構同步問題，升級問題，軟件測試等等一些問題。我犯的最大的錯就是全部事都是本身幹，核心代碼本身寫、普通業務代碼本身寫、小工具本身寫（如：輔助升級工具、數據庫同步工具、用戶管理工具等等）。漸漸發現不少事情都作很差，本身非常力不從心。惟一的解決途徑就是，一個要相信本身的團隊有能力把事情作好，並且要相信他們能比我本身作的更好。只有不斷的放權，相信一塊兒開發的夥伴這纔是體現團隊價值的時候。

挖的第七個坑【切莫全部事情都本身躬親作，把事情交給合適的人作，效果會更好】

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

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

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

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

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

直到測試環境正式用上後，不一樣部門的人在不一樣的環境中工做，到目前爲止再也沒出現過類始於上次那樣的大錯誤。以前提到被老闆罵的狗血淋頭，這裏老闆罵的再兇這個鍋也要接好，千萬不要亂丟。爲何這麼說呢，不能丟，你們夥都在爲產品努力自己壓力很大，在加上任務是我安排的，天然邀功主要人也是我，要是把鍋甩出去，問題就大了，鬧很差可能會出現手下夥伴不滿，致使產品核心開發流失等等更大的問題出現，因此記住「背鍋比邀功更重要」。只有這樣才能讓團隊更好的發展。

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

......

持續更新

......

後記

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