為什麼開發人員總是會產生過度設計的程式碼？

為什麼開發人員總是會產生過度設計的程式碼？

問題的來源

什麼是過度設計？開發人員為什麼會過度設計？過度設計與預先設計有什麼關係？過度設計是最終導致的結果，而預先設計無非是想讓軟體的程式碼撰寫落在刀口上，減少時間的支出來產生可交付的程式碼。但是這件事情好像沒這麼簡單？即便談需求的是我，我還是會有過度設計的程式碼產生，為什麼回如此呢？但這樣真的完全不好嗎？

會產生過度設計可能有以下幾個原因。

  1. 分析時間過久

以前筆者曾提過傳統的瀑布式容易造成分析時間過長，最終就導致過度的設計而不自知，撰寫程式碼時因為關起門來寫，一些就是 3 個月或半年，脫節的需求產出的程式碼可能大部分不是客戶要的，這也是種過度設計，只是大部分設計出不正確的程式碼。

這會產生比較嚴重的反效果，一個是因為需求的脫節，即便抓回方向，但錯誤的設計已經使系統長歪，要修復往往非常的耗時耗力，甚至打掉重練比較快的情況也可能發生。

  1. 搞不清楚客戶說什麼

所謂隔行如隔山，軟體公司常只接針對特定領域的專案，或熟悉的領域進行客製化，好比筆者10幾年前曾待過專接流通業的 SI 公司，突然接金融電信領域的專案通常前 1-2 個失敗機率極高，為什麼，因為不熟悉這個產業的通用語言。然而這樣的接案就是極高的風險，筆者甚至分享以前遭遇到的經驗，曾經有同行求救於我們公司，他們因為不熟悉該領域硬是接下後無法收尾，而求助於我們公司熟悉金融領域的部門，當然，最後我們也沒有答應協助收這個爛攤子。

所以，Gelis 認為，搞清楚客戶說什麼常重要，在三地確認客戶腦袋的想法也很種要。

  1. 需求不明確

有可能需求訪談客戶主事者不在，或者具備決定權剛好不在、又或者客戶因為處於新員交接、正在熟悉此業務，所提需求自然諸多漏洞 + 沒想清楚。這筆者就曾遇過客戶端兩位經理在訪談會議時爭吵需求執行內容，讓在場的廠商非常傻眼，很想請他們去廁所打一架看誰贏了，我就做哪一個需求。

或者純粹是使用者想太多，想變更需求。或者自己搞不懂自己想要什麼，這比較常見。

也有可能開發團隊最後自己腦補，產生了一些設計，結果最後又不同於客戶確認的規格內容，這也是種過度設計，因為你設計了一堆不需要的架構內容。

如此一來，程式碼修修改改，不產生技術債都難。

  1. 保留設計

這接續前面的需求不明確，就因為需求不明確，所以開發人員就做了許多『預先設計』的保留，以應付未來當 user 又說這個需求要做時，預先保留的設計便派上的用場。但此舉也有可能讓一些設計從未需要使用到，最終會導致累贅又未使用的爛 code 越來越多，最後搞不清楚哪一些是現有 Business 使用的？哪一些是預留的？最後導致複雜度增加，而形成重構困難，因為一些後來根本用不上的設計參雜其中，反而增加技術債。嚴重時，可能部分打掉重練，這又形成一種嚴重的浪費，因為最糟情況專案也有可能因此失敗。

  1. 試驗新技術

這也是種常見的情況，當有一個全新的專案時，因為通常全新的專案沒有過往的技術包袱，於是開發人員就想利用這個專案練練使用新的技術是常有的事情，但新的技術可能有一定的學習曲線，在有時程壓力的專案裡當遭遇到技術的使用問題時，往往得花費數日，甚至無法解決，最後反而壓縮到專案的驗收時間。

之前我曾在［軟體開發之路(https://www.facebook.com/groups/361804473860062/permalink/8216510725056025/)］貼過就是探討 Side Project 測試新技術的相關貼文，試驗新技術比較適合在 Side Project 上練功，因為專案通常不是你新技術的試煉場，這得看情況，在時程壓力之下，不熟悉的技術比較容易產生過多的設計 或 錯誤的設計爾後最後形成另一種技術債。

結語：

其實我認為，過度設計這件事情在專案開發中是一種，像 Bug 一樣無法避免的正常情況，正常發揮就對了！XD 什麼？老師..你在說什麼！？我是說，軟體設計本來就會先設計、爾後才撰寫程式碼，難道你沒想清楚就開始寫 code？😂好.. 那既然無法避免，那如何降到最低？或者是怎麼拿捏分寸？其實這很難回答，沒有標準答案，總之你得搞清楚方向、有個全貌+並收斂、還有知道應該要做什麼時，才開始動工寫 code。

好了，後來有人問我，到底是過多的設計寫 code 傷害比較小，還是不進行預先設計就寫 code 的傷害比較小？我的建議是，我還是寧可稍微進行多一點點的預先設計會 "優" 於完全的不設計，我的多一點點是=真的就是 "一點點" 不多不少，多個 5% 就好，因為多 5% 的預先設計頂多是這 5% 打掉從練；好過『完全不設計』就『直接寫』 code 最後整個打掉重練來的更好。

迷之音：

不能 10% 嗎？其實這沒有標準答案，就像在【API 設計原則】一書中 Dave Thomas 曾說過：過早設計是愚蠢的、但不提早設計是更愚蠢的。

延伸閱讀：

(1). 關於『預先設計』 vs. 『過度設計』
https://www.facebook.com/groups/361804473860062/permalink/7175055019201606/

留言

張貼留言

這個網誌中的熱門文章

什麼是 gRPC ？

圖片
圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 .
閱讀完整內容

什麼是 gRPC（二）- 來撰寫第一個 Hello World 吧！

圖片
前言 上一篇 什麼是 gRPC ，筆者大致介紹了 gRPC Service 的基本概念，這一次，我們就來小試一下身手，撰寫一個 Hello World （迷之音：嘗試新技術時，總是得先來一個 Hello World ～我不想違背這良好傳統阿阿阿阿） 使用環境 Visual Studio 2019 .NET Core 3.0.100-preview3-010431 開始進行 撰寫 gRPC 除了先準備好基礎環境、選定一種 作業系統／ 程式語言 Language 外、（Framework／SDK／Runtime）等環境備妥後，就可以開始撰寫， (1). 開始撰寫 gRPC 第一步就是先定義 .proto 協議了 上一篇筆者提到，gRPC 的 Server 與 Client 必須使用相同的協議才可進行溝通，一般來說，你應該使用 protoc.exe 編譯器先行編譯過 greet.proto 協議檔，並產出 C# 程式碼檔案後才可繼續，而在 Visual Studio 2019 裡，拜 MSBuild 之賜，已經有人預先寫好 .Target 檔案了 （什麼是 MSBuild ？什麼是附檔名 .Target 檔案可參考： MSBuild .targets 檔案 ） 筆者先撰寫一個 SayHelloWorld 方法如下： 在協議裡，除了在 service Class 撰寫要公開存取的方法外， 必須在提供『傳入訊息型態』、『回傳訊息型態』 ，這邊我先定義兩個 message，一個是『 HelloMyFirstgRPC 』、另一個是『 HelloMyReply 』 在撰寫 proto 協議檔時，建議先決定 message 回傳型態與傳入的型態，那麼 Visual Studio 2019 會有 InteillSense 的完整支援。不得不說 Visual Studio 2019 在 .proto 協議編輯上的支援已經算不錯了。 注意： 一般來說，Visual Studio 2019 會在背景裡自動編譯 .proto 協議檔案，但始有可能不會有任何提示，所以您也可以自行使用命令列工具進行手動編譯，如下圖，若編譯失敗會出現錯誤訊息，如下圖顯示 return 關鍵字錯誤： protoc.exe 編譯器 & 相關 MSBuild Tools 會隨著 NuGet 套件在 Vis
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當
閱讀完整內容