本月的功能在踉蹌中勉強上線了，這個月有實驗的味道，有摸索的代價，有分工和銜接上的問題，有技術儲備方面的不足，有業務梳理方面的欠缺，也有個人能力和意識上的不足，梳理整個開發流程，目前存在的幾大問題：

一、程式碼質量問題：

描述分析

1.效能層面：

　　從綜合維度看，程式碼質量好壞取決於開發人員整體的程式設計經驗：比如作業系統，設計模式，資料結構和演算法，網路原理，資料庫，前端等等因素。

　　就目前系統整體上看，效能可能會出現的地方，從優先順序權重來排列，主要集中在：

• 資料庫優化技術偏弱。

• 不看執行計劃
• 對索引的理解比較淺，沒用好索引
• SQL優化經驗薄弱
• 資料庫查詢和指令碼問題。
  • 關聯查詢
  • 索引缺失
  • 請求頻率

• 減少請求次數。

• 減少介面對資料庫請求
• 減少前端圖片請求
• 減少前端css/js請求

• 善用快取

• 靜態檔案CDN快取
• 基礎資料共享快取

• 內容壓縮

• 圖片壓縮
• 請求檔案壓縮
• 富文字內容壓縮

• 主站可能出現的高併發查詢。
• 網路頻寬延遲。

　　2.規範層面

• 命名隨意性

　　有些規範是可以文件化的。比如全域性變數全部大寫，區域性變數駝峰命名，檔案前後綴命名等等比較容易約定俗成；

　　有些規範無法約定的。比如作業排程有些人命名jobs，有些人命名schedule。如果要想規範必須把業務考慮進來。如果只是想表達定時作業，屬於技術術語job可能比較合適；如果是業務層面的任務排程可能schedule比較合適。也就是說如果碰到模稜兩可的命名的時候，需要增加考慮因子，通過擴大“視野”來更精確的命名它。

　　如果碰到一個問題始終不清楚要如何命名的時候，首先應該要反省的是自己對業務熟悉不熟悉，對系統整體熟悉不熟悉。如果實在無法確認，最好請教和溝通，一般都能做好命名。說不定能發現一些自己無知的內容。

　　如果真的覺得用名字無法描述清楚，言不盡意，模稜兩可，那就增加程式碼註釋。程式碼註釋的前提是自解釋，實在無法達意才去做註釋，因為註釋太多也是有成本的。

一致性優先，也就是說一致性是可讀性的基礎，否則資料庫一種命名，業務程式碼一種命名就是錯亂了。比如公司叫Company，但是業務命名叫Supplier，會員叫Member。這裡會出現這種不一致的命名，主要原因還是對業務領域不清楚導致的。

　　所以在底層命名非常關鍵，比如資料模型的表和欄位的命名，如果底層命名錯誤，從上下往上只能將錯就錯，讓人改也不是，不改也不是。

　　總之，程式碼命名和給孩子取名字一樣，其實都是需要慎之又慎，不可隨意叫個阿貓阿狗什麼的。這裡有個原則就是要遵循：簡單，可讀，統一和優雅的原則，當然優雅是最高的要求。

• 規範不是萬能

　　規範僅僅寫個規範文件是很不夠的，寫好並持續完善規範文件只是萬里長征第一步。只有規範文件，沒有落地檢查，文件也會變成一紙空文。

　　定個原則是比較容易和簡單的，如果細細追究，裡面有很多坑。

　　首先大家對簡單，可讀，統一的理解各不相同，最後生成的程式碼必然是千人前面，理論上需要對業務的深入瞭解，需要有很好的英文功底，同時在整體上要做經常性的檢查和覆盤。

　　但是引入程式碼審查又需要成本，假設一個月審查一次，那麼對每個成員編寫的一個月的程式碼，從月初到月底進行一番梳理和糾正，沒有1-2天是無法完成的。

　　所以審查是有成本的，要不要審查呢？

　　權衡利弊，必須要審查，而且要按照規範，引入嚴苛的程式碼審查機制，每個月做一次程式碼規範和程式碼質量的檢查和考核。

　　為什麼要嚴苛來做程式碼稽核呢？因為程式碼質量反應了我們的產品質量，程式碼的好壞決定了未來運維的成本，技術債務的危害怎麼形容都不為過，輕則系統區域性異常，中等的會導致修改困難，嚴重的推翻重來。

　　如果因為進度一時妥協，回頭又忘記了修改，中間又出現人員變動，那麼這份程式碼的後患是無窮的，因為沒有規範的程式碼，對交接人來說從心態上是本能反抗的，但是又不得不改，於是就一通亂改，能貼膏藥就貼膏藥，能執行就可以，管他規範不規範。這樣導致的結果是對規範來說，只能從不規範走向更加不規範，最後走向無法維護。

落地解決：

　　1.效能層面：

• 任務分解和文件化

磨刀不負砍柴功，開發之前進行技術評估，識別出其中技術複雜度和難度，及早發現效能方面可能會產生的問題。

把評估的內容逐條分解羅列並做文件化，對容易的功能儘量不要有心態上的藐視。

遇到沒有把握的技術問題，及時的拿出來討論，不要覺得不好意思。

• 資料庫層面：
• 通過個人持續學習和提高資料庫優化技能：
• 學會檢視執行計劃
• 瞭解索引的底層原理
• 深入理解關聯查詢的底層原理
• 主站需要生成靜態頁面進行快取。
• 增加頁面靜態快取技術
• 增加CDN技術
• 多研究學習和參考別人寫的程式碼，做好底層的技術沉澱，平時多練練內功。
• 通過針對性內部培訓來提高個人薄弱環節，讓技術均衡發展，又各有特長。

　　2.規範層面：

• 編寫規範的文件，並持續更新和完善
• 嚴格遵循規範來寫程式碼，如果規範當中沒有的，需要適當討論並做迭代規範。
• 按照規範進行程式碼審查，每個開發人員都參與其中，每隔兩週輪流進行程式碼的檢查和盤點。直到團隊形成默契，可以在後期適當的減少審查頻率。
• 基本的規範審查並不難，比如命名，函式的長度等，只要遵循文件來做就可以了。
• 難的是對沒有接觸過的技術應該如何做？比如單點登入，路由規則等。
• 參與前期的需求分析，如果沒有則後期自行了解，比如以詢問的方式進行了解。
• 瞭解技術評估和技術原理。
• 檢視當事人的原始碼。

二、測試釋出問題

描述分析：

• 週期：每個月集中到最後一週進行測試和釋出時間太緊迫，如果中間缺少互動和確認，很難保證結果不偏離方向。
• 人設：測試人員對業務和測試流程缺少前置準備，包括業務的爛熟於心，測試工具和測試資料的知識儲備，導致測試時候不知道如何測試，在本來時間不足的情況下，增加溝通成本。同時測試水平只停留在簡單淺層的黑盒測試層面，對於深層次的問題，比如壓力測試，DDos攻擊，安全層面的往往就測試不到了。
• 功能測試：測試力度遠遠不足。原因有如下幾種：
• 邊測試邊修改邊上線，修改速度不及測試速度，導致開發紊亂。
• 前期測試重視不夠，部分業務理解異常，等到測試出來，修改的週期可能會很長，這樣其他積累下來的BUG處理起來就只能長時間等待了……
• 整合測試
• 功能分工導致的個人只測試和自己相關的功能，但是系統是一個整體，在測試邊界處是需要雙方整合測試的，比如Message的來往功能。

落地解決：

• 週期：改進交付時間，每隔兩週就交付測試，增加交付頻率，儘早發現和解決問題。
• 人設：
• 增加測試人員May和Kaka的前期業務培訓和接受業務熟練度的考核，減少測試的遺漏。
• 增加對測試人員包括開發測試的測試技能培訓，提升測試人員的測試水平。比如對測試人員來說，需要學習產品經理的思維和設計原理，增加測試人員的主動性，讓測試人員能站在使用者的角度來進行測試，而不是簡單的滑鼠點點。
• 從心態上重視測試，測試是閉環的最後一個環節，缺一不可。對測試要有敬畏感，測試並不是簡單的點一點滑鼠的問題，測試的水可深可淺。測試人員需要的是綜合能力，測試技能怎麼強調都是不為過的。
• 編寫測試用例文件。測試既要有心態上的重視，也要有可落地的操作方法，而測試用例文件可以很好的指導每個測試人員進行統一測試，避免測試的遺漏和不足。
• 文件內容涵蓋測試的各個維度，該文件編寫人員儘量對產品的理解要達到設計人員的水平，對每個角落的測試用例要儘可能詳盡。該測試用例模板必須要規範，用來指導開發和測試人員進行完整詳盡的測試。
• 開發人員內測：
• 功能測試：執行交換角色測試
• 整合測試：交換角色測試，負責人集中測試。

三、開發效率問題

描述分析：

　　1.業務層面

• 業務理解不透徹導致的程式碼BUG，比如Message系統模組，收發人員流程無法打通；
• 對資料庫模型理解偏差導致的功能BUG，例子同上；
• 開發任務分工和配合不足；
• 開發交付頻率不足，導致的過程脫節和問題集中積壓，最後處理緩慢和延遲；

　　2.技術層面

• 前端技術積累薄弱，遇到複雜一點的前端做起來比較耗時；
• 技術複雜度預估不足，導致的開發延遲。
• 分工導致的整合薄弱，比如整合測試，需求和開發溝通成本。

落地解決：

　　1.業務層面

• 業務培訓：產品需求文件需要提前釋出預熱，培訓後需要做業務複述，複雜的需要做詳細的設計文件，直到產品經理覺得正確後再進行開發設計。
• 對於複雜功能的業務，採用專題會議的方式，反覆討論，進行頭腦風暴，把業務掰開揉碎講清楚，直到當事人能複述通過為止。針對個別複雜的業務，比如公共詢盤功能，需要出詳細的需求文件。

　　2.技術層面

• 前端技術難點：自研解決，實在無法解決再去考慮外包和招聘。
• 開發前需要做任務分解，識別出技術複雜度，對沒有把握的技術要及早提出疑問，通過團隊的力量拿出合理的解決方案。
• 功能層面，進行角色互換測試。比如Arvin測試Ive的Message模組，Ive測試Arvin的機械錶單模組。

四、開發意識問題：

以下從三個方面總結一下成員開發過程中的意識問題。

• 樹立嚴謹心態

　　對開發來說，各個環節要持有嚴謹和一絲不苟的態度，樹立簡單並不簡單的意識。對於完成的功能，如果時間上允許，需要反覆回頭檢查可能出現的問題，不要滿目樂觀，或者覺得某個功能很簡單，要站在可能出現問題的立場上來看待正常的功能。因為我們要打造的是產品，而不是專案，不是小孩過家家的功能。

• 重構意識

　　好的程式碼是不斷重構出來的，因為業務和需求是不斷疊加的，不可能寫出一成不變的程式碼。當業務倍增，需求變革的時候，再好的程式碼都會出現生鏽，腐蝕和壞味道。所以在不忙的時候，需要經常性的整理自己的程式碼。

重構解決的是長遠的質量和可維護，可擴充套件的根本問題。技術債務，如果不及時解決，隨著時間的推進和人員變動，後續花費的成本會逐漸疊加甚至無法解決，好比蓋房子，在有問題的基礎上蓋房子，蓋得越高危險越大，到了晚期可能就只能推倒重建。

• 重視討論

　　三個臭皮匠賽過諸葛亮，技術越討論越進步，業務越討論越明白。對於模稜兩可或者完全不懂的問題，儘量多請教和討論。

　　討論的印象是最深刻的，對個人的成長和幫助也是最大的。比如對Vue的學習和上手，對資料庫指令碼的編寫，對ES的學習和討論等等……

　　樹立不懂不丟人，不懂裝懂才丟人的意識。不要忌諱或者不好意思討論。

　　討論講究效率和默契。要集中時間，充分準備。 有些開發人員經常問些沒頭沒腦的問題，既沒有背景鋪墊，也沒有上下文，然後想一出一個問題，頻繁的打斷別人的思路而不自知。這種溝通是很浪費時間和成本的。

&n