軟件開(kāi)發(fā)打敗了 80 %的程序員
首先，我并不是說(shuō)軟件開(kāi)發(fā)人員都是輸家，我想說(shuō)的是，大多數(shù)軟件開(kāi)發(fā)人員都沒(méi)能贏得軟件開(kāi)發(fā)，他們都被軟件開(kāi)發(fā)打敗了。
開(kāi)發(fā)人員的痛點(diǎn)在于，他們不知道自己面對(duì)的是什么游戲，或者說(shuō)他們不知道應(yīng)該采用哪種戰(zhàn)術(shù)。
你必須知道軟件開(kāi)發(fā)是何種游戲，才能在游戲中獲勝。
在編寫(xiě)代碼的過(guò)程中，重點(diǎn)不在于代碼是否會(huì)出錯(cuò)，而是代碼何時(shí)會(huì)出錯(cuò)，以及如何通過(guò)最簡(jiǎn)單的方法修復(fù)錯(cuò)誤。
贏家與輸家
Charles Ellis曾撰寫(xiě)過(guò)一篇文章《Loser’s Game》，他指出，職業(yè)網(wǎng)球是贏家的比賽，即選手利用自己的技能主動(dòng)贏得比賽。而業(yè)余選手會(huì)使用不同的策略避免自己失誤，然后等待對(duì)手出現(xiàn)失誤，從而自己打敗自己。
“在專業(yè)網(wǎng)球比賽中，80%的得分是贏得的；而在業(yè)余網(wǎng)球比賽中，80%的得分是輸?shù)舻摹Q句話說(shuō)，職業(yè)網(wǎng)球是贏家的游戲，即最終結(jié)果取決于贏家的活動(dòng)；而業(yè)余網(wǎng)球是輸家的游戲，即最終結(jié)果取決于輸家的活動(dòng)。這兩種游戲的基本特征完全不同，甚至是相反的。”
—— Charles Ellis
游戲雖然相同，但你需要根據(jù)對(duì)手選擇有效的策略：
“專業(yè)網(wǎng)球就是我所說(shuō)的贏家游戲。贏得分?jǐn)?shù)更多的一方選手獲勝，也就是說(shuō)并不是看哪個(gè)選手得到的分?jǐn)?shù)更高，而是看哪個(gè)選手贏得的分?jǐn)?shù)更高。Ramo發(fā)現(xiàn)業(yè)余網(wǎng)球則完全不同。業(yè)余選手很少打敗自己的對(duì)手，但是他們會(huì)自己打敗自己。在這樣的比賽中，得分更高的選手獲勝，但他得分更高是因?yàn)樗膶?duì)手輸?shù)舻姆謹(jǐn)?shù)更多。”
—— Charles Ellis
軟件開(kāi)發(fā)游戲
我從事軟件開(kāi)發(fā)工作已20載有余，曾與許多軟件開(kāi)發(fā)人員一起從事過(guò)許多項(xiàng)目。我認(rèn)為80%的開(kāi)發(fā)人員都是業(yè)余玩家，只有20%的是專業(yè)玩家。
我為什么這么說(shuō)？
業(yè)余軟件開(kāi)發(fā)人員不喜歡：
標(biāo)準(zhǔn)
單元測(cè)試
設(shè)計(jì)模式/ SOLID原則
學(xué)習(xí)和設(shè)置開(kāi)發(fā)運(yùn)維和產(chǎn)品生命周期管理（他們喜歡使用）
修復(fù)構(gòu)建
代碼審查
代碼分析/解決方案檢查
如果你想毀掉一個(gè)開(kāi)發(fā)團(tuán)隊(duì)，那就不要執(zhí)行上述步驟，因?yàn)閳F(tuán)隊(duì)中的大多數(shù)開(kāi)發(fā)人員都不是專業(yè)人員。
“避免犯錯(cuò)的方法是保守行事，想辦法讓比賽繼續(xù)下去，給對(duì)手充裕的機(jī)會(huì)出現(xiàn)失誤，從而自己打敗自己，因?yàn)闃I(yè)余選手玩的是輸家的游戲，而且他深陷其中卻不自知。”
—— Charles Ellis
大多數(shù)開(kāi)發(fā)人員都會(huì)低估編寫(xiě)代碼的難度，同時(shí)還會(huì)高估自己的能力。他們以為編寫(xiě)代碼非常容易，而且編寫(xiě)好的代碼第一次運(yùn)行就可以成功。
業(yè)余玩家
如果大多數(shù)開(kāi)發(fā)人員都是業(yè)余玩家，那么我們就應(yīng)該將軟件開(kāi)發(fā)視作輸家的游戲，竭盡全力減少業(yè)余玩家容易犯的錯(cuò)誤。
業(yè)余開(kāi)發(fā)人員的目標(biāo)是寫(xiě)代碼，其他活動(dòng)都會(huì)降低開(kāi)發(fā)的速度。上述提到的其他步驟就是為了創(chuàng)建簡(jiǎn)單的代碼，更快地發(fā)現(xiàn)錯(cuò)誤，并注意提高質(zhì)量。產(chǎn)品生命周期管理/開(kāi)發(fā)運(yùn)維可以快速地完成部署，而且還不容易出錯(cuò)，從而實(shí)現(xiàn)快速反饋。
快速編寫(xiě)代碼的最佳方法是專注于質(zhì)量和減少錯(cuò)誤，而不是更快地編寫(xiě)代碼。
項(xiàng)目和開(kāi)發(fā)團(tuán)隊(duì)的規(guī)模越大，為bug和錯(cuò)誤所付出的代價(jià)就越沉重。大型團(tuán)隊(duì)的問(wèn)題可能會(huì)導(dǎo)致很多人的進(jìn)度延誤，而實(shí)施上述列表中的活動(dòng)可以讓我們集中精力處理阻礙。
我曾經(jīng)歷過(guò)一些項(xiàng)目，直到項(xiàng)目后期才發(fā)現(xiàn)的一些bug導(dǎo)致用戶失去信心，并給上線帶來(lái)了風(fēng)險(xiǎn)。
本末倒置
我們的目標(biāo)不是編寫(xiě)有效的代碼，而是花時(shí)間避免編寫(xiě)質(zhì)量低劣的代碼和bug，否則就會(huì)本末倒置。
“對(duì)于你我之輩來(lái)說(shuō)，難得的不是一時(shí)的聰明，而是堅(jiān)持不做蠢事。”
—— Charlie Munger
業(yè)余開(kāi)發(fā)人員認(rèn)為，快速編寫(xiě)代碼是最有效的創(chuàng)建產(chǎn)品的方法。如果方法龐大，代碼復(fù)雜，則代碼庫(kù)會(huì)越來(lái)越復(fù)雜，而且每添加一行代碼開(kāi)發(fā)工作就會(huì)更加困難。這種方法僅適合只有1～2名開(kāi)發(fā)人員的小型項(xiàng)目。
Bug的成本
從代碼編寫(xiě)完成開(kāi)始，發(fā)現(xiàn)bug的時(shí)間越晚，修復(fù)所需的時(shí)間就越長(zhǎng)。舉個(gè)例子，如果你發(fā)現(xiàn)了生產(chǎn)中的某個(gè)bug，那么首先你必須設(shè)法復(fù)現(xiàn)bug，并搞清楚bug發(fā)生的原因，修復(fù)bug，并通過(guò)每個(gè)環(huán)境的部署和測(cè)試，最后才能進(jìn)入生產(chǎn)。
如果在單元測(cè)試中發(fā)現(xiàn)相同的錯(cuò)誤，則可以快速修復(fù)，同時(shí)還不會(huì)影響到其他開(kāi)發(fā)人員和測(cè)試人員。
我們可以在開(kāi)發(fā)過(guò)程中添加一些簡(jiǎn)單的步驟來(lái)找出bug，在軟件開(kāi)發(fā)這個(gè)游戲中，bug會(huì)浪費(fèi)大量時(shí)間，并消磨掉客戶的信任。
如果我們知道大多數(shù)開(kāi)發(fā)團(tuán)隊(duì)的成員都是業(yè)余玩家，他們很容易犯錯(cuò)并導(dǎo)致自己甚至團(tuán)隊(duì)的失敗，那么我們就更加應(yīng)該重視防止bug，而不是假定每個(gè)人都是專業(yè)的開(kāi)發(fā)人員，每個(gè)人都可以編寫(xiě)出色的代碼。
贏得軟件開(kāi)發(fā)這場(chǎng)游戲的關(guān)鍵，不在于第一次就能創(chuàng)建正確的代碼，而在于避免失敗的各種方式。
“專業(yè)人士靠主動(dòng)贏分獲勝，而業(yè)余人士靠對(duì)方丟分獲勝。”
—— Charles Ellis
者 | Ben Hoskin
譯者 | 彎月
原文鏈接：https://thehosk.medium.com/software-development-is-a-losers-game-fc68bb30d7eb
聲明：本文由CSDN翻譯，轉(zhuǎn)載請(qǐng)注明來(lái)源。
歡迎關(guān)注“Java引導(dǎo)者”，我們分享最有價(jià)值的Java的干貨文章，助力您成為有思想的Java開(kāi)發(fā)工程師！