發表文章

目前顯示的是 10月, 2019的文章

再談 SOLID 原則,Why SOLID?

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則,Why SOLID? SRP 單一職責原則,定義、解析與實踐 物件導向設計原則:開放封閉原則,定義、解析與實踐 Why SOLID? 在 前一篇文章 中介紹 SOLID 對一個工程師的影響,這裡再稍微補充一下為什麼軟體開發會需要 SOLID 原則? 軟體複雜的本質 專案經常會歷經「商業邏輯調整」和「快速且多變的需求」,這都不是開發環節所能控制的,但是一個專案會「遇到困難」常常是因為  糟糕的程式設計  和其他技術層面導致。 其中  糟糕的程式設計  又可分成三個因素: 程式碼變更 Bug 修復 複雜度控制 在添加功能前應該  閱讀代碼並細心設計 ,但實際上更常發生的是,開發者選擇 直接在程式碼上面堆疊新的程式碼 。 新舊版本  和  意圖不同  的程式碼錯綜複雜之下,會讓專案難以在不引發連鎖反應的情況下增加功能。最後新的功能引入 Bug,從而導致另一個 Bug,然後一個接著一個,這樣的事情不斷發生。 在  沒有做過可擴展性設計的程式碼  上進行擴展功能,常常是火上加油! 那為什麼不把程式「設計」成可擴展就好了呢? 開發者知識普遍不足 一個充滿外行人的產業 開發者們來自不同的背景,且有大量不同的方式去解決問題,但是一個開發者應該具備什麼樣的知識體系,並沒有一個廣泛的共識。 更不幸的是,許多開發者在學校裡面學到的知識是過時的,學校提供的程式設計課程並未給學生做好準備。這些課程通常只關注程式語言的功能,但是 ... 掌握一門程式語言並不能使你成為軟體開發者,正如掌握一門自然語言並不能使你成為作家 學校所教的知識,並不是大部分軟體開發者的工作內容。 開發者也許能編寫一個可運行的程式碼,但若要 回頭去擴展程式碼卻 常 常 是艱難且冒險的 。 軟體開發過程中,開發者需要做出無數個選擇,加上每個開發者用不同的方法解決問題,助長了難以維護、難以擴展的程式碼。最終讓  系統設計的思想溝通  變得困難( 工程師必須花費大量時間閱讀程式碼 )。 不論是開發者還是管理者都需要對  軟體複雜的本質  做管理。為了編寫出更容易應對變化的程式碼,我們必須填補基礎認知方面的空白。 導入設計原則 若有一些

淺談物件導向 SOLID 原則對工程師的好處與如何影響能力

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則,Why SOLID? SRP 單一職責原則,定義、解析與實踐 物件導向設計原則:開放封閉原則,定義、解析與實踐 物件導向 SOLID 原則對工程師的好處與如何影響能力 前言 為了感謝部落格一直以來都有人在閱讀,讓我一直有經營下去的動力。所以想寫一個系列 學習 SOLID 原則 2 年後的心得文章。這心得文章包含自己使用 SOLID 兩年的總結,並且以自己的理解簡化 SOLID 原則,希望幫助新手工程師縮短「SOLID 原則是文字天書」的時間。 從第一次接觸 物件導向 SOLID 原則  至今已經兩年了,一開始覺得「SOLID 原則是文字天書」,到現在 Coding 時常融入 SOLID 的思想來「設計」程式。 所以 SOLID 原則到底是什麼? 》SOLID 原則其實是物件導向「設計層面」的思維與定律。 大學時期程式設計課程中所學的物件導向,其實只是在介紹程式語言有提供  物件導向的哪些特性 ,卻 從未有人教導如何透過物件導向的特性撰寫程式碼 ,甚至沒人告訴你為什麼要用物件導向開發程式。 然而 SOLID 原則就是物件導向開發的指導方針,若以多個角度來看這些原則,會發現 SOLID 已經指出  物件導向的優點   以及 程序式程式碼隱晦的缺點 。但這不代表物件導向沒有缺點,要是沒有妥善運用 SOLID 原則的話,物件導向對專案的傷害絕對不比  程序式程式碼  低!但這留給後續的文章來解釋,首先來看看 SOLID 的好處與重要性。 SOLID 原則對專案的好處?  SOLID 原則對專案的影響很大,當專案一點一滴的導入 SOLID 原則的程式碼,不少複雜的程式碼慢慢被簡化,被 簡化的程式碼可以降低複雜度,讀懂程式碼的時間從原本需要花 20 分鐘閱讀,到只需要花費 2 分鐘閱讀 。縮短閱讀時間對專案來說是一件好事, 一般來說工程師「閱讀程式碼」的時間常常大於 「 新增/修改程式碼」的時間 ,畢竟要先讀懂才能動手嘛,因此  縮短閱讀 程式碼 時間 等於 縮短 「 新增/修改程式碼」 程式碼的時間 。 優點:降低程式碼複雜度 => 縮短閱讀程式碼的時間 => 減少維護專案程式碼的時間 你可能會覺得,為什麼 S