原文地址：The Problem You Solve Is More Important Than The Code You Write
程式設計師們是否已經忘記軟體的真實目標——那就是去解決真實世界的問題？
50年前，在1968年，由北約科學委員會舉辦了軟體工程會議。在那時，人們開始注意到軟體逐漸變成了社會的基本組成部分，然而，它也變得越來越難理解。在該會議之後，程式設計開始成為一整個行業，它也逐步脫離業務人員的控制。
從那時起，無論程式設計發展成什麼樣，一直存在著一個問題，即業務和軟體開發的界限如何劃分。如果開發者過於專注開發，他們往往會忽視正在開發的軟體背後的目標。這樣就會錯過那些其實不需要任何程式碼的解決方案。
這裡有一個例子：
有一家初創公司正在開發一款裝置，目的是讓使用者可以通過藍芽開啟家門。和裝置通訊的介面是一個widget元件，即使鎖屏時也可見，那上面只有一個按鈕“開門”。
當使用者靠近家的時候，他們需要拿起手機，找到元件，然後按下按鈕開門。
有人看了整個流程後，問道：
如果我們使用藍芽，並且商業模式允許任何擁有手機的人進入房間，那為什麼需要使用者拿起手機按按鈕？讓裝置探測手機距離，靠近1米時，自動開門就可以了。這樣我們就不需要花精力去設計以及開發這個元件了。
這個關於藍芽的小故事很好的說明了過於專注實現的結果。這個專案的目的是為了花最小代價地開門，那隻要有無線感測器，設計使用者介面就是沒用的。
如果你瞭解業務目標和業務價值，然後把這些資訊和技術可行性相結合，只有這樣，才能讓你有足夠的資訊去得出結論，那就是，這款產品不需要介面。
這個例子也很好的說明了，除了核心程式碼，如何不寫程式碼去解決問題。當然，沒有任何理由可以成為編寫垃圾程式碼的藉口。
不是所有程式碼都值得編寫
有時候，嚴重bug的修復並不是高優先順序的。這有一個案例，使用者的存款記錄會出現重複兩條。如果解決問題的開發成本過高，人工干預可能是最佳的方案。
嚴重性和優先順序之間的權衡讓我想起最近一個大學同學跟我提及的模型。它叫做優先順序矩陣，是一個二維模型，可以通過bug影響的使用者數量和影響程度來決定bug優先順序。
Y軸展示的是使用者影響數量，值包含一個、多個、所有人。x軸展示的是嚴重性，值包含不好看、困擾、阻斷工作。bug的優先順序通過軸上的位置來決定，例如：一個外觀問題，影響了一個使用者，那優先順序是4；一個問題阻斷多個人的工作，那優先順序是1；如果一個問題阻斷了所有人的工作，那它就是最高優先順序，0。
上文提到的那個重複存款記錄的問題只是讓一個使用者使用困擾，所以，優先順序是3。
不是所有Bug都值得修復
開發者常常會寫程式碼去做任何事情。但是，一些重複度高的任務其實不值得自動化。如果只是為了隱藏底層命令如何執行，那沒必要花時間去編寫指令碼。
對複雜邏輯的封裝和對有用知識的抽象是有區別的。有時，傳達的資訊應該更直接，讓別人便於理解；如果你抽象了它們，反而起到負面作用，會讓它變得難以理解。
在命令列使用多種低階命令比使用抽象的高階命令（例如Git別名）更有用。
不是所有指令碼都值得編寫
幾年前，我在做一個增量迭代的專案，這是一個身份驗證系統，要求使用者提交一些個人資料給第三方驗證。
這個專案一開始準備做一個酷炫的欄位驗證提示特性。然而，隨著截止日越來越近，這個功能的優先順序在每一期迭代中都被往後排。到最後，團隊認為，把這個酷炫的驗證特性放在第一位開發是沒有意義的。
原因是，驗證是強制性的！
這個特性的目的是為了引導使用者提供正確資訊，但如果使用者填了錯誤資訊，他們就無法進入系統。所以，無論有沒有這個功能，使用者都會自發的提供正確資訊。此外，瀏覽器自帶的html驗證功能已經足夠好了。
在最糟糕的情況下，那些無法驗證通過的使用者更願意尋求人工幫助來通過驗證。
不是所有特性都值得開發
作為一個開發者，如果你理解你要解決的問題，你就有能力寫出更合適的程式碼，甚至，不需要程式碼。你不應該被當做一個只在螢幕上敲字元的碼農，你應該是一個專業解決問題的人。
如果你試圖用技術去解決每一個問題，而不經過思考，把程式碼當做解決任何問題的銀彈。你會變得越來越難理解你能給使用者帶去的價值，變得越來越難提出好意見。
你的目的，以及寫的程式碼的目的都是去創造價值，讓這個世界變得更好，而不是去滿足你自認為的世界應該是怎麼樣的。
有句俗話：如果你有的只是一個錘子，那其他東西都看起來像一個釘子。
正確的應該是，先有一個釘子，然後你再考慮是否需要一個錘子。
也就是說，你首先需要一個釘子。