寫程式最困難的地方

最近跟同事討論一個功能模組的設計有什麼問題，當我很流暢的找出問題點並且提供幾種不同的方向時。同事就問我說，要怎麼樣才有一個「標準做法」去設計這些系統呢？

我只能告訴他，這一切都要根據當下狀況判斷。在過去的學習經驗中，我們總是學著所謂的「標準答案」因此會很習慣的認為有一個標準做法。同時，在學習撰寫程式的時候，我們參考的教科書、文章、課程也都會有一個完整的案例。

在這樣的狀態下，就會發生所謂不知變通的狀況。也就是每一次都會想著要套用一個公式進去，然而這樣的系統很多時候會變得難以維護甚至完全不符合產品、客戶、使用者的需要。

即使我們能夠針對一個情況判斷，也仍然會因為人、時間等因素讓情況改變。這也是在上週的軟體是一種生物這篇文章所提到的觀點，我們是需要不斷的更新、改變設計來對應當下最為真實的狀況。

這就表示，即使我們再怎麼努力的設計一個當下「完美」的系統，依舊還是會面臨需要被調整跟修改的情況。這也是在軟體開發中最為困難的一個能力，要做到所謂的「剛好」是非常困難的。同時，在許多軟體開發的技巧中，會追求所謂的「解耦（Decoupling）」這個特性，就是為了盡可能的減少無法靈活調整的情況。

要能夠在這樣的狀況下應對自如，大多數時候需要扎實的基本功以及足夠的經驗。因為有經驗，就能夠快速的想像一個系統至少具備怎樣的特性、規格、盲點，進而避開這些問題，這也是為什麼在同一個領域轉換會比較常見的原因。

至於基本功，就是對於程式的運作、電腦科學的理解，也就是軟體工程師的素養所提到的「素養」問題。當我們嘗試去解決一個複雜的問題，最好的方法就是找到切分問題的方式，由大到小的分解，最後的結果就會回到這些關於電腦、程式運作原理的概念上。

然而，大多數新手容易遇到的是，剛開始工作都會被分配到「小單元」的工作，往往是由小而大的堆疊，因此常常看不見完整系統的樣貌。要解決這樣的狀況，由比較資深的工程師所規劃、設計並且切分的工作就變得極為重要。

簡單來說，寫程式最困難的地方往往不是技術上的問題，而是如何對當下的狀況正確判斷並且建立良好協作的狀態，才會是最為困難的地方。

封面圖片使用 Unsplash 上 insung yoon 的作品，有想聽的主題可以透過匿名提問告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。