英文原文： The problem you solve is more important than the code you write.

　　譯/_小生_

　　軟件的目的有時會被遺忘

　　程序員似乎忘記了軟件的真正目的，那就是解決現實問題。

　　50年前，在1968年，由北約科學委員會主辦的軟件工程工作會議召開。那時，人們開始注意到軟件正在成為社會的基本組成部分。然而，它也變得難以理解。在那次會議之后，編程開始成為一個新的行業。它開始擺脫商界人士的控制。

　　無論從那時起編程的路徑如何，業務和軟件開發之間的分離仍然存在問題 - 或者是第一次召開會議時的“工程”。如果開發人員過于專注于開發，他們可能會錯過他們編寫的軟件背后的目的。他們可能看不到不需要任何代碼的隱藏解決方案。

　　這里有一個例子。

　　有一家初創公司正在建造一種設備，允許一個人使用藍牙解鎖他們家的門。與設備通信的可視界面是一個小部件，即使手機被鎖定也可見。它只有一個名為“打開門”的按鈕。

　　當用戶靠近房子時，他們會抓住手機，找到小部件，然后單擊按鈕打開。

　　有人看著那個工作流程并問：

如果我們使用藍牙，我們的商業模式接受任何擁有手機的人都可以進入房子，為什么我們需要讓某人拿起手機并按下按鈕？當檢測到設備靠近1米時，我們允許門解鎖。這樣我們就不需要為設計和編寫可視化界面付出代價了！

　　藍牙故事是狹隘焦點的一個很好的例子：目標是以最小的努力解鎖門。如果傳感器是無線的，那么設計可視界面是沒有意義的。

　　如果您了解業務正在嘗試實現的目標以及對用戶的價值，您可以將這些知識與您對該技術可能性的了解相結合。只有這樣，您才能獲得足夠的信息以獲得更好的答案，并得出結論。

　　這是如何解決編程問題的一個很好的例子，而不必編寫除解鎖功能代碼之外的任何其他代碼。然而，就像技術債務一樣，沒有什么可以作為在其余部分編寫垃圾代碼的借口。

并非每個代碼都是有價值的

　　有時，嚴重bug的修復可能不是優先事項。如果您是加密交換，并且您的系統允許重復存款一次，那么如果解決問題的成本很高，人工干預可能是最佳的成本效益解決方案。

　　嚴重性和優先級之間的這種權衡讓我想起了一位同事最近向我展示的模型。它被稱為優先級矩陣，這是一種二維模型，可用于根據錯誤影響的用戶數量和嚴重程度確定錯誤的優先級。

　　前面描述的單個重復存款問題屬于影響一個用戶的不便類別。因此，優先3。

并非每個bug都值得修復

　　作為開發人員，嘗試為所有內容編寫腳本是很常見的。但是，一些可重復的任務可能不值得自動化。

　　復雜邏輯的封裝和有用知識的抽象之間存在差異。有時，信息應該明確，以便易于理解。如果你抽象它們，它們會產生相反的效果并且更難理解。

　　在CLI中使用某些類型的低級命令比抽象知識的高級命令（如Git別名.）更有用。

并非每個命令都值得編寫腳本

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

　　團隊想要建立這種奇特的現場驗證功能。然而，隨著截止日期變得越來越近，驗證在每個sprint規劃中被排除優先級。最后，該團隊發現，首先存在的花式驗證沒有任何意義。

　　原因如下：驗證是強制性的！

　　提供有效信息符合用戶的利益。如果用戶提供了錯誤的數據，則不會對其進行驗證，也無法使用該系統。此外，大多數瀏覽器都支持足夠好的標準HTML驗證。

　　在最糟糕的情況下，無法驗證自己的用戶會調用支持手動驗證。

并非每個功能都值得編碼

　　作為開發人員，如果您了解了您嘗試解決的問題，那么您將能夠提供更好的代碼，有時甚至根本沒有代碼。您不是為在屏幕上書寫字符而付費的 Code Monkey。你是一個專業的解決問題的人。

　　您編寫的代碼的目的是為了創造價值并使現有世界變得更美好，而不是滿足您對自我世界應該是什么的以自我為中心的觀點。

　　有人說：“如果你擁有的只是一把錘子，那么一切看起來都像釘子一樣。”

　　最好先釘一個釘子，以便你可以考慮錘子的需要。