本月的功能在踉蹌中勉強上線了，這個月有實驗的味道，有摸索的代價，有分工和銜接上的問題，有技術儲備方面的不足，有業務梳理方面的欠缺，也有我的能力和意識上的不足，梳理整個開發流程，目前存在的幾大問題：
1、代碼質量問題：
描述分析
1.性能層面：css
從綜合維度看，代碼質量好壞取決於開發人員總體的編程經驗：好比操做系統，設計模式，數據結構和算法，網絡原理，數據庫，前端等等因素。前端
就目前系統總體上看，性能可能會出現的地方，從優先級權重來排列，主要集中在：算法
- 不看執行計劃
- 對索引的理解比較淺，沒用好索引
- SQL優化經驗薄弱
- 數據庫查詢和腳本問題。
- 減小接口對數據庫請求
- 減小前端圖片請求
- 減小前端css/js請求
2.規範層面數據庫
有些規範是能夠文檔化的。好比全局變量所有大寫，局部變量駝峯命名，文件先後綴命名等等比較容易約定俗成；編程
有些規範沒法約定的。好比做業調度有些人命名jobs，有些人命名schedule。若是要想規範必須把業務考慮進來。若是隻是想表達定時做業，屬於技術術語job可能比較合適；若是是業務層面的任務調度可能schedule比較合適。也就是說若是碰到模棱兩可的命名的時候，須要增長考慮因子，經過擴大「視野」來更精確的命名它。設計模式
若是碰到一個問題始終不清楚要如何命名的時候，首先應該要檢討的是本身對業務熟悉不熟悉，對系統總體熟悉不熟悉。若是實在沒法確認，最好請教和溝通，通常都能作好命名。說不定能發現一些本身無知的內容。緩存
若是真的以爲用名字沒法描述清楚，言不盡意，模棱兩可，那就增長代碼註釋。代碼註釋的前提是自解釋，實在沒法達意纔去作註釋，由於註釋太多也是有成本的。安全
一致性優先，也就是說一致性是可讀性的基礎，不然數據庫一種命名，業務代碼一種命名就是錯亂了。好比公司叫Company，可是業務命名叫Supplier，會員叫Member。這裏會出現這種不一致的命名，主要緣由仍是對業務領域不清楚致使的。網絡
因此在底層命名很是關鍵，好比數據模型的表和字段的命名，若是底層命名錯誤，從上下往上只能將錯就錯，讓人改也不是，不改也不是。數據結構
總之，代碼命名和給孩子取名字同樣，其實都是須要慎之又慎，不可隨意叫個阿貓阿狗什麼的。這裏有個原則就是要遵循：簡單，可讀，統一和優雅的原則，固然優雅是最高的要求。
規範僅僅寫個規範文檔是很不夠的，寫好並持續完善規範文檔只是萬里長征第一步。只有規範文檔，沒有落地檢查，文檔也會變成一紙空文。
定個原則是比較容易和簡單的，若是細細追究，裏面有不少坑。
首先你們對簡單，可讀，統一的理解各不相同，最後生成的代碼必然是千人前面，理論上須要對業務的深刻了解，須要有很好的英文功底，同時在總體上要作常常性的檢查和覆盤。
可是引入代碼審查又須要成本，假設一個月審查一次，那麼對每一個成員編寫的一個月的代碼，從月初到月底進行一番梳理和糾正，沒有1-2天是沒法完成的。
因此審查是有成本的，要不要審查呢？
權衡利弊，必需要審查，並且要按照規範，引入嚴苛的代碼審查機制，每月作一次代碼規範和代碼質量的檢查和考覈。
爲何要嚴苛來作代碼審覈呢？由於代碼質量反應了咱們的產品質量，代碼的好壞決定了將來運維的成本，技術債務的危害怎麼形容都不爲過，輕則系統局部異常，中等的會致使修改困難，嚴重的推翻重來。
若是由於進度一時妥協，回頭又忘記了修改，中間又出現人員變更，那麼這份代碼的後患是無窮的，由於沒有規範的代碼，對交接人來講從心態上是本能反抗的，可是又不得不改，因而就一通亂改，能貼膏藥就貼膏藥，能運行就能夠，管他規範不規範。這樣致使的結果是對規範來講，只能從不規範走向更加不規範，最後走向沒法維護。
落地解決：
1.性能層面：
磨刀不負砍柴功，開發以前進行技術評估，識別出其中技術複雜度和難度，及早發現性能方面可能會產生的問題。
把評估的內容逐條分解羅列並作文檔化，對容易的功能儘可能不要有心態上的藐視。
遇到沒有把握的技術問題，及時的拿出來討論，不要以爲很差意思。
- 數據庫層面：
- 經過我的持續學習和提升數據庫優化技能：
- 學會查看執行計劃
- 瞭解索引的底層原理
- 深刻理解關聯查詢的底層原理
- 主站須要生成靜態頁面進行緩存。
- 多研究學習和參考別人寫的代碼，作好底層的技術沉澱，平時多練練內功。
- 經過針對性內部培訓來提升我的薄弱環節，讓技術均衡發展，又各有特長。
2.規範層面：
- 編寫規範的文檔，並持續更新和完善
- 嚴格遵循規範來寫代碼，若是規範當中沒有的，須要適當討論並作迭代規範。
- 按照規範進行代碼審查，每一個開發人員都參與其中，每隔兩週輪流進行代碼的檢查和盤點。直到團隊造成默契，能夠在後期適當的減小審查頻率。
- 基本的規範審查並不難，好比命名，函數的長度等，只要遵循文檔來作就能夠了。
- 難的是對沒有接觸過的技術應該如何作？好比單點登陸，路由規則等。
- 參與前期的需求分析，若是沒有則後期自行了解，好比以詢問的方式進行了解。
- 瞭解技術評估和技術原理。
- 查看當事人的源代碼。
2、測試發佈問題
描述分析：
- 週期：每月集中到最後一週進行測試和發佈時間太緊迫，若是中間缺乏交互和確認，很難保證結果不偏離方向。
- 人設：測試人員對業務和測試流程缺乏前置準備，包括業務的爛熟於心，測試工具和測試數據的知識儲備，致使測試時候不知道如何測試，在原本時間不足的狀況下，增長溝通成本。同時測試水平只停留在簡單淺層的黑盒測試層面，對於深層次的問題，好比壓力測試，DDos攻擊，安全層面的每每就測試不到了。
- 功能測試：測試力度遠遠不足。緣由有以下幾種：
- 邊測試邊修改邊上線，修改速度不及測試速度，致使開發紊亂。
- 前期測試重視不夠，部分業務理解異常，等到測試出來，修改的週期可能會很長，這樣其餘積累下來的BUG處理起來就只能長時間等待了……
- 集成測試
- 功能分工緻使的我的只測試和本身相關的功能，可是系統是一個總體，在測試邊界處是須要雙方集成測試的，好比Message的來往功能。
落地解決：
- 週期：改進交付時間，每隔兩週就交付測試，增長交付頻率，儘早發現和解決問題。
- 人設：
- 增長測試人員May和Kaka的前期業務培訓和接受業務熟練度的考覈，減小測試的遺漏。
- 增長對測試人員包括開發測試的測試技能培訓，提高測試人員的測試水平。好比對測試人員來講，須要學習產品經理的思惟和設計原理，增長測試人員的主動性，讓測試人員能站在用戶的角度來進行測試，而不是簡單的鼠標點點。
- 從心態上重視測試，測試是閉環的最後一個環節，缺一不可。對測試要有敬畏感，測試並非簡單的點一點鼠標的問題，測試的水可深可淺。測試人員須要的是綜合能力，測試技能怎麼強調都是不爲過的。
- 編寫測試用例文檔。測試既要有心態上的重視，也要有可落地的操做方法，而測試用例文檔能夠很好的指導每一個測試人員進行統一測試，避免測試的遺漏和不足。
- 文檔內容涵蓋測試的各個維度，該文檔編寫人員儘可能對產品的理解要達到設計人員的水平，對每一個角落的測試用例要儘量詳盡。該測試用例模板必需要規範，用來指導開發和測試人員進行完整詳盡的測試。
- 開發人員內測：
- 功能測試：執行交換角色測試
- 集成測試：交換角色測試，負責人集中測試。
3、開發效率問題
描述分析：
1.業務層面
- 業務理解不透徹致使的代碼BUG，好比Message系統模塊，收發人員流程沒法打通；
- 對數據庫模型理解誤差致使的功能BUG，例子同上；
- 開發任務分工和配合不足；
- 開發交付頻率不足，致使的過程脫節和問題集中積壓，最後處理緩慢和延遲；
2.技術層面
- 前端技術積累薄弱，遇到複雜一點的前端作起來比較耗時；
- 技術複雜度預估不足，致使的開發延遲。
- 分工緻使的集成薄弱，好比集成測試，需求和開發溝通成本。
落地解決：
1.業務層面
- 業務培訓：產品需求文檔須要提早發佈預熱，培訓後須要作業務複述，複雜的須要作詳細的設計文檔，直到產品經理以爲正確後再進行開發設計。
- 對於複雜功能的業務，採用專題會議的方式，反覆討論，進行頭腦風暴，把業務掰開揉碎講清楚，直到當事人能複述經過爲止。針對個別複雜的業務，好比公共詢盤功能，須要出詳細的需求文檔。
2.技術層面
- 前端技術難點：自研解決，實在沒法解決再去考慮外包和招聘。
- 開發前須要作任務分解，識別出技術複雜度，對沒有把握的技術要及早提出疑問，經過團隊的力量拿出合理的解決方案。
- 功能層面，進行角色互換測試。好比Arvin測試Ive的Message模塊，Ive測試Arvin的機械錶單模塊。
4、開發意識問題：
如下從三個方面總結一下成員開發過程當中的意識問題。
對開發來講，各個環節要持有嚴謹和一絲不苟的態度，樹立簡單並不簡單的意識。對於完成的功能，若是時間上容許，須要反覆回頭檢查可能出現的問題，不要滿目樂觀，或者以爲某個功能很簡單，要站在可能出現問題的立場上來看待正常的功能。由於咱們要打造的是產品，而不是項目，不是小孩過家家的功能。
好的代碼是不斷重構出來的，由於業務和需求是不斷疊加的，不可能寫出一成不變的代碼。當業務倍增，需求變革的時候，再好的代碼都會出現生鏽，腐蝕和壞味道。因此在不忙的時候，須要常常性的整理本身的代碼。
重構解決的是長遠的質量和可維護，可擴展的根本問題。技術債務，若是不及時解決，隨着時間的推動和人員變更，後續花費的成本會逐漸疊加甚至沒法解決，比如蓋房子，在有問題的基礎上蓋房子，蓋得越高危險越大，到了晚期可能就只能推倒重建。
三個臭皮匠勝過諸葛亮，技術越討論越進步，業務越討論越明白。對於模棱兩可或者徹底不懂的問題，儘可能多請教和討論。
討論的印象是最深入的，對我的的成長和幫助也是最大的。好比對Vue的學習和上手，對數據庫腳本的編寫，對ES的學習和討論等等……
樹立不懂不丟人，不懂裝懂才丟人的意識。不要忌諱或者很差意思討論。
討論講究效率和默契。要集中時間，充分準備。 有些開發人員常常問些沒頭沒腦的問題，既沒有背景鋪墊，也沒有上下文，而後想一出一個問題，頻繁的打斷別人的思路而不自知。這種溝通是很浪費時間和成本的。
