避免把路走窄，程式員須記住：解決問題比寫代碼更重要

當你手裡有把錘子的時候，看所有的東西都是釘子。有時候程式員往往會陷入為了寫代碼而寫代碼的怪圈，沒有意識到代碼是為了解決現實問題的。當問題有更簡便的解決方案時，寫代碼未必就是必須。

記住：你不是别人花錢讓你在螢幕上寫字元的程式猿，而是讓你解決問題的專業人士。Fagner Brack的總結非常有見地。

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

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

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

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

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

舉個例子。

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

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

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

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

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

如果你意識到企業想要實作什麼以及對使用者的價值是什麼的話，你可以将哪方面的知識跟你對技術可能做到什麼的知識融為一體。隻有這樣你才會具備足夠的資訊來想出更好的答案并且得出結論說界面對産品來說毫無必要。

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

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

有時候，修補重大bug未必是優先事項。假設你是加密數字貨币交易所，如果你的系統允許出現一次賬戶副本的話，人為幹預會是成本效益最佳的解決方案——如果修補漏洞的代價很大的話。

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

二維優先級矩陣圖示。Y軸表示受影響的使用者，分别包含“一個”、“一些”以及“全部”這些值。X軸表示“嚴重性，值包括“界面性”、“造成不便”以及“無法工作”。Bug的優先級多少要取決于它在坐标上的位置。比方說，如果ug是界面性的而且僅影響到一個使用者的話，則優先級為4；如果bug讓某人無法工作而且影響到一些人的話，則優先級為1；如果bug導緻所有人都無法工作的話，則優先級為最高，0。

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

不是所有的bug都值得修複

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

服裝複雜邏輯和抽象有用知識之間是有差別的。有時候，資訊應該明确表示友善了解。如果你對資訊進行了抽象的話，可能反而産生相反效果并且難以了解。

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

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

幾年前我用Incremental Delivery做了一個項目。這是一個身份驗證系統，系統會讓使用者送出一些個人資料，讓第三方提供商進行驗證。

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

原因是：驗證是必須的！

提供合法資訊關乎使用者的利益。如果使用者提供的資料是錯的，驗證就不會通過也就無法使用系統。此外，大多數浏覽器都支援标準的HTML驗證，這已經足夠了。

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

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

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

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

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

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

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

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

原文釋出時間為：2018-07-04

本文來自雲栖社群合作夥伴“

Java程式員聯盟

”，了解相關資訊可以關注“

”