對大多數的程式人來說,撰寫程式碼或許是令人開心的一件事情,但我相信,有更多人視閱讀他人所寫成的程式碼為畏途。許多人寧可自己重新寫過一遍程式碼,也不願意接收別人的程式碼,進而修正錯誤、維護它們、甚至加強功能。

這其中的關鍵究竟在何處呢?若是一語道破,其實也很簡單,程式碼是別人寫的,只有原作者才真的了解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感,深怕被迫去碰觸其他人所寫的程式碼。這是來自於人類內心深處對於陌生事物的原始恐懼。

讀懂別人寫的程式碼,讓你收穫滿滿
不過,基於許多現實的原因,程式人時常受迫要去接收別人的程式碼。例如,同事離職了,必須接手他遺留下來的工作;也有可能你是剛進部門的菜鳥,而同事經驗值夠了、升級了,風水輪流轉,一代菜鳥換菜鳥。甚至,你的公司所承接的專案,必須接手或是整合客戶前一個廠商所遺留下來的系統,你們手上只有那套系統的原始碼(運氣好時,還有數量不等的文件)。

諸如此類的故事,其實時常在程式人身邊或身上持續上演著。許多程式人都將接手他人的程式碼,當做一件悲慘的事情。每個人都不想接手別人所撰寫的程式碼,因為不想花時間去探索,寧可將生產力花在產生新的程式碼,而不是耗費在了解這些程式碼上。

很遺憾的是,上述的情況對程式人來說很難避免。我們總是必須碰觸到其他人所寫成的程式碼,甚至必須了解它、加以修改。對於這項需求,在現今開放原始碼的風氣如此盛行的今日,正如之前的「程式設計2.0」文中所提到的,你可以透過開放原始碼學習到新的技術、學習到高手的架構設計,大幅提高學習的效率及效果。你甚至可以直接自開放原始碼專案中抽取、提煉出自己所需的程式碼,站在巨人的肩膀上,直接由彼端獲得所需的生產力。從這個觀點來看,讀懂別人所寫的程式碼,就不再只是從負面觀點的「被迫接收」,而是極具正面價值的「汲取養份」。
 

進公司以來,到目前為止也接過不少別人寫的程式碼
的確很多時候一如文中所說『寧可自己重新寫過一遍程式碼』
因為別人寫的程式風格可能跟自己的差很多...
最重要的可能是埋藏許多不知名的陷阱、地雷
三不五時賞給你一個access violation
今天下班之前,就跟阿明發現一個陳年的bug
對已經delete的物件呼叫其release method執行dll提供的釋放資源的方法
>"<  被不是自己埋的炸彈炸個正著

雖是如此,接別人寫的程式碼也可以學到不少東西
程式碼的佈局、命名風格、...  時常發現許多嘆為觀止的地方
比VCL提供的TThread更輕巧好用的執行緒物件
比TCriticalSection更好用的執行緒同步控制方法

今天在一番努力之下
包裝STL提供的list容器變成Ring link-list (早在上一個Project就該這麼做了)
讓程式碼變的很簡短
template真好用~~

arrow
arrow
    全站熱搜

    志 發表在 痞客邦 留言(1) 人氣()