Find N3入網(wǎng)：最高支持16+1TB
OPPO將于近期登場的Find N3折疊屏目前已經(jīng)正式入網(wǎng)，型號為PHN110。本次Find N3在外觀方面相比前兩代有很大的變化，不再是小號的橫向折疊屏，而是跟別的廠商一樣采用了較為常見的
作者 | 李光毅
在過去相當(dāng)長一段時間內(nèi)，我都在一個負責(zé)項目維護的團隊內(nèi)工作。團隊的特殊之處在于，我們從來不開發(fā)新功能，而是負責(zé)解決每天上報的線上問題。這些 bug 無奇不有，從無法打開頁面到數(shù)據(jù)奇怪丟失，麻木早已經(jīng)替代焦慮成為了我們面對 bug 時的主要情緒。
但我時不時的抱怨依然是：為什么 bug總是在發(fā)生。
缺陷早已在豐田生產(chǎn)系統(tǒng)（Toyota Production System）中被標(biāo)注為浪費之一。沒有人希望看到 bug，我們不想，客戶更加不想。但我們似乎都不愿承認(rèn)的一個事實是：
bug是代碼的副產(chǎn)品而已。
如果我們選擇接受編碼不過是人思維活動的一種形式，與思考無異，那我們也就必須接納，人性的缺陷在代碼中自然也不會缺席，恰如硬幣的正反兩面。
反過來說，如果你對 bug采取的是零容忍的態(tài)度，甚至不惜把此寫入 KPI 中，它也未必會帶來正面效應(yīng)，因為自此開始，沒有人會愿意重構(gòu)，沒有人會愿意引入新的技術(shù)方案，道理非常簡單：改動越多風(fēng)險越大——這是某年發(fā)生在我所屬團隊的一次親身經(jīng)歷。
所以我們面臨的并非 bug 去或者留的選項，而是多與少的問題。
在 MoSCoW 方法論的框架下，我們通常可以將功能的優(yōu)先級劃分為四類: Must Have, Should Have, Could Have 以及 Won’tHave，如果把質(zhì)量也作為功能的一個維度落入這四個區(qū)間之一的話，它一定不會在 Must Have 這個范圍內(nèi)。因為人們既不會因為沒有 bug而選擇長時間地使用一款應(yīng)用，也不會因為存在 bug而成為轉(zhuǎn)投它競爭對手的唯一理由。我們必須承認(rèn)這樣一個事實：質(zhì)量永遠也不是商業(yè)的核心競爭力，這也暗示著：
前者并非我們的一廂情愿，在互聯(lián)網(wǎng)產(chǎn)品的高性價比和快速迭代的商業(yè)邏輯下，用戶對產(chǎn)品質(zhì)量的預(yù)期已經(jīng)被規(guī)訓(xùn)到一個非常「理想」的狀態(tài)。
而后者更為關(guān)鍵：我們應(yīng)該如何最大化利用有限的資源去提升質(zhì)量？如果你所在的部門也有機會組建一支類似于本文開頭的團隊，那不妨考慮一下這個建議：用資源換取更多的人員加入這支團隊怎么樣？
原諒我用一個粗俗的比喻來解釋為什么這么做行不通：
我們換來的只是打掃的速度，對制造垃圾的人產(chǎn)生不了任何影響，效果甚至?xí)m得其反：考慮到總有人為他們收拾殘局，我們的善后工作做得越好，他們越是會肆無忌憚。
但這是當(dāng)下大部分公司的現(xiàn)狀：如果線上問題激增，是不是QA 工作不到位？我們似乎傾向把編碼和測試的界限劃分得一清二楚，從人員到職責(zé)到工序都是如此。而質(zhì)量問題從編碼中來，卻想從測試中尋找解決之道，這與刻舟求劍無異。
鋪墊了如此之多，我想表達的觀點依然是老生常談：質(zhì)量內(nèi)建，以及最近幾年我們常常提倡的測試左移。至于什么是質(zhì)量內(nèi)建和測試左移，并不在這篇文章的范圍內(nèi)，你在網(wǎng)上可以找到大量的專業(yè)文章來介紹他們。
現(xiàn)在我們必須回答一個核心問題：誰該對質(zhì)量負責(zé)？最官方的答案是每個角色，我們可以列舉出產(chǎn)品經(jīng)理沒有全面地對功能做驗收，QA沒有把控好質(zhì)量關(guān)等等。但假定此刻我們必須指定一人將他五花大綁起來祭天，為的是有人需要為上一個讓人焦頭爛額的bug 負責(zé)，程序員絕對是不二之選。
但程序員死也不會瞑目的。
如果你是團隊經(jīng)理，你發(fā)現(xiàn)上個月線上問題數(shù)量增加了一倍，于是你沖到你的工程師團隊工位前，怒不可遏地沖他們吼道：我希望這個月的線上問題不超過個位數(shù)！你覺得他們能做到嗎？
我想說的是：
質(zhì)量不是「希望」的結(jié)果，它是付出的收獲。關(guān)鍵在于你愿意用什么去交換。
提升質(zhì)量的訣竅一點也不神秘。口口相傳的各類業(yè)內(nèi)實踐便是最好的靈丹妙藥，比如重構(gòu)、代碼評審、結(jié)對編程、流水線集成等等。我們不妨就以單元測試為例，看看我們需要付出多大的成本
首先，時間便是一筆可觀的支出。以我所在的項目為例，我們?yōu)榍岸薘eact 組件編寫單元測試的時間，幾乎與開發(fā)功能的時間相同。注意這還是在沒有追求覆蓋所有的邊界用例，以及沒有追求 100%的測試覆蓋率的情況下。另外，當(dāng)我們編寫的代碼導(dǎo)致之前編寫的關(guān)聯(lián)測試無法通過流水線時，去查找失敗的原因以及修正這些錯誤也是隱形時間。
其次，在我看來最難以逾越的障礙在于對工程文化的重塑。對下要強調(diào)保證程序員去寫、關(guān)注、修復(fù)的紀(jì)律；對上要爭取理解和空間來輔助這些實踐，單拎出來任何一件事推動起來都不簡單。工程實踐天然具有一種反商業(yè)活動的特性，它很難被量化、難以一針見效。沒有人敢拍著胸脯說在xx 天之內(nèi)或者當(dāng)測試覆蓋率至少達到 xx 水平之后， bug 數(shù)量會降至 xx。我們都不否認(rèn)它會變得更好。諷刺的是實踐帶來的「負面」效應(yīng)是立竿見影的：工程團隊的交付速度變慢了。
測試的部分好處還來自未來，比如它能增強我們重構(gòu)代碼和變更架構(gòu)時的信心，防止舊功能無意被新功能破壞。但我依然無法保證你的收益會何時何地有幾倍于付出的到來。
于是現(xiàn)狀變成了一方面可見的迭代速度變慢，另一方面成本的付出看不到收益，質(zhì)量就自然值得被犧牲。
在提升質(zhì)量的過程中，我們解決的不是個體問題而是工業(yè)問題。細想這是很難的：一個團隊中成員的能力不同背景不同，但我們卻要設(shè)法讓它們的產(chǎn)出質(zhì)量處于某個水平之上。
聽上去我們只能義無反顧去相信（take a leap of faith）某些實踐能夠幫助我們提升質(zhì)量，且付出的收益是不確定的。但換一個角度想，我們只是在做一些本該做好的事情而已，用戶的寬容讓質(zhì)量變得可有可無。
我不否認(rèn)有時候快比好更重要，只不過當(dāng)有一天質(zhì)量變成我們無法再忽視的問題時，別不知所措地想不起來質(zhì)量是在哪里搞丟的。
本文鏈接：http://www.tebozhan.com/showinfo-26-103567-0.html昂貴的質(zhì)量——為什么bug總在發(fā)生？
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 前端新入職必備清單，保姆級教程！
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號