會想要寫這 30 天的原因在於以下兩個理由 :
然後在 2 年前時,寫了一個馬克的軟體架構小筆記
這個 30 天的鐵人賽。
https://ithelp.ithome.com.tw/articles/10265496
但是在寫的中途我就有發現我對這個領域的東西理解太少,寫完這 30 天後發現有些只是寫出來而以,很多東西實際上有沒有用我好像自已也搞不太清楚,有些東西的前因後果也有點模糊,白話文就是寫得有點心虛 ~ 這樣寫完好像不算完賽啊,一直以來我覺得我自已寫的程式碼維護性應該算不錯,但是後來卻慢慢注意到 :
那只是我自已覺得好維護
就所謂的自以為是,是主觀還是客觀的覺得好維護都很難知道,所以這一次鐵人賽,我以三個面向來整理了一下我現階段所知道增加維護性的手法。
根據 ISO/IEC 25010 來看,它將軟體品質進行了以下的分類 :
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
事實上這個也是我年輕時在找的一個好的系統
比較明確的定義,然後我們這 30 天要研究的,就是 Maintainability,然後它又分類成如下 :
首先第一個 Modularity,它的目的就是不要變成大泥球,所有東西都混在一起,它希望每個模組就是可以獨立,這樣在修改時,才不會影響到太多東西
第二個 Reusability,這個應該就不用多說太多,雖然很多工程師喜歡從 0 至 1 自已幹 ( 包含年輕的我 ),但一個好維護的系統當然不是這樣。
第三個 Analysability,我自已是比較喜歡用理解性來表達,如果一個系統可分析性 很差 ( 很難理解 ),那也代表你在追問題與進行修改時,都會像在通靈一樣。
第四個 Modifiability,就是你會不會改了一個東西,又炸了另一個東西,或是又藏了一個炸彈。
第五個 Testability 應該就不用多解釋,一個系統不能測試,給我在多錢我都不想改,因為我什麼都動不了。
不過有點不確定是不是我看漏,ISO/IEC 25010 本身好像沒有說明這幾個分類的衡量指標,至於如何衡量,我在後面的文章會提到我尋找的一些東西。
順到說一下,這是我在找資料時從這本書《Good Code, Bad Code》看到的圖,我也覺得很棒。
圖片來源: Good Code, Bad Code
接下來這 30 天,會來來尋找一些 :
探索增加可維護性與儘可能降低軟體工程複雜度的手法
基本上會分三個面向 :
首先 point 這個面向就是比較小方面的,例如 function 、variables 或啥這種小地方,但這個地方應該是所有工程師最常面對的地方,所以這裡會比較以 code review 的角度來看。
再來是 line 這裡就是比 point 方面在大一點,但是不會因為用了它,就可能整個軟體架構需要調整,desgin pattern 就主要是這個方向的東西。但是這裡會說的比較少,因為已經太多了。
最後是 plane,它就是你整個專案的架構與準則,然後我自已會將他放在可以增加最多維護性的理由在於;你想想如果你的軟體架構是什麼都不分層,純 CRUD 的寫法 ( 假設是在業務複雜,且產品會一直迭代情況 ),你覺得 function 寫的在好維護,你覺得有用嗎 ?
最後簡單說一下,會用『 馬克版 』來當這 30 天的命名,到不是我自戀還啥,而是因為在看這維護性的東西,我發現每個人都有不同的想法,也有不同的好維護,所以這個 30 天的主題實際上 :
我 ( 馬克 ) 覺得比較客觀能增加好維護的知識、經驗與想法分享
所以才這樣命名,至於有沒有人要拿來用,就自已判斷吧 ~ 我又沒收錢,我也不保證這就是好啊啊啊 ~ 但至少這個應該都有走在軟體工程史那條巨人的肩膀上,我自已很少會發明東西的 ~
開始吧 ~ ( 又要過渡日如年的 30 天了…… )