來自：http://36kr.com/p/5140435.html；
原文：https://medium.com/@fagnerbrack/the-problem-you-solve-is-more-important-than-the-code-you-write-d0e5493132c6

當你手裏有把錘子的時候，看所有的東西都是釘子。

有時候程序員往往會陷入爲了寫代碼而寫代碼的怪圈，沒有意識到代碼是爲了解決現實問題的。當問題有更簡便的解決方案時，寫代碼未必就是必須。記住：你不是別人花錢讓你在屏幕上寫字符的程序猿，而是讓你解決問題的專業人士。Fagner Brack 的總結非常有見地。

錘子擺在一塊木板上。木板有一顆被錘彎的釘子。

程序員似乎已經忘記了軟件的真正目的是什麼，是解決現實世界的問題。

50 年前的 1968 年開過一場會，會議名字叫做軟件工程工作會議，是有 NATO 科學委員會贊助的。那時候大家已經開始注意到軟件日益成爲社會的基礎。然而，軟件也變得太難以理解。在那次會議之後，變成開始變成一個行業。軟件開始擺脫商業人士的控制。

不管軟件此後走上了什麼樣的發展道路，仍然存在着業務與軟件開發（或者按照那次會議首次的說法，“工程”）分離的問題。如果開發者太過狹隘地專注於開發，就會錯過了他們編寫的軟件背後的目的。以至於可能會看不到並不需要編寫任何代碼的潛在解決方案。

舉個例子。

有一家初創企業是做設備的，這種設備可以讓人利用藍牙解鎖開門。跟這種設備進行通信的可視化界面是一個小程序，就算是門鎖上它也能看見。這個玩意兒有一個按鈕叫做 “開門”。

當用戶接近房子時，他們會拿出手機，找到那個小程序，然後點擊按鈕開門。

有人看過這套流程之後問道：

如果我們用的是藍牙並且假設拿着這部手機的任何人都能進入房子的話，爲什麼還需要讓某人拿出手機然後按按鈕呢？當它檢測到設備距離在 1 米之內時讓們打開不就行了嗎。這樣我們就不用付出設計和編寫可視化界面的成本了！

這個藍牙應用的故事是聚焦過窄的絕佳例子：目標是用盡量方便地開門。如果傳感器是無線的話設計可視化界面毫無意義。

如果你意識到企業想要實現什麼以及對用戶的價值是什麼的話，你可以將哪方面的知識跟你對技術可能做到什麼的知識融爲一體。只有這樣你纔會具備足夠的信息來想出更好的答案並且得出結論說界面對產品來說毫無必要。

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

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

有時候，修補重大 bug 未必是優先事項。假設你是加密數字貨幣交易所，如果你的系統允許出現一次賬戶副本的話，人爲幹預會是成本效益最佳的解決方案——如果修補漏洞的代價很大的話。《告別狗屎代碼，請記住這 11 條編碼祕訣！》建議你看一下。

嚴重性於優先級之間的權衡讓我想起了同事最近給我看過的一種模型。這個模型叫做優先級矩陣這是一個二維模型，可用於確定 bug 的優先級，其根據是影響到的用戶數以及嚴重性。

二維優先級矩陣圖示。Y 軸表示受影響的用戶，分別包含 “一個”、“一些” 以及 “全部” 這些值。X 軸表示 “嚴重性，值包括 “界面性”、“造成不便” 以及 “無法工作”。Bug 的優先級多少要取決於它在座標上的位置。

比方說，如果 ug 是界面性的而且僅影響到一個用戶的話，則優先級爲 4；如果 bug 讓某人無法工作而且影響到一些人的話，則優先級爲 1；如果 bug 導致所有人都無法工作的話，則優先級爲最高，0。

前面說過的單賬戶副本問題算是影響了一個用戶的使用便利性這類，因此其優先級爲 3。

不是所有的 bug 都值得修復

開發者想給一切都寫腳本是非常常見的。然而，一些重複性的任務未必值得自動化。如果你打算隱藏一些有關底層命令如何工作的基本知識的話，就不需要花時間去寫腳本了。

服裝複雜邏輯和抽象有用知識之間是有區別的。有時候，信息應該明確表示方便理解。如果你對信息進行了抽象的話，可能反而產生相反效果並且難以理解。

在 CLI 裏面使用一些類型的低級命令而不是抽象了知識的高級命令（如 Git aliases）會更有用。

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

幾年前我用 Incremental Delivery 做了一個項目。這是一個身份驗證系統，系統會讓用戶提交一些個人數據，讓第三方提供商進行驗證。

團隊想要開發一個非常棒的字段驗證功能。然而，驗證這個功能每次 sprint 計劃都被列到低優先級的位置，眼看着截止期限越來越近了。到最後，團隊發現這項功能根本就沒有必要。

原因是：驗證是必須的！

提供合法信息關乎用戶的利益。如果用戶提供的數據是錯的，驗證就不會通過也就無法使用系統。此外，大多數瀏覽器都支持標準的 HTML 驗證，這已經足夠了。

最糟糕的情況下，本人無法驗證通過的用戶會打電話給支持進行人工驗證。

不是每一項功能都值得編寫

作爲開發者，如果你理解了自己試圖要解決的問題的話，你就能想出更好的代碼，甚至有時候根本不需要編碼。你不是別人花錢讓你在屏幕上寫字符的程序猿。你是別人花錢來幫忙解決問題的專業人士。

不過，如果試圖不經思考只想用技術解決每一個問題，就好像把代碼當成銀彈的話，你就很難理解什麼東西對客戶有價值，也很難想出很好的點子。

你的目的以及所寫代碼的目的都是爲了產生價值，讓世界更美好，而不是爲了滿足你以自我爲中心的世界觀。

有句話是這麼說的：“當你手裏有把錘子的時候，看所有的東西都是釘子。”

最好還是先有顆釘子這樣你纔會考慮需要一把錘子。

也就是說，如果你本來就需要釘子的話。