Gelis 技術隨筆-部落格

為什麼開發人員總是會產生過度設計的程式碼？ 問題的來源 什麼是過度設計？開發人員為什麼會過度設計？過度設計與預先設計有什麼關係？過度設計是最終導致的結果，而預先設計無非是想讓軟體的程式碼撰寫落在刀口上，減少時間的支出來產生可交付的程式碼。但是這件事情好像沒這麼簡單？即便談需求的是我，我還是會有過度設計的程式碼產生，為什麼回如此呢？但這樣真的完全不好嗎？ 會產生過度設計可能有以下幾個原因。 分析時間過久 以前筆者曾提過傳統的瀑布式容易造成分析時間過長，最終就導致過度的設計而不自知，撰寫程式碼時因為關起門來寫，一些就是 3 個月或半年，脫節的需求產出的程式碼可能大部分不是客戶要的，這也是種過度設計，只是大部分設計出不正確的程式碼。 這會產生比較嚴重的反效果，一個是因為需求的脫節，即便抓回方向，但錯誤的設計已經使系統長歪，要修復往往非常的耗時耗力，甚至打掉重練比較快的情況也可能發生。 搞不清楚客戶說什麼 所謂隔行如隔山，軟體公司常只接針對特定領域的專案，或熟悉的領域進行客製化，好比筆者10幾年前曾待過專接流通業的 SI 公司，突然接金融電信領域的專案通常前 1-2 個失敗機率極高，為什麼，因為不熟悉這個產業的通用語言。然而這樣的接案就是極高的風險，筆者甚至分享以前遭遇到的經驗，曾經有同行求救於我們公司，他們因為不熟悉該領域硬是接下後無法收尾，而求助於我們公司熟悉金融領域的部門，當然，最後我們也沒有答應協助收這個爛攤子。 所以，Gelis 認為，搞清楚客戶說什麼常重要，在三地確認客戶腦袋的想法也很種要。 需求不明確 有可能需求訪談客戶主事者不在，或者具備決定權剛好不在、又或者客戶因為處於新員交接、正在熟悉此業務，所提需求自然諸多漏洞 + 沒想清楚。這筆者就曾遇過客戶端兩位經理在訪談會議時爭吵需求執行內容，讓在場的廠商非常傻眼，很想請他們去廁所打一架看誰贏了，我就做哪一個需求。 或者純粹是使用者想太多，想變更需求。或者自己搞不懂自己想要什麼，這比較常見。 也有可能開發團隊最後自己腦補，產生了一些設計，結果最後又不同於客戶確認的規格內容，這也是種過度設計，因為你設計了一堆不需要的架構內容。 如此一來，程式碼修修改改，不產生技術債都難。 保留設計 這接續前面的需求不明確，就因為需求不明確，所以開發人員就做了許多『預先設計』的保留，...

圖片取自： https://2.blog.xuite.net/2/8/9/b/11597010/blog_3502284/txt/218534111/5.jpg 前言 在前一篇文章『 您的軟體架構夠敏捷嗎？（二）- 持續演進的軟體架構 』一個持續演進的軟體架構我們其實做到一半而已，而在上一次，我們針對一個 ATM 自動櫃員機 的需求做了初步的分析，注意了，只是個『初步』的設計，這個設計其實還看不出來程式會怎麼寫，但敏捷又不希望我們在初期進行過多的設計，但是這不代表我們完全不設計啊？這一點我在第一篇文章：『 您的軟體架構夠敏捷嗎？ 』有特別禪述，這裡就不再說講。 下面，我們就繼續將這最後一塊拼圖給完成吧～ 測試先行的軟體架構 (1). 單元測試的最小粒度 在這裡，我們使用 TDD (Test Driven Development) 為主要的開發方法，TDD 是先寫測試、爾後再撰寫實際的程式碼，這部分我想會讀到此篇文章的讀者們應該都清楚這個部份了，還不清楚可參考訪間相關的 TDD 測試驅動開發相關說明，本篇就不再詳述。 重點來了，既然是撰寫單元測試 Unit Test、那麼單元測試不就是寫一段程式碼、來去測試一段程式碼嗎？其實這樣說並不完全正確喔！如果你今天是先撰寫產品代碼、爾後才撰寫測試的程式碼（當然這就不是 TDD 了）這樣說或許還算正確，但是 TDD 指的是一種『開發的方法論』，不單只是撰寫一段程式來測試另一段程式那麼簡單， 因為許多的開發者一提到『單元』測試，就認為單元就是指一段程式碼，但其實不是的， 這裡的單元指的是應該是一個『行為』的『單元』，它是一個獨立的、可驗證的行為。它必須對系統產生可觀察的影響，而這就是我們這裡定義的單元測試的最小粒度，當然，同樣為確保測試的獨立性它又不與其他的行為有耦合情況發生。 (2). 要怎麼測試先行？ 很多教你的 TDD 沒有人在講 UML 啊？沒有關係，我這邊慢慢教你怎麼開始？ 要開始撰寫測試先行的程式碼，我們也得要知道這個系統到底要要幹嘛？對吧？根據前面的 Domain Modeling 就是我們這個系統目前的全貌的樣子，當然這個全貌還不清楚，但最少有個基本的方向，而且方向在第一個最小可行性產品的增量是可以被評估出可以做出什麼，對吧？而我們一開始，也沒有花太多的時間，進行這些 UML 的設計，對吧？算一算，我這裡繪製前面那...

這次，於 2019/05/05 受新竹敏捷社群總舵主柯仁傑的邀請，在新竹敏捷社群我分享了一個關於 您的軟體架構夠敏捷嗎？ 的主題，在這個主題當中，我分享了我個人早期多年在專案開發上的系統設計相關經驗外，與最近這五年執行顧問時，替企業規畫與設計軟體架構相關經驗的分享，過程中，與觀眾有幾個共鳴點待我在下方娓娓道來。 軟體的快速交付≠有價值的交付 課程一開始，我提到了在十多年前，我曾待過一家軟體公司，在這個環境中我們嘗試創造出一個 0 缺陷的軟體架構，詳細的內容我在上一篇文章【 敏捷的軟體架構設計：可擴展的軟體架構 】裡有說明，這裡不再重述。 接著，我提到了現在也是開發流程+開發方法百花齊放的年代，只是 Agile／DevOps 特別為人所知而已，但在這個混亂的年代分常容易讓人無所適從，尤其時初學者，因為你所處的環境有可能已經追不上大環境中的變化與改變的速度了，但是你卻還是有很多東西要學，對吧？我的意思是，最讓人無所適從的倒不是技術的推層出新，慢慢的反而是到底是改怎麼做才是正確的？這部分我們以下在詳盡說明。 先前我曾聽過某大廠的 App 能夠在一天之內交付 20 ~ 30 次的版本，這對一家軟體公司來說，維運與開發之間必須非常的運作與整合完備情況下，再加上工具的熟悉度極高，才有可能將 CI／CD 持續整合+自動化部暑到如此境界 ，有許多軟體開發商無不卯足全力渴望達成此境界！ 但是據我所知，大部分大型購物網站、或者對外的訂票系統，事實上，他們在實務上只需要一天上一個至兩個版本便足夠了！ 如果您需要在一天之內上 20-30 次版的話，通常代表著您的開發流程可能是出了問題，比如：團隊與 User 可能存在著隔閡／開發人員或小組之間沒有共識+不清楚需求就冒然的修改程式碼… 等等。 我在這邊請大家思考另一個面向問題，就是，軟體公司究竟想要什麼？做專案+產品想要的是什麼？就是【獲利】！對吧？做這麼多，改變這麼多，去了解敏捷是什麼！最終目的，就是要賺錢，但是要賺錢，就得先思考如何【獲利】呢？因為你們在進行系統開發時一定常常遇到下面問題： 測試總是花費許多時間？ 軟體的修改總是牽一髮動全身？ 無法掌控的技術債？ 失控 的技術債？ 需求確定後，才可以開始寫程式？ 架構設計完成後？才可以開始寫程式？ 對了，看到這裡答案就呼之欲出了，公司要賺錢，就是要將『成本...

敏捷底下的軟體架構 圖片取自： http://m.001zf.com/newshow.php?itemid=696 前一篇，我分享了 您的軟體架構夠敏捷嗎 ？而我寫過許多關於架構設計的相關文章，但今天這一篇，可能是最難寫的一篇？因為，在（確定的需求／沒有 Deadline 的時間壓力下），寫程式並不件難事，對吧？那麼真正難的在哪裡？真正難的是在，有限的時間 與 資源內，發展出（符合客戶需要／為客戶產生價值）的商用軟體，且這個軟體須具備一定的可延展性、擴充性、可維護性，並在企業的可控制的成本範圍內，或者，在敏捷的每一個迭代開發裡，逐漸發展成為客戶所需要的軟體，對吧？軟體公司為企業創造與量身訂做軟體也是為了賺錢，若軟體開發所投注的成本成為無限的話，虧本的生意沒有人會想做的。 傳統的軟體開發產生的架構問題 圖（一）、傳統軟體開發的前身 SDLC (Software/System Development Life Cycle) SDLC 是早期用以描述一個資訊系統，從無開始規劃、分析、建立、測試、直到最終完成的一個過程。看似無任何問題，事實上，它也運作了幾十年，似乎也確實沒有任何問題，許多團隊也是能夠創造與交付出符合客戶需求的軟體，可是，慢慢的，許多團隊與軟體公司漸漸地發現，當需求變動性高、需求不確定因素高的時候、或者在許多實際的市場機制下，軟體的『開發』與『發展』逐漸與慢慢地跟不上時代的演進 與 市場的變化了。這怎麼說呢？因為當不了解需求、不了解客戶想要的價值時，你所花的（工／成本）絕大部分是浪費的，因為軟體開發越到後期修復的成本是越高的。 以傳統瀑布式開發來說，我得先做完需求分析、才可進行系統的設計，而當系統設計完成後、才可開始進行系統的（程式碼撰寫／Implementation／實作），但問題來了，什麼叫做【系統設計完成】？難道我得在一開始，弄清楚客戶的所有需求？因為系統設計完成、也代表架構設計完成了？如果軟體架構可以在程式碼撰寫前就確定，這不就代表需求必須固定？問題是…. 這是不可能的….. 這其實是一個【雞生蛋、蛋生雞的問題】 圖（二）、雞生蛋、還是蛋生雞？ 0 缺陷的架構 = 0 擴展的軟體架構 在早期，曾經有團隊／軟體公司 將所有功能均提供在軟體產品裡，也就是大雜燴的方式，嘗試滿足市場各種不同的需求，筆者很早期待過的軟體公司也還真的經歷過這樣的模式，而在當時，...

圖片來源： https://www.magzter.com/articles/488/256119/5a2a9554df1c0 什麼都要敏捷？ 近年來，敏捷概念幾乎已經深入人心，不光是軟體業談敏捷，慢慢的可以看見各行各業也在談敏捷的思想，前幾次的 Agile 活動裡，不再像以前一樣，只會出現軟體相關產業的面孔。為什麼敏捷思想開始深入人心？其實是因為『變化』不只存在於軟體產業，要面對未來、面對變化、面對挑戰，唯有敏捷以對，隨時快速地調整自己，提升自我能力，靈活的面對這些改變，隨時再出發、隨時再出擊。 測試理念的崛起 測試可說是近十年來，發展最快速的軟體開發理論之一，早期的軟體開發將測試定義為軟體開發生命週期裡的其中一個階段，通常後期進行，也就是當軟體完成到某一程度時才進行，但是當軟體完成到某一程度時，也代表著你要對軟體做任何的需求改變、功能的改變、又或者是新增功能，所需的成本可能是非常的高的，這也是傳統的瀑布式開發慢慢為人所棄用的最主要原因之一，因為人們慢慢地察覺到，軟體的『測試』應該與『開發』這件動作密不可分才是，又或者說，測試其實應該算是軟體開發的其中一個動作，而且是非常重要的一個動作，因為經由測試，你曾能夠確認軟體正常運行無誤、經由測試才能確保軟體能夠被交付、符合客戶需求 + 如預期的運作。 而早在十多年前，TDD, Test Driven Development 的大師 Kent Beck 所撰寫的 TDD by Example 一書就已經提到這樣的觀念，先撰寫測試的程式碼 (Unit Test)，在撰寫 Production 的程式碼 從 TDD／ATDD 談傳統 SDLC 的缺陷 在 ATDD 裡提到了左移測試的 V-Model 模型，這個被討論了十多年，只是不幸的是左移這件事常常被誤解成只是將測試移轉至左側，而忽略了由上而下的測試進行。然而，當然，許多的軟體開發者也都知道，在軟體開發生命週期越後期測試所發現問題的時候，修復的代價就越高，這個狀況幾乎可以解釋為傳統 SDLC 的缺陷了，所以，這表示什麼？這意味著在軟體開發生命週期裡應該盡早進行測試才能夠降低這些風險，因為在這些年來因為沒有盡早測試而產生的問題如下： 測試人員可能沒有參與軟體的初始規劃，通常導致測試對系統了解有限+最後分配給測試的資源又嚴重不足 許多需求，架構和設計缺陷都沒有再一開始被『發...

前言 最近在客戶端遇到一個需求，由於時常發生一種情況就是 Developer 撰寫完程式碼簽入 TFS 時，總是會將無法編譯通過的程式碼簽入，通常，在直覺上想到的就是 TFS Build 的『閘道簽入』 透過閘道簽入可以做到『先提交程式碼』到後端 TFS 的 Build 主機，交由 Build 主機確認該程式碼可以建置通過，當然，一般來說，所謂的完整地 CI 必須經由 Build Server 建置通過 + Unit Test + Source Analysis 完成的才表示程式碼是可交付、且沒有問題，當然，流程上是沒有問題的！標準的 CI 確實是如此，但是…. 有另外的一個問題來了！因為，所謂的閘道簽入它還是將『無法編譯的程式碼』簽入到 TFS 中了，而且，熟悉 TFS 的應該都知道，Developer 還是可以選擇將『在本機保留我的暫止的變更』的勾勾消掉，甚至略過驗證組建… 所以，這根本還是無法達到客戶的需求，客戶雖然希望由 CI 機制通過、出去的程式碼才是標準、可運行的，但是，希望開發人員可以在本機先進行『建置』動作，並確認建置動作是 OK 沒有問題的！才開放讓開發人員簽入程式碼。 TFS Check-In Policy 而這時，客戶提了個需求，說：TFS 有沒有 Check-In Policy 是可以在 Client Visual Studio 端確認建置過才可簽入呢？就像是 StyleCop 可以在 Client 先掃過程式碼，確認符合團隊的 Coding Style 後才允許簽入。 聽到這需求後，我當下想了想，身為 Visual Studio 擴充套件開發魔人的我，寫過各式 VS Extensions 還上架了一個 MyORM Extension ，甚至還推出了『C# Project Templates』的線上課程，當然 VsPackage 是不同的，但是我也寫過 VsPackage，卻沒寫過 TFS Check-In Policy 這…他日恐遭人話柄 XD 需求分析： 使用 C# 撰寫一個 VS 擴充套件，就像 StyleCop 一樣，只是這個套件必須呼叫 Local 端的 MSBuild 進行專案的建置動作，如果建置不過，就不讓 Developer 簽入程式碼，並秀出錯誤訊息。 這個 Check-In Policy 也必須可以被包裝成 VSIX 的可...

前言 最近接觸一些開發團隊，發現還是有許多團隊雖然已經導入 TFS 或 VSTS (以下都簡稱為 VSTS)，但是仍然只是將 VSTS 當作 Source Control 使用而已，不要說 PM 或 PO 沒有將 WBS 或是 Task(後面都簡稱為 Task) 鍵入 VSTS 中的 Work Items 外，就算有鍵入 Work Items ，也沒有強制要求團隊成員 Check-In Policy (簽入原則)，將完成的程式碼簽入 VSTS 的時候，關聯相關的工作項目 Task 。 如果開發團隊連最基本的原始檔管控、Work Item 、工作管理等都沒有做的完善，而原始檔管控又算是軟體專案開發最基本功的部分，如果連基本功都無法落實的話，那麼，後續的 Agile/Scrum... 其實都不用談了。 引發的問題、隱憂 筆者先前，有許多文章在探討團隊開發、個人工作管理與共同規範的關係與問題，這也是筆者先探討 問題、隱憂的原因，因為撇開團隊所使用的開發方法、合作模式 Agile/Scrum/CMMI 等方式不談，因為流程在這邊並不是重點，但是工作若沒有被有效管理，你如何掌握每一個工作項目所花的工時、無法掌握每一個工作項目的工時，更不要說你想要掌控團隊成員中，每一個人手上有哪些工作，有那些已經完成、那些正在進行中、哪一些還未開始，以及哪一些工作由哪一位成員進行 (工作分派狀況)。 在以前，大約十多年前，2005 年左右，當時 TFS 還未盛行，當時筆者的公司、訪間的軟體開發團隊會使用 EXCEL 來控管團隊的工作進度，當時，一樣控管得很好，只是會有幾個缺點， 團隊成員要另外開啟 EXCEL 與其他成員共享 Sheet，每天Update工作 主管要引導團隊成員 Update EXCEL 內容 主管對團隊成員間，要花比較多的溝通成本 團隊成員之間，要花比較多的溝通成本，討論程式碼 (因為 EXCEL 內的說明無法直接與程式碼相關連) 使用 EXCEL 管理專案當然不是不好，以前的開發人員這樣管理專案，不也管理得很好，相信很多讀者心裡是這樣想著，沒有錯，但是 (有但書)，開始有使用者回饋 (進入 UAT) 階段， 團隊成員 A 簽入的程式碼究竟是為了某個 Task 而修改、或是因為從某個原始 WBS 展開的 工作項目，User 測過後有 Bug 所...

關於規範這件事 還記得筆者先前曾經說過一句話： 軟體開發的問題一直都不在於『技術』、『工具』的不斷推陳出新。 而在於，你的做事方法有沒有想要推陳出新、有沒有想要『改變』而進步？ 因為世界永遠只會更進步、永遠都是自己在原地踏步！ RAD 無罪論 這讓我想起了很久以前，網路上曾紅極一時的一個討論，「RAD 無罪論」，當時因為 RAD （Rapid Application Development）工具，如：Borland Delphi、C++ Builder 開始盛行，網路上出現兩派人馬爭論著，究竟 RAD 的出現是好是壞 好的一方認為： 透過 RAD 工具，開發可省下不少的時間，也是 IDE 開發工具的趨勢，且使用 RAD 工具不代表就不需要瞭解底層運作細節。 壞的一方認為： RAD 工具使的一些初學者不需要瞭解底層運作細節，甚至不需要瞭解太多的OOP 物件導向概念、 Object Pascal 語法，就可以拼湊出一個應用程式，因此 RAD 工具會產生對於軟體開發一堆一知半解的工程師。 還記得當時一位 Delphi 書籍的作者：陳寬達先生，他在他的著作「Delphi 深度歷險」裡面記載了當時在 TANet 論壇上比較經典的討論，陳寬達先生將比較中肯的回覆記載在他的著作裡面，如下： 所以，這也就是說，不管是任何工具、技術，其實都跟你個人或團隊 進步 其實一點關係都沒有。 好比使用 RAD、IDE 工具、好用的精靈，不代表就不需要去瞭解底層的運作細節。 也就是說，其實重點都在「人」的身上。工具終究只是工具，就看你怎麼使用而已。 套句流行語： 這不是南北拳的問題，是你的問題。 另外，小編之前所開的課程「 架構設計好簡單系列 - 如何設計符合團隊的範本精靈 (Project Template) 」中，也不是只是教導各位如何建立 C# Project Templates 然後包進 VSIX Project 裡面這麼簡單而已，所教導的是， 如何制訂團隊共同規範 ， 注意 ， 是團隊共同規範 ，是的，我不斷的在課程中強調， 這是「團隊共同規範」的設計，不是只是設計「Project Templates」 ， 而且，我也再三的強調，這個 Project Templates 是在團隊共同規範成形後，也就是在團隊已經擬聚共識、具備共同開發規範...

在規劃好團隊的 StyleCop Source Analysis Rules 後，開發人員除了可以在開發階段透過 StyleCop 掃描自己撰寫的程式碼是否符合團隊所制定的 Coding Standard 外，在 Check-In 每日開發的工作項目的程式碼，除了 Team Build 外，開發主管接著會想做的事應該就是，如何將 StyleCop Source Analysis Rule 與 TFS Check-In Policy 整合，也就是說限制開發人員，只有符合 StyleCop 掃描且通過的程式碼才允許簽入 TFS 中 閱讀全文 from 點部落-gelis 技術隨筆 http://ift.tt/1Uex8NT