架構腐化的一個因素是向開發代價妥協
腐化的架構特徵有: 大量的特殊處理, 相容處理, 耦合嚴重, 積重難返. 架構都會慢慢腐化.腐化後的架構難以開發新特性, bug 難修, 牽一髮動全身, 導致測試和 QA 也很難做. 我曾看到有跨行開發愛好者發帖說, 限制模型寫程式碼時的抽象行為, 這樣程式碼更…
腐化的架構特徵有：大量的特殊處理、相容處理、耦合嚴重、積重難返。 架構都會慢慢腐化。腐化後的架構難以開發新特性，bug 難修，牽一髮動全身，導致測試和 QA 也很難做。 我曾看到有跨行開發愛好者發帖說，限制模型寫程式碼時的抽象行為，這樣程式碼更容易看得懂。人更容易看得懂的程式碼，LLM 也會更容易看得懂，因此可以快速開發且減少錯誤。我想跨行開發者大概工程量較小，習慣流水線式邏輯，如果有規模擴大的預期，思維方式不能侷限於流水線，而是使用建築工思維。預期蓋30層樓房子，即要打10米地基，預期通水通電，即要預留水池電井。這是目標明確的設計，此外還有目標不明確的設計，如房屋內某處將來要放電器，但不確定放什麼，預留插座即可。 軟體工程已有SOLID原則用於指導設計，很多時候表象上來看，遵循solid原則時實現相同的功能會跨更多的檔案，寫更多的程式碼，就短期結果來看，設計和不設計在老闆/測試和使用者看來幾乎沒分別，設計帶來的好處只有在長期才能體現。一個好的架構容易加特性、改特性、修bug，且更少引入問題。 設計需要的思考常常比直接上手開發特性要多，設計需要考慮顆粒度，直接把插座面板當瓷磚貼滿全屋，是另一種荒謬做法。以往我在開發時考慮開發週期，會做取捨，時間緊時連設計都不做，加幾個函式完事，將來的事將來說。現在借助AI，我們可以將設計的顆粒度做更小，生成的程式碼人看著會更難懂，但工程會更容易維護。增多抽象後，差一點的模型的確有可能處理不好，最好用當前最好的模型。如果只是寫腳本，那麼模型間的能力差異可能不會太明顯。 關於AI是否降低了開發者的准入門檻？我對此存疑，畢竟新人開發者的學習路徑和過往已截然不同，討論門檻高低可能沒有意義，因為我們不知道門檻被搬到哪去了。
