不管是做產品還是做項目，也不管是采用瀑布模型還是敏捷開發，我們都有一個終極目標，就是能按時交付質量可靠的功能，其中質量尤為重要。

本文是我對產品質量的一點思考，如果您所在的團隊代碼質量很高，很少出BUG，那么可以私信我，我們可以交流下關于代碼質量的一些問題。

小公司面臨的問題

大公司里每個人指責分明，團隊的人員配置也比較齊全，有完整的開發流程，流程也會不斷的迭代優化，每個環節只要按照流程嚴格去執行，基本不會出什么大的問題。但不是每個人都能夠進入到大公司，或者說會一直待在大公司，如果您是在中小公司，可能會有下面一些情況：

• 沒有專職的需求分析人員，沒有專職的測試人員，很多時候是一崗多職

• 沒有不急的項目，客戶永遠說的都是越快越好

• 雖然說唯一不變的就是變化，我們需要擁抱變化，但常常會即便擁有一雙長臂，也無力擁抱

• 需求來了，直接寫代碼，后期補文檔

• 代碼中基本不寫單元測試

• 沒有自主研發的需求管理平臺

為什么會有上面的問題，我覺得很重要的一個原因是成本問題，專職需求分析需要人力成本，寫單元測試、文檔等需要時間成本，等等。短期看來是節省了成本，但從長遠來看，會導致質量下降，最終會得不償失，如果您是做項目，打一槍換個地方，我不做評價，如果是在不斷地迭代成品，那么就要停下來好好思考下了。

我們的現狀

10人左右的團隊，需要做的事情如下：

• 需求分析

• Vue前端開發

• dotNetCore后端開發

• H5、小程序、iOS、安卓

• 測試

• 運維

上面說到，在小公司會是一崗多職，我們也不例外，大概任務分配如下：

• 全員做需求分析，即便是新手，也要求做簡單需求的分析

• 后端工程師除了iOS和安卓不做，其他的都做

• iOS和安卓工程師除了后端不做，其他都做

• 只有一兩個只做純前端的工程師

目前來看，整個團隊是偏全棧的，全棧的團隊理論上效率會很高，的確，效率從來都不是我擔心的問題，但質量問題卻一直都沒能很好的解決：

• 開發人員還是更喜歡寫代碼，文檔能力偏弱，雖然目前強制規定每個所做的需求在語雀上要寫對應的需求文檔，但很多時候寫不到點子上，關聯影響點也沒有分析，給測試提供不了很好的支撐

• 文檔寫不好，加上開發者的思維，很多低級問題在自測階段不能被發現

• 經常改了A模塊的一個問題，引發其他模塊的幾個問題

• 同樣的問題會反反復復出現

怎樣解決質量問題

取舍和平衡

我認為軟件開發其實是在時間、范圍、穩定性和代碼質量上做博弈：

• 時間：交付一個功能的期限，比如老板說3個月要上線某功能

• 范圍：需要實現功能的邊界

• 穩定性：隨著版本的不斷更新，用戶使用產品的一個最直觀的感受

• 代碼質量：代碼是否是可復用，易于維護的，用戶不能直觀感受，但也同樣重要

領導總是會說，這個時間節點非常重要，或者重要客戶，不能延后，等等，總之時間節點后延的可能性不大。

穩定性也不能出問題，輕則客戶滿意度降低，重則會造成事故，給客戶帶來嚴重損失，客戶可能因此就丟了。

所以只能在范圍和代碼質量上做取舍：

• 本來應該三個月做的任務，非要壓縮到一個月，那只能去和領導溝通，將一些不重要，或者不緊急的任務放到下一階段完成

• 如果范圍也不能壓縮，那就只能舍棄代碼質量了，怎么快怎么來，但也因此欠下了一個技術債，債是需要償還的，也是有利息的，還的越遲，利息越多。

自動化測試

自動化測試分為兩個部分，構建之前的單元測試和構建之后的端到端測試

• 單元測試又分為前端Vue的單元測試和dotNetCore的單元測試，在一個已成型的產品中去加單元測試是很困難的，所以只能先找一些關鍵點，經常出問題的點去嘗試

• 端到端的測試我們采用TestCafe，反復出問題的地方，就提煉出來一種業務場景，有針對性地去寫測試代碼

配合Jenkins，做到測試的自動化，那是不是有了自動化測試就能高枕無憂了呢？并不是，我覺得更重要的是，每個人員對產品要有深入的理解，對所做的需求要能完全掌握，對關聯影響點的分析要沒有任務遺漏。

測試只是手段而不是目的，我們的目的是寫出好的代碼，交付出無缺陷的功能。

總結

沒有任何的方法論是可以生搬硬套的，只有不斷的去學習、吸收、結合現有資源進行實踐、不斷的重復這個過程，直到找到一種適合自己團隊的落地方案。

改善質量的道路任重而道遠，不斷地去嘗試，去實踐總會有些效果的。

您所在的團隊又是怎么樣來保證質量的呢？歡迎討論。

總結

以上是生活随笔為你收集整理的对产品质量的一点思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。