別依賴「試誤法」寫程式
from Pixabay
你身邊的人都是怎麼開發的呢？
有個情況很普遍，我不得不為此發聲：「請停止用『試誤法』寫程式！」
這尤其適用於準備知識不夠紮實（指為開發所做的功課太少）的開發者。但如下所述，其實它本質上是一個「開發習慣」議題。
我們先看看維基百科對於「試誤法」的闡述：
嘗試錯誤法，又稱試誤法（英語：trial and error），簡稱試錯，是用來解決問題、獲取知識。此種方法可以視為簡易解決問題的方法中的一種，與使用洞察力／直覺或理論推理的方法正好相反。
就像這句「此種方法可以視為簡易解決問題的方法中的一種」說的，在我看來，試誤法常常會得到 workaround 等級（指雖不能根本解決，但能暫時繞過問題的方案）的答案——這肯定不是好事。
不過，我承認，「試誤」在軟體開發中，是一個常見且實用的手段。
我自己寫一些邏輯時，也常常在 jupyter notebook 先執行嘗試執行一下程式碼片段，看看結果，以確保我的想法沒錯。但，這只是一種輔助。
本文想強調的是：不要以「試誤」作為開發的基調，或解決問題的主要方式。換言之，不要濫用試誤。
否則那將是一場災難。
無數次 trial and error，看起來勤勤懇懇，實際上是最低效的開發手段。我覺得，試個兩、三次行不通，就應該重新思考問題的本質——而非繼續嘗試。
以下我們從除錯（debug）與開發（develop）兩個角度，來看看「濫用試誤法」帶來的困境。
Debug 時的試誤
Debug 和試誤法似乎挺搭的，不是嗎？一步一步嘗試，直接全都正確了為止。
看似如此，但實際上正好相反。
把試誤心態用在 debug，恰恰是讓 bug 不斷滋生的主要原因。
試誤的基本心態是「結果好，一切好」，但我們 debug 往往不僅是為了把當下的錯誤消除掉而已。
更多時候，我們想要知曉錯誤發生的「原因」為何，以及是否存在會引發相關錯誤的其它原由——這些都是試誤法不關心的。
所以，debug 時，試誤只能作一種次要的輔助手段，我們的目標應該是「找出錯誤的原因，並想辦法防止同類型錯誤的發生」。
沒找出問題的根源，那後續可有的「試」了。
開發時的試誤
很遺憾，並非只有 debug 才容易讓人陷入試誤的濫用。以「試誤心態」進行開發，在我看來也非常普遍！
這樣的開發者的什麼樣的習性？以開發一個新功能為例，常常有以下流程：
- 想到什麼就寫什麼——單純把自然語言的需求，「直譯」成程式碼，我常戲稱為「機器翻譯」。
- 從頭到尾寫完，然後看看程式運行會不會出錯。（寫完也不重構一下，就像文章草稿完成後，直接發表）
- 發現執行結果有錯，看一下錯誤訊息，調整程式碼——說真的，願意好好看錯誤訊息，已實屬不易！很多試誤型開發者，是連訊息都不看就繼續埋頭苦試。
- 可以了！好，下一個功能。
這樣的開發方式有什麼問題？看起來好像也不算太差呀？
確實，在簡單的需求時，這種開發方式（或說心態、習性）可能是「效率最高」的做法！——姑且不論程式碼品質。
試誤處理不了變化與複雜
但只要需求變化、複雜化，包括後續的擴充，這樣的開發方式就不太妙了。
因為缺乏全局觀與開發工具（套件、框架）相關重要知識——講白了就是文件看太少，畢竟之前的開發成果主要是靠「試」出來的。
此時「試誤型開發者」會陷入一個迴圈：
- 發現程式執行結果不如預期。（未必是無法執行，但就是不如預期）
- 不確定原因為何。（因為常常都是靠「試誤」在解決問題）
- 不斷調整寫法、不斷觀察程式執行結果。
- 試了又試，終於正常了！
- 因為問題沒根本解決，所以不久後又出問題——回到前述 1
隨著專案愈來愈複雜，程式碼行數不斷擴張，這種情況也將隨之增加。
簡言之，試誤無法有效處理複雜。處理複雜，需要你有系統地思考、更全面的知識——最好多看文件、多問 ChatGPT。而非簡單的試誤。
但在簡單的需求下，試誤卻是一個快速完成開發的誘人捷徑。總是依賴試誤法開發，在複雜的情況就容易原形畢露。
試誤依賴的根本問題
現在有了 ChatGPT 這個強力工具，理論上我們的開發水準都在相應提升。
但是，我必須說，對於依賴試誤開發的人而言，ChatGPT 對他們帶來的提升，可能是最小的——why？
因為這類人很容易把試誤心態帶入 ChatGPT 的使用習慣，所以就變成了「向 ChatGPT 要答案」：
- 可以了！→下一題
- 不行耶！→修改問題再問一次
反正我要的就是答案，至於原理是什麼，暫且不論。
沒錯，這只是另一種方式的試誤而已。（或許我們可以稱之為「AI 輔助試誤法」）
這樣做絕對可以讓開發變得更快，卻未必能變得「更好」。
小結：試誤是機器的事
試誤是機器的事，因為機器擅長此道。沒有人能夠在 1 秒內發出 1000 個請求，但機器卻能輕鬆辦到。
直白地說，如果軟體工程師終有一天會被 AI 取代，那我相信第一波被取代的，肯定是這些「只把 AI 當作試誤工具」的人。
這樣的用法，相當於把自己當「試誤機器」在運作，但人終究不是機器。
在快速試誤的競賽中，人和機器，誰更有機會勝出呢？