程式設計師似乎忘記了軟體的真正目的，那就是解決現實問題。

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

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

這裡有一個例子。

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

當使用者靠近房子時，他們會抓住手機，找到小部件，然後單擊按鈕開啟。

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

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

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

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

這是如何解決程式設計問題的一個很好的例子，而之外的任何其他程式碼。然而，就像，沒有什麼可以作為在其餘部分編寫垃圾程式碼的藉口。

並非每個程式碼都是有價值的

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

嚴重性和優先順序之間的這種權衡讓我想起了最近向我展示的模型。它被稱為優先順序矩陣，這是一種，可用於根據錯誤影響的使用者數量和嚴重程度確定錯誤的優先順序。

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

並非每個bug都值得修復

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

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

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

並非每個命令都值得編寫指令碼

幾年前，我使用進行了一個專案。這是一個身份驗證系統，要求使用者提交一些個人資料以供第三方提供商驗證。

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

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

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

在最糟糕的情況下，無法驗證自己的使用者會呼叫支援手動驗證。

並非每個功能都值得編碼

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

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

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

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

你解決的問題比你編寫的程式碼更重要！

相關文章