當(dāng)你手里有把錘子的時(shí)候，看所有的東西都是釘子。有時(shí)候程序員往往會(huì)陷入為了寫代碼而寫代碼的怪圈，沒有意識(shí)到代碼是為了解決現(xiàn)實(shí)問題的。當(dāng)問題有更簡便的解決方案時(shí)，寫代碼未必就是必須。記住：你不是別人花錢讓你在屏幕上寫字符的程序猿，而是讓你解決問題的專業(yè)人士。Fagner Brack 的總結(jié)非常有見地。

　　錘子擺在一塊木板上。木板有一顆被錘彎的釘子。程序員似乎已經(jīng)忘記了軟件的真正目的是什么，是解決現(xiàn)實(shí)世界的問題。50 年前的 1968 年開過一場(chǎng)會(huì)，會(huì)議名字叫做軟件工程工作會(huì)議，是有 NATO 科學(xué)委員會(huì)贊助的。那時(shí)候大家已經(jīng)開始注意到軟件日益成為社會(huì)的基礎(chǔ)。然而，軟件也變得太難以理解。在那次會(huì)議之后，變成開始變成一個(gè)行業(yè)。軟件開始擺脫商業(yè)人士的控制。

　　不管軟件此后走上了什么樣的發(fā)展道路，仍然存在著業(yè)務(wù)與軟件開發(fā)（或者按照那次會(huì)議首次的說法，“工程”）分離的問題。如果開發(fā)者太過狹隘地專注于開發(fā)，就會(huì)錯(cuò)過了他們編寫的軟件背后的目的。以至于可能會(huì)看不到并不需要編寫任何代碼的潛在解決方案。

　　舉個(gè)例子：有一家初創(chuàng)企業(yè)是做設(shè)備的，這種設(shè)備可以讓人利用藍(lán)牙解鎖開門。跟這種設(shè)備進(jìn)行通信的可視化界面是一個(gè)小程序，就算是門鎖上它也能看見。這個(gè)玩意兒有一個(gè)按鈕叫做 “開門”。當(dāng)用戶接近房子時(shí)，他們會(huì)拿出手機(jī)，找到那個(gè)小程序，然后點(diǎn)擊按鈕開門。有人看過這套流程之后問道：如果我們用的是藍(lán)牙并且假設(shè)拿著這部手機(jī)的任何人都能進(jìn)入房子的話，為什么還需要讓某人拿出手機(jī)然后按按鈕呢？當(dāng)它檢測(cè)到設(shè)備距離在 1 米之內(nèi)時(shí)讓們打開不就行了嗎。這樣我們就不用付出設(shè)計(jì)和編寫可視化界面的成本了！

　　這個(gè)藍(lán)牙應(yīng)用的故事是聚焦過窄的絕佳例子：目標(biāo)是用盡量方便地開門。如果傳感器是無線的話設(shè)計(jì)可視化界面毫無意義。如果你意識(shí)到企業(yè)想要實(shí)現(xiàn)什么以及對(duì)用戶的價(jià)值是什么的話，你可以將哪方面的知識(shí)跟你對(duì)技術(shù)可能做到什么的知識(shí)融為一體。只有這樣你才會(huì)具備足夠的信息來想出更好的答案并且得出結(jié)論說界面對(duì)產(chǎn)品來說毫無必要。

　　這是一個(gè)解決編程問題的出色例子——除了編寫解鎖功能以外再無編寫任何額外代碼之必要。然而，就像技術(shù)債務(wù)一樣，任何東西都不應(yīng)該用來作為編寫垃圾代碼的借口。

　　不是所有的代碼都值得編寫

　　有時(shí)候，修補(bǔ)重大 bug 未必是優(yōu)先事項(xiàng)。假設(shè)你是加密數(shù)字貨幣交易所，如果你的系統(tǒng)允許出現(xiàn)一次賬戶副本的話，人為干預(yù)會(huì)是成本效益佳的解決方案——如果修補(bǔ)漏洞的代價(jià)很大的話。

　　嚴(yán)重性于優(yōu)先級(jí)之間的權(quán)衡讓我想起了同事近給我看過的一種模型。這個(gè)模型叫做優(yōu)先級(jí)矩陣這是一個(gè)二維模型，可用于確定 bug 的優(yōu)先級(jí)，其根據(jù)是影響到的用戶數(shù)以及嚴(yán)重性。

　　二維優(yōu)先級(jí)矩陣圖示。Y 軸表示受影響的用戶，分別包含 “一個(gè)”、“一些” 以及 “全部” 這些值。X 軸表示 “嚴(yán)重性，值包括 “界面性”、“造成不便” 以及 “無法工作”。Bug 的優(yōu)先級(jí)多少要取決于它在坐標(biāo)上的位置。比方說，如果 ug 是界面性的而且僅影響到一個(gè)用戶的話，則優(yōu)先級(jí)為 4；如果 bug 讓某人無法工作而且影響到一些人的話，則優(yōu)先級(jí)為 1；如果 bug 導(dǎo)致所有人都無法工作的話，則優(yōu)先級(jí)為高，0。

　　前面說過的單賬戶副本問題算是影響了一個(gè)用戶的使用便利性這類，因此其優(yōu)先級(jí)為 3。

　　不是所有的 bug 都值得修復(fù)

　　開發(fā)者想給一切都寫腳本是非常常見的。然而，一些重復(fù)性的任務(wù)未必值得自動(dòng)化。如果你打算隱藏一些有關(guān)底層命令如何工作的基本知識(shí)的話，就不需要花時(shí)間去寫腳本了。服裝復(fù)雜邏輯和抽象有用知識(shí)之間是有區(qū)別的。有時(shí)候，信息應(yīng)該明確表示方便理解。如果你對(duì)信息進(jìn)行了抽象的話，可能反而產(chǎn)生相反效果并且難以理解。

　　在 CLI 里面使用一些類型的低級(jí)命令而不是抽象了知識(shí)的高級(jí)命令（如 Git aliases）會(huì)更有用。

　　并不是所有的命令都值得寫腳本

　　幾年前我用 Incremental Delivery 做了一個(gè)項(xiàng)目。這是一個(gè)身份驗(yàn)證系統(tǒng)，系統(tǒng)會(huì)讓用戶提交一些個(gè)人數(shù)據(jù)，讓第三方提供商進(jìn)行驗(yàn)證。團(tuán)隊(duì)想要開發(fā)一個(gè)非常棒的字段驗(yàn)證功能。然而，驗(yàn)證這個(gè)功能每次 sprint 計(jì)劃都被列到低優(yōu)先級(jí)的位置，眼看著截止期限越來越近了。到后，團(tuán)隊(duì)發(fā)現(xiàn)這項(xiàng)功能根本就沒有必要。

　　原因是：驗(yàn)證是必須的！

　　提供合法信息關(guān)乎用戶的利益。如果用戶提供的數(shù)據(jù)是錯(cuò)的，驗(yàn)證就不會(huì)通過也就無法使用系統(tǒng)。此外，大多數(shù)瀏覽器都支持標(biāo)準(zhǔn)的 HTML 驗(yàn)證，這已經(jīng)足夠了。糟糕的情況下，本人無法驗(yàn)證通過的用戶會(huì)打電話給支持進(jìn)行人工驗(yàn)證。

　　不是每一項(xiàng)功能都值得編寫

　　作為開發(fā)者，如果你理解了自己試圖要解決的問題的話，你就能想出更好的代碼，甚至有時(shí)候根本不需要編碼。你不是別人花錢讓你在屏幕上寫字符的程序猿。你是別人花錢來幫忙解決問題的專業(yè)人士。不過，如果試圖不經(jīng)思考只想用技術(shù)解決每一個(gè)問題，就好像把代碼當(dāng)成銀彈的話，你就很難理解什么東西對(duì)客戶有價(jià)值，也很難想出很好的點(diǎn)子。你的目的以及所寫代碼的目的都是為了產(chǎn)生價(jià)值，讓世界更美好，而不是為了滿足你以自我為中心的世界觀。

　　有句話是這么說的：“當(dāng)你手里有把錘子的時(shí)候，看所有的東西都是釘子。”好還是先有顆釘子這樣你才會(huì)考慮需要一把錘子。也就是說，如果你本來就需要釘子的話。