對產(chǎn)品質(zhì)量的一點(diǎn)思考

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

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