我們是程式設計師，所以編寫程式碼就是我們要做的工作，不是嗎？但是，我們的工作比整天在螢幕前敲擊鍵盤上的按鍵要複雜得多。如果跳出程式語言，框架和流程的範疇，超出了測試套件、衝刺和Jira的範疇，那麼您總會發現需要解決的問題。 

作為程式設計師，我們首先是問題的解決者。我們解決了其他人遇到的問題，並使用我們可以使用的所有工具提供瞭解決方案。

軟體不是目的

讓我們先解決這個問題：軟體本身並不是我們工作的目的。您編寫的軟體必須與現實世界中的問題相關，否則，您將獲得一個無用的，儘管漂亮的程式。不僅如此，應該首先評估您編寫的軟體對問題的解決程度。該軟體是用於解決特定問題的工具。使用您可以想到的最佳軟體：它乾淨，易於閱讀，並以所有正確的方式使用所有正確的模式。如果該軟體沒有執行您需要做的事情，那就沒用了。

瞭解問題域

軟體開發的第一步應該是瞭解問題。花費所有必要的時間來完全瞭解您要做什麼。這適用於小型任務和整個專案。我認為這甚至適用於整個專案。努力解決錯誤問題而產生的問題很難解決。在大多數情況下，它們涉及大量的重構並浪費大量的工作（您花了大量時間建立的塊）。更不用說當您必須向客戶解釋整個應用程式為什麼出錯時會遇到的尷尬了。 

完美是足夠好的敵人

既然我已經提出了理由，那麼您應該專注於解決問題，而不是編寫程式碼，我想提醒您帕累託原理，或更普遍地稱為80/20規則。作為程式設計師，我們有時會被解決的一個很酷的問題所困擾，以至於忘記了問自己：“雖然我在研究正確的問題嗎？”。時不時地休息一下，看看為什麼做自己的事情是值得的。以下是一些可以幫助您的問題：解決此問題有多少價值？有另一種更快的方法嗎？我能想到一個容易實現的妥協方案嗎？ 

這些問題並不總是可以自己解決的（除非您在自己的專案中進行）。值得與利益相關者聊天，看看他們真正關心的是什麼。如果可以，請收集使用者的反饋。通常，快速的A / B測試，可以對下一步的工作大有幫助。實驗並迭代！

選擇你的戰鬥

並非每個問題都需要技術解決方案。您不需要其他任何應用程式。一切都是有代價的。您編寫的程式碼浪費了您的時間和資源（編寫和執行）。另外，擁有的程式碼越多，必須維護的程式碼就越多，出現問題的機會就越大。過程中的一小步手動操作可以為您節省大量開發工作和許多潛在問題。有時，手動操作是正確的方法，尤其是在專案開始時。這將使您有機會了解該步驟的重要性，需要多久執行一次，為您的專案增加多少價值。此外，它使您有時間深入思考您的過程，而手動步驟可以為您提供軟體無法實現的靈活性。簡而言之，手動更新軟體比做新的事情要好。Netflix在我們今天所知道的巨大的流媒體龐然大物之前，是通過手動向訂戶的DVD傳送電子郵件開始的。（來源）

最好的程式碼是根本沒有程式碼

我敢肯定，您現在已經注意到，新增程式碼會帶來風險。遲早會出現錯誤。您所擁有的程式碼行數與維護程式碼的工作量之間存在非線性關係。換句話說：更多程式碼意味著更多問題。 

我強烈建議您使用現成的解決方案來解決常見問題。

(banq注：最好的程式碼是沒有程式碼，但是移植現有解決方案也是有風險的，因為解決方案的上下文不同，學習現有解決方案也是有成本的，最好的程式碼是少而精的程式碼，將精力集中到核心問題，其他通用方案採取現成解決方案)