對產品質量的一點思考

不管是做產品還是做項目，也不管是采用瀑布模型還是敏捷開發，我們都有一個終極目標，就是能按時交付質量可靠的功能，其中質量尤為重要。
本文是我對產品質量的一點思考，如果您所在的團隊代碼質量很高，很少出BUG，那么可以私信我，我們可以交流下關于代碼質量的一些問題。
小公司面臨的問題
大公司里每個人指責分明，團隊的人員配置也比較齊全，有完整的開發流程，流程也會不斷的迭代優化，每個環節只要按照流程嚴格去執行，基本不會出什么大的問題。但不是每個人都能夠進入到大公司，或者說會一直待在大公司，如果您是在中小公司，可能會有下面一些情況：
沒有專職的需求分析人員，沒有專職的測試人員，很多時候是一崗多職
沒有不急的項目，客戶永遠說的都是越快越好
雖然說唯一不變的就是變化，我們需要擁抱變化，但常常會即便擁有一雙長臂，也無力擁抱
需求來了，直接寫代碼，后期補文檔
代碼中基本不寫單元測試
沒有自主研發的需求管理平臺
為什么會有上面的問題，我覺得很重要的一個原因是成本問題，專職需求分析需要人力成本，寫單元測試、文檔等需要時間成本，等等。短期看來是節省了成本，但從長遠來看，會導致質量下降，最終會得不償失，如果您是做項目，打一槍換個地方，我不做評價，如果是在不斷地迭代成品，那么就要停下來好好思考下了。
我們的現狀
10人左右的團隊，需要做的事情如下：
需求分析
Vue前端開發
dotNetCore后端開發
H5、小程序、iOS、安卓
測試
運維
上面說到，在小公司會是一崗多職，我們也不例外，大概任務分配如下：
全員做需求分析，即便是新手，也要求做簡單需求的分析
后端工程師除了iOS和安卓不做，其他的都做
iOS和安卓工程師除了后端不做，其他都做
只有一兩個只做純前端的工程師
目前來看，整個團隊是偏全棧的，全棧的團隊理論上效率會很高，的確，效率從來都不是我擔心的問題，但質量問題卻一直都沒能很好的解決：
開發人員還是更喜歡寫代碼，文檔能力偏弱，雖然目前強制規定每個所做的需求在語雀上要寫對應的需求文檔，但很多時候寫不到點子上，關聯影響點也沒有分析，給測試提供不了很好的支撐
文檔寫不好，加上開發者的思維，很多低級問題在自測階段不能被發現
經常改了A模塊的一個問題，引發其他模塊的幾個問題
同樣的問題會反反復復出現
怎樣解決質量問題
取舍和平衡
我認為軟件開發其實是在時間、范圍、穩定性和代碼質量上做博弈：
時間：交付一個功能的期限，比如老板說3個月要上線某功能
范圍：需要實現功能的邊界
穩定性：隨著版本的不斷更新，用戶使用產品的一個最直觀的感受
代碼質量：代碼是否是可復用，易于維護的，用戶不能直觀感受，但也同樣重要
領導總是會說，這個時間節點非常重要，或者重要客戶，不能延后，等等，總之時間節點后延的可能性不大。
穩定性也不能出問題，輕則客戶滿意度降低，重則會造成事故，給客戶帶來嚴重損失，客戶可能因此就丟了。
所以只能在范圍和代碼質量上做取舍：
本來應該三個月做的任務，非要壓縮到一個月，那只能去和領導溝通，將一些不重要，或者不緊急的任務放到下一階段完成
如果范圍也不能壓縮，那就只能舍棄代碼質量了，怎么快怎么來，但也因此欠下了一個技術債，債是需要償還的，也是有利息的，還的越遲，利息越多。
自動化測試
自動化測試分為兩個部分，構建之前的單元測試和構建之后的端到端測試
單元測試又分為前端Vue的單元測試和dotNetCore的單元測試，在一個已成型的產品中去加單元測試是很困難的，所以只能先找一些關鍵點，經常出問題的點去嘗試
端到端的測試我們采用TestCafe，反復出問題的地方，就提煉出來一種業務場景，有針對性地去寫測試代碼
配合Jenkins，做到測試的自動化，那是不是有了自動化測試就能高枕無憂了呢？并不是，我覺得更重要的是，每個人員對產品要有深入的理解，對所做的需求要能完全掌握，對關聯影響點的分析要沒有任務遺漏。
測試只是手段而不是目的，我們的目的是寫出好的代碼，交付出無缺陷的功能。
總結
沒有任何的方法論是可以生搬硬套的，只有不斷的去學習、吸收、結合現有資源進行實踐、不斷的重復這個過程，直到找到一種適合自己團隊的落地方案。

原文轉自：http://mp.weixin.qq.com/s?__biz=MzU0NjgzNzQyMw==&mid=2247483862&idx=1&sn=b2993fc378c7a1c7e98f7d02238f1db4