Re: [討論] 一段想重構的程式碼

[StupidGaGa (笨嘎嘎)]

※ 引述《tyc5116 (累人啊....)》之銘言：
: ※ 引述《oaz ()》之銘言：
: : 如果對 debug 只有小影響，那應該是要另外去想其它較好的 debug 方式
: 原本還以為可能PO錯板,沒想到得到這麼多人的回應..(笑)
: 單純就是我的看法和主管不同,只是反應出來看看大家的看法而已
: 我也覺得稍微作個處理就可以分辨是哪個模組進到func了
: 但是主管就覺得這個方式不妥@@
: 因為他資深,我資淺,對於他說會對於debug造成麻煩
: 我只是"感覺"會比原來的方式好才對,但我並沒辦法量化
: 也無法百分百的保證,新的方式一定就好比較好,大致上就是這樣
: 推文也有說到,先重構就對了,但是要作過測試
: 的確,這是應該做的,但這不是我的問題點
: 測試我也會做(雖然我對測試不是那麼在行)
: 而是說,我重構了,測試了,真的沒問題了,但是程式看起來重構前和重構後差滿多的
: (至少覺得我站在主管的立場來看,會這樣想),對於公司來說,就是個風險
: 基於這樣,我才會先詢問主管的意見,既然他不同意就算了
: 我的出發點在於,日後在修改維護會很有彈性,便利
: 程式碼越少越不會出錯,別人看不看的懂是別人的事(註)
: 實際上那些模組的其中一個func是去讀取xml的資料,功能是對的
: 但是演算法效率不好,才讓我有想改的念頭,先讓程式碼在每個模組變成共用(重構)
: 日後有時間再改良func(改寫),當重構的部份OK了,以後改寫就不用四處都要跟著改
: 大致上就是這樣
: 註:這就是我個人的黑暗面了...哈,我會想要盡量將進階的寫作技巧應用在裡面
:    一方面程式碼少,就容易懂
:    (當然也不是刻意的在賣弄技巧,何況我也還不到那個程度)
:    前面的人把程式碼寫那麼爛,也沒考慮到後面的人阿
:    我反而是想說,在確保程式碼正確的情況下,能盡量用進階技巧就盡量用
:    程度不好的看不懂就不敢亂改,程度好的....也不擔心你改了XD
:    (有遇過一段傳了好幾個人用都OK的程式碼,到你手上就出了一堆bug,
:     查了半天才發現.原來是上一個人把大家共用的底層亂改的情況嗎XD)
:    也許有人會想說,就把共用的程式碼包成lib就好啦,嘖嘖....
:    因為我有遇到阿,大家有用了很久的程式碼,只有偶爾會出錯而已,所以大家就將就用
:    好不容易(其實是湊巧)我找到了他的bug的可能原因,那相關的定義式咧??
:    抱歉被包起來了
:    那source code咧?
:    抱歉,傳了太多人,沒有source code了......@@


如果不想看落落長的感想文章，
請直接拉到最下面的網址，一定會有幫助。
如果想看，要鞭也請小力點...

說實在的，這文章回響很大，
主要是因為，牽扯到程式的「架構」跟「維護」這兩種一定會矛盾的事情，
每個程式設計師都會因為個人的經驗而有不同。


我想所有的程式設計師都會有相同的毛病，
那就是「眼見為憑」、「前人的錯誤並不會發生在我身上」、「舊的程式碼不如新的」
即使身邊的人都建議，但還是要自己碰到釘子再說，
但「前人」跟「自己」都是人，並不會高竿多少...


今天跟公司的前輩(上司)討論到這問題，前輩寫了很多年，
他都可以給我許多的幫助跟經驗。

我說：前輩，你認為程式的「穩定」、「維護」、「效率」哪個比較重要？

前輩：你覺得哪個重要？

我說：我認為 穩定 > 維護 > 效率。

前輩：跟我說一下理由

我說：穩定是程式的基本條件，一個常掛掉、BUG的程式不能賣錢，也是自找麻煩(除錯)。
      維護跟程式除錯時間與增刪功能有關，維護性高代表不須太多時間在這程式上面。
      效率是我最後的考量，程式寫得好增加0.001秒，只要使用者無感都沒差，
      當然一定有例外，每分鐘幾十萬資料上下的那種，或者不同需求、大小等，
      但這並不代表我不考慮效率，而是我在穩定與維護之後才會增加效率。

前輩：這跟年資有關係。

      一開始在學校是要求你寫出來，能跑。

      經驗多一點時，隨便寫都能跑，你就會開始考慮到穩定性，
      因為你隨便寫都寫得出來，但是你的BUG很多。

      經驗在多一點時，穩定性夠了，你會覺得怎麼自己以前寫的程式都看不懂，
      程式加個功能或刪掉功能都很麻煩，BUG出現時很難找希望找快一點，
      不要每次都全看才能知道BUG可能在哪，你就會覺得維護很重要。

      經驗在多一點時，像我就會覺得穩定跟維護已經是最最基本的要求，
      而直接針對效率下手了。

      但是「穩定」與「維護」常常都會「效率」相衝突，甚至三者相衝突，
      這就要看這專案的大小程度來衡量了。

我心想：靠，我被間接說菜了~T.T



前面的推文我都在說「容易維護」，因為根據自我的經歷，
我大部分都在幫別人或自己的程式做除錯、增刪功能等等，也會開發新程式，
我常常遇到的問題就是，
1. 程式是外包寫的，沒說明文件
2. 編寫程式的人已經離職、或者在職但他自己因為時間久遠也看不懂或忘了
3. 整份程式幾乎沒有幾個地方有註解
4. 新增或刪除功能時，幾乎牽一髮動全身
5. 看繼承之前先寫族譜
還有更機車的不說了。

但我很幸運的，我也遇過不少漂亮、容易維護的程式。
大致上都有我之前推文說的那兩個共通點。

1. 直覺式架構、程式碼
有人會說：「直覺這東西跟個人經驗有關，你的直覺別人不一定看得懂，直覺太抽象。」
那我會說：「別人無法一眼就看出來就是你的問題。」
直覺就是要一眼就看的出來，
難道你直覺「一個香菸圖像，外面包個圓圈，從左上到右下畫個直線」是禁止開車的符號？
難道你直覺變數名稱Length的意義是平方？
難道你直覺Class Dog裡面放的是天氣資料？
難道你直覺變數相加，c = a + b，要這樣寫 c = (a * 100 + b * 100) / 100？
有多少程式設計師還是不重視「直覺式」！
iPhone連猩猩都會滑了，程式碼內容至少也讓後人看得懂吧！！

2. 獨立性高
BIOS還是組合語言的那時代，更動一行程式碼有時就必須開會一個星期或一個月，
真的就是牽一髮動全身，舊時代的恐龍BIOS。
很不幸的，現在都高階語言時代了還是有不少人這樣做，
當初規劃架構沒考慮到，導致後面要改倒不如重寫。
獨立性高不是單以程式碼的角度來看，是以功能面+程式碼來看。
況且獨立性高不代表會有「程式碼重複」問題，但是多執行緒有時必須要這樣。
如果今天A、B內的func一模一樣，當然寫成一個就好，
但是今天A、B內的func少許不同，依照程式決定是否寫成一個，
(但我大多會分開寫，而不是用同一個func再加上判斷)
舉例來思考：
小算盤當初只有+-，如果寫出*/是否需要動到一推變數？
今天加了*/功能會不會對之前的+-有影響？
老闆不爽+，要把它刪除是否困難？會對其他-*/有影響嗎？

以上說的是個通則，一定會有例外情況，
大量處理、記憶體或硬體容量極小、銀行相關金錢交易系統等等。


謝謝大家也聽我廢話那麼多，
也許有人認為我不是頂尖的程式設計師，所以我說的話都沒參考價值。
也許有人意見跟我相左，這很好，因為這樣子才會互相學到更多經驗，聽到更多東西。

我喜歡的文章之一

http://local.joelonsoftware.com/wiki/The_Joel_on_Software_Translation_Project:
你絕對不應該做的事


當你肚爛別人程式看不懂時，也請想想自己寫了多少；
當你覺得別人程式易懂易改時，請讚嘆他是如何寫的；
當你覺得別人程式不好時，請先思考他為什麼這樣寫。

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 114.33.20.138
→ elvispoetic:短網址：http://goo.gl/V47KOR
→ StupidGaGa:感謝，我還不太會用短網址，謝謝^^
推 bobju:關於[直覺式的設計]這點的認知,要看是從哪個角度去理解.以
→ bobju:iphone為例,它是設計得給終端user在[應用上很直覺],但這背後
→ bobju:是[相當刻意地設計]出來的,設計原型不知打掉重練過多少次,才
→ bobju:會有最終決定可以拍板定案的型態.通常一個看起來很直覺的設
→ bobju:計,背後都不知融合了多少面面俱到的考量,絕非[直覺]就能想到
→ bobju:;另外,從工程面來講,你提出一個[直覺]的提案,是否有經過組織
→ bobju:的審查?符不符合組織的共通規範?會不會對組織既有的運作有影
→ bobju:響,這些都不是一個人說了算
→ bobju:我想你在程式面當中所提到的[直覺],其實就是盡量符合共同規
→ bobju:範的意思,符合大多數在軟體開發領域的人的認知,而不是光憑自
→ bobju:己想到什麼就寫什麼
推 bobju:另外,你提到 穩定 > 維護 > 效率, 基本上已是標準答案了,沒
→ bobju:什麼好挑剔的,只不過基於學長立場,若不再補充一些東西,只怕
→ bobju:就顯不出學長比學弟長在哪裏? :P
推 CRPKT:推這篇
→ CRPKT:程式碼的直覺我和 bobju 意見一樣, 那是取決於讀者的背景
→ CRPKT:若確定接手者有特定的知識基礎, 即使使用特殊知識也是直覺的
推 littleshan:穩定/維護/效率是要看場合的，沒有一定的答案
→ tyc5116:bobju最後一句滿好笑的,哈~~XD
→ littleshan:遊戲就是效率第一 玩家很難接受畫面遲鈍的遊戲
→ littleshan:相較之下對小bug的容忍度就比較高
→ bobju:其實 穩定>維護>效率 是符合大部份的考量,當然要找特例肯定
→ bobju:也不少.甚至我還可以說預算/時間/政治都是影響穩定/維護/效
→ bobju:能的變數,只不過要這樣展開的話,就是case by case了
推 FukadaKyoko:前輩說得很中肯!
推 xw:推
推 cwlin0416:不能說你錯, 但我也覺得時間點很重要, 通常開發的情況
→ cwlin0416:是沒有時間讓你把程式寫的十全十美
→ cwlin0416:對我來說維護是最重要的, 程式的架構有切出來, 後續才是
→ cwlin0416:讓你專心的提高程式的穩定性及效率
→ cwlin0416:甚至是分工, 這也是 SA&D 的重要