有時候，解決問題比寫程式碼更重要！
當你手裡有把錘子的時候，看所有的東西都是釘子。
有時候程式員往往會陷入為了寫程式碼而寫程式碼的怪圈，沒有意識到程式碼是為了解決現實問題的。當問題有更簡便的解決方案時，寫程式碼未必就是必須。記住： 你不是別人花錢讓你在螢幕上寫字元的程式猿，而是讓你解決問題的專業人士。 Fagner Brack 的總結非常有見地。
錘子擺在一塊木板上。木板有一顆被錘彎的釘子。
程式設計師似乎已經忘記了軟體的真正目的是什麼，是解決現實世界的問題。
50 年前的 1968 年開過一場會，會議名字叫做軟體工程工作會議，是有 NATO 科學委員會贊助的。那時候大家已經開始注意到軟體日益成為社會的基礎。然而，軟體也變得太難以理解。在那次會議之後，變成開始變成一個行業。軟體開始擺脫商業人士的控制。
不管軟體此後走上了什麼樣的發展道路，仍然存在著業務與軟體開發（或者按照那次會議首次的說法，“工程”）分離的問題。 如果開發者太過狹隘地專注於開發，就會錯過了他們編寫的軟體背後的目的。以至於可能會看不到並不需要編寫任何程式碼的潛在解決方案。
舉個例子。
有一家初創企業是做裝置的，這種裝置可以讓人利用藍芽解鎖開門。跟這種裝置進行通訊的視覺化介面是一個小程式，就算是門鎖上它也能看見。這個玩意兒有一個按鈕叫做 “開門”。
當用戶接近房子時，他們會拿出手機，找到那個小程式，然後點選按鈕開門。
有人看過這套流程之後問道：
如果我們用的是藍芽並且假設拿著這部手機的任何人都能進入房子的話，為什麼還需要讓某人拿出手機然後按按鈕呢？當它檢測到裝置距離在 1 米之內時讓們開啟不就行了嗎。這樣我們就不用付出設計和編寫視覺化介面的成本了！
這個藍芽應用的故事是聚焦過窄的絕佳例子： 目標是用盡量方便地開門。如果感測器是無線的話設計視覺化介面毫無意義。
如果你意識到企業想要實現什麼以及對使用者的價值是什麼的話，你可以將哪方面的知識跟你對技術可能做到什麼的知識融為一體。只有這樣你才會具備足夠的資訊來想出更好的答案並且得出結論說介面對產品來說毫無必要。
這是一個解決程式設計問題的出色例子——除了編寫解鎖功能以外再無編寫任何額外程式碼之必要。然而，就像技術債務一樣，任何東西都不應該用來作為編寫垃圾程式碼的藉口。
不是所有的程式碼都值得編寫
這裡推薦一下我的JAVA架構學習交流群：835544715 ，想要學習Java高架構、分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊都有整理，送給每一位JAVA小夥伴，有想學習JAVA架構的，或是轉行，還有工作中想提升自己能力的，正在學習的小夥伴歡迎加入學習。
有時候，修補重大 bug 未必是優先事項。假設你是加密數字貨幣交易所，如果你的系統允許出現一次賬戶副本的話，人為干預會是成本效益最佳的解決方案——如果修補漏洞的代價很大的話。《 ofollow,noindex">告別狗屎程式碼，請記住這 11 條編碼祕訣！ 》建議你看一下。
嚴重性於優先順序之間的權衡讓我想起了同事最近給我看過的一種模型。這個模型叫做優先順序矩陣這是一個二維模型，可用於確定 bug 的優先順序，其根據是影響到的使用者數以及嚴重性。
二維優先順序矩陣圖示。Y 軸表示受影響的使用者，分別包含 “一個”、“一些” 以及 “全部” 這些值。X 軸表示 “嚴重性，值包括 “介面性”、“造成不便” 以及 “無法工作”。Bug 的優先順序多少要取決於它在座標上的位置。
比方說，如果 ug 是介面性的而且僅影響到一個使用者的話，則優先順序為 4；如果 bug 讓某人無法工作而且影響到一些人的話，則優先順序為 1；如果 bug 導致所有人都無法工作的話，則優先順序為最高，0。
前面說過的單賬戶副本問題算是影響了一個使用者的使用便利性這類，因此其優先順序為 3。
不是所有的 bug 都值得修復
開發者想給一切都寫指令碼是非常常見的。然而，一些重複性的任務未必值得自動化。如果你打算隱藏一些有關底層命令如何工作的基本知識的話，就不需要花時間去寫指令碼了。
服裝複雜邏輯和抽象有用知識之間是有區別的。有時候，資訊應該明確表示方便理解。如果你對資訊進行了抽象的話，可能反而產生相反效果並且難以理解。
在 CLI 裡面使用一些型別的低階命令而不是抽象了知識的高階命令（如 Git aliases）會更有用。
並不是所有的命令都值得寫指令碼
幾年前我用 Incremental Delivery 做了一個專案。這是一個身份驗證系統，系統會讓使用者提交一些個人資料，讓第三方提供商進行驗證。
團隊想要開發一個非常棒的欄位驗證功能。然而，驗證這個功能每次 sprint 計劃都被列到低優先順序的位置，眼看著截止期限越來越近了。到最後，團隊發現這項功能根本就沒有必要。
原因是：驗證是必須的！
提供合法資訊關乎使用者的利益。如果使用者提供的資料是錯的，驗證就不會通過也就無法使用系統。此外，大多數瀏覽器都支援標準的 HTML 驗證，這已經足夠了。
最糟糕的情況下，本人無法驗證通過的使用者會打電話給支援進行人工驗證。
不是每一項功能都值得編寫
作為開發者，如果你理解了自己試圖要解決的問題的話，你就能想出更好的程式碼，甚至有時候根本不需要編碼。你不是別人花錢讓你在螢幕上寫字元的程式猿。你是別人花錢來幫忙解決問題的專業人士。
不過，如果試圖不經思考只想用技術解決每一個問題，就好像把程式碼當成銀彈的話，你就很難理解什麼東西對客戶有價值，也很難想出很好的點子。
你的目的以及所寫程式碼的目的都是為了產生價值，讓世界更美好，而不是為了滿足你以自我為中心的世界觀。
有句話是這麼說的：“當你手裡有把錘子的時候，看所有的東西都是釘子。”
最好還是先有顆釘子這樣你才會考慮需要一把錘子。
也就是說，如果你本來就需要釘子的話。
想要學習Java高架構、分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊免費獲取 架構群：835544715