iT邦幫忙

2024 iThome 鐵人賽

DAY 1
0
Software Development

一個好的系統之好維護基本篇 ( 馬克版 )系列 第 1

Day-01: 之開篇與軟體工程維護性

  • 分享至 

  • xImage
  •  

同步至 medium

會想要寫這 30 天的原因在於以下兩個理由 :

  • 工作多年,以產品類的軟體來看,我覺得最重要的是這個,因為我們每天都會迭代程式碼,每一天都會都加複雜度,然後當你想改時,看到他已經爛了 8 年了,還會有力氣改嗎 ?
  • 軟體工程在維護性這一塊,我覺得是一個有點難判斷好與壞的技術,像性能啥的就有很明確的指標,例如花多少時間處理,記憶體花了多少,但在好維護這一塊就一直有點曖昧。

然後在 2 年前時,寫了一個馬克的軟體架構小筆記這個 30 天的鐵人賽。

https://ithelp.ithome.com.tw/articles/10265496

但是在寫的中途我就有發現我對這個領域的東西理解太少,寫完這 30 天後發現有些只是寫出來而以,很多東西實際上有沒有用我好像自已也搞不太清楚,有些東西的前因後果也有點模糊,白話文就是寫得有點心虛 ~ 這樣寫完好像不算完賽啊,一直以來我覺得我自已寫的程式碼維護性應該算不錯,但是後來卻慢慢注意到 :

那只是我自已覺得好維護

就所謂的自以為是,是主觀還是客觀的覺得好維護都很難知道,所以這一次鐵人賽,我以三個面向來整理了一下我現階段所知道增加維護性的手法。

何謂好維護呢 ?

根據 ISO/IEC 25010 來看,它將軟體品質進行了以下的分類 :

https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

  • Functional Suitability
  • Performance efficiency
  • Compatibility
  • Usability
  • Reliability
  • Security
  • Maintainability

https://ithelp.ithome.com.tw/upload/images/20240915/20089358dbqjlF0vtq.png

事實上這個也是我年輕時在找的一個好的系統比較明確的定義,然後我們這 30 天要研究的,就是 Maintainability,然後它又分類成如下 :

  • 模組化(Modularity)
  • 重用性(Reusability)
  • 可分析性(Analysability)
  • 可修改性(Modifiability)
  • 可測試性(Testability)

首先第一個 Modularity,它的目的就是不要變成大泥球,所有東西都混在一起,它希望每個模組就是可以獨立,這樣在修改時,才不會影響到太多東西

第二個 Reusability,這個應該就不用多說太多,雖然很多工程師喜歡從 0 至 1 自已幹 ( 包含年輕的我 ),但一個好維護的系統當然不是這樣。

第三個 Analysability,我自已是比較喜歡用理解性來表達,如果一個系統可分析性 很差 ( 很難理解 ),那也代表你在追問題與進行修改時,都會像在通靈一樣。

第四個 Modifiability,就是你會不會改了一個東西,又炸了另一個東西,或是又藏了一個炸彈。

第五個 Testability 應該就不用多解釋,一個系統不能測試,給我在多錢我都不想改,因為我什麼都動不了。

不過有點不確定是不是我看漏,ISO/IEC 25010 本身好像沒有說明這幾個分類的衡量指標,至於如何衡量,我在後面的文章會提到我尋找的一些東西。

順到說一下,這是我在找資料時從這本書《Good Code, Bad Code》看到的圖,我也覺得很棒。

https://ithelp.ithome.com.tw/upload/images/20240922/20089358yADzwn31WJ.png
圖片來源: Good Code, Bad Code

手法

接下來這 30 天,會來來尋找一些 :

探索增加可維護性與儘可能降低軟體工程複雜度的手法

基本上會分三個面向 :

https://ithelp.ithome.com.tw/upload/images/20240915/2008935872LaKTTa3P.png

首先 point 這個面向就是比較小方面的,例如 function 、variables 或啥這種小地方,但這個地方應該是所有工程師最常面對的地方,所以這裡會比較以 code review 的角度來看。

再來是 line 這裡就是比 point 方面在大一點,但是不會因為用了它,就可能整個軟體架構需要調整,desgin pattern 就主要是這個方向的東西。但是這裡會說的比較少,因為已經太多了。

最後是 plane,它就是你整個專案的架構與準則,然後我自已會將他放在可以增加最多維護性的理由在於;你想想如果你的軟體架構是什麼都不分層,純 CRUD 的寫法 ( 假設是在業務複雜,且產品會一直迭代情況 ),你覺得 function 寫的在好維護,你覺得有用嗎 ?

結論

最後簡單說一下,會用『 馬克版 』來當這 30 天的命名,到不是我自戀還啥,而是因為在看這維護性的東西,我發現每個人都有不同的想法,也有不同的好維護,所以這個 30 天的主題實際上 :

我 ( 馬克 ) 覺得比較客觀能增加好維護的知識、經驗與想法分享

所以才這樣命名,至於有沒有人要拿來用,就自已判斷吧 ~ 我又沒收錢,我也不保證這就是好啊啊啊 ~ 但至少這個應該都有走在軟體工程史那條巨人的肩膀上,我自已很少會發明東西的 ~

開始吧 ~ ( 又要過渡日如年的 30 天了…… )


下一篇
Day-02: 設計原則 SOLID - SRP
系列文
一個好的系統之好維護基本篇 ( 馬克版 )30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言