過度設計在網路上查找到一段解釋

Overengineering (or over-engineering, or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design.
指以過於複雜的方式設計產品或提供問題解決方案的行為，其中可以證明用更簡單的解決方案且與現有解決方案相同的效率和有效性

而原原作者所提到的
Code or design that solves problems you don’t have.
解決您沒有的問題的程式碼或設計。

也是筆者很喜歡的話，
而對於筆者來說，
過度設計主要成立的前提，
有兩個重要的可能，

一是現在、二是外來。

那麼何謂是現在，
最為常見的就是前幾日所提的基礎設計原則-SOLID。

在SRP中筆者有示範過
把一個單一職責更為細分，
例如汽油把他定義為能源，
能更為明確．
但如果切的更為細緻呢？
約切缺細，能量轉換，
切到連質能守恆公式都出來了。
想當然的這就是過度設計。

要達成OCP，
在程式中很常使用的interface，
在實作上其實很常發生一個事情
為什麼要這樣做，因為前面這樣做。

偶而會出現一個特別的現象
明明可以肯定不會需要用介面卻又使用的狀況，
例如某個功能的作用就只是轉拋
所以他根本不會做任何的邏輯，最多只有防呆的狀況下

答案是肯定的不需要，
所以在某些狀況下一昧地追求著OCP，
反而會適得其反。

而除此之外還有非常多例子，
可以看到不論是過度遵守、沒必要遵守都會是屬於過度設計，
而這些往往都是依據實務定義與決策來去做判斷。

而未來的不確定性，會很容易造成過度設計，
如筆者的程式是為了鐵人賽所寫的，
但其中有很多地方是不需要的，
這也是明確屬於過度設計的一環。

可以看到在此之前，
都是盡可能要求各位遵循著某種規範，
而這就是軟體設計的目的，
筆者也一直想達到讓人一看就懂，
並且簡單簡潔的程式。

但要達成這個前提，
除了時間與技術上的學習，
還有很重要的明確的定義。

但往往現實中就有很多的定義不明確，
而其中的彈性，
就是由人來做為把關。

筆者舉幾個接近的例子

在其他縣市工作，明明不在戶籍地生活，卻投戶籍地的票？

一個汽車是否有人，會導致法律設計等等都大有調整
那麼這個設計我要預留嗎?
還是出現之後再製作嗎?

無人載具算載具嗎？

如果某個罪的不成立是基於一定程度上可信的內容，
AI是根據現有資訊來搜尋生成的，
那麼如果AI基於現有資訊生成來評論，
那麼這個罪會成立嗎?

而如果有人相信AI所說，
並且跟人說，
那這個會成立嗎?

---筆者覺得很多都寫得心有戚戚焉

從"過度"的不是設計，而是對未來的不確定性
https://buttondown.email/tech_management_mindset/archive/guo-du-de-bu-shi-she-ji-er-shi-dui-wei-lai-de-bu/
上文中提到的連結，且也是英文受
https://www.mindtheproduct.com/overengineering-can-kill-your-product/?utm_source=tech_management_mindset&utm_medium=email&utm_campaign=guo-du-de-bu-shi-she-ji-er-shi-dui-wei-lai-de-bu

為什麼開發人員會過度設計？
http://teddy-chen-tw.blogspot.com/2023/07/blog-post.html

規劃、規劃再規劃-如何避免過度設計的系統？
https://ariontechs.medium.com/%E8%A6%8F%E5%8A%83-%E8%A6%8F%E5%8A%83%E5%86%8D%E8%A6%8F%E5%8A%83-%E5%A6%82%E4%BD%95%E9%81%BF%E5%85%8D%E9%81%8E%E5%BA%A6%E8%A8%AD%E8%A8%88%E7%9A%84%E7%B3%BB%E7%B5%B1-e792553515a7

除此之外筆者在想要不要介紹
迪米特法則（Law of Demeter, LoD）
畢竟俗稱就是有五就有六。

而以下是過度設計的介紹。

在軟體開發領域，過度設計（Overengineering）指的是在設計和實現軟體時，過分追求過多的特性、結構、抽象層次或複雜性，而這些都超出了實際需求和問題的範圍，從而導致了不必要的複雜性、低效率以及難以維護的代碼。

過度設計在軟體開發中可能表現為以下幾個方面：

過度抽象和複雜性： 引入過多的抽象層次、設計模式和框架，導致代碼難以理解，並使開發變得複雜。

過多的功能和特性： 將過多的功能添加到軟體中，即使這些功能對最終用戶並不重要或根本不需要。

過度通用化： 設計過度通用的解決方案，嘗試應對未來可能出現的需求，導致代碼過於複雜，並可能未能很好地滿足實際需求。

過多的優化： 在追求極致性能的同時，花費過多的時間和精力進行微小的優化，而忽略了更重要的部分。

過度的設計文件： 產生過多而冗長的設計文件，消耗時間，並可能在開發過程中過度限制了靈活性。

過度設計可能會導致以下問題：

開發時間增加： 複雜的設計和結構可能需要更多的時間來實現，延遲了產品的交付。
難以維護： 過度複雜的代碼難以理解和修改，增加了維護成本。
資源浪費： 在不必要的特性和優化上浪費了時間和資源。
性能下降： 過多的抽象和複雜性可能導致性能下降，因為運行時的開銷增加。
因此，在軟體開發中，適度的設計和平衡非常重要，避免過度設計，確保專注於真正的需求，並保持代碼的簡潔和可維護性。