對大多數的程式人來說，撰寫程式碼或許是令人開心的一件事情，但我相信，有更多人視閱讀他人所寫成的程式碼為畏途。許多人寧可自己重新寫過一遍程式碼，也不願意接收別人的程式碼，進而修正錯誤、維護它們、甚至加強功能。
這其中的關鍵究竟在何處呢？若是一語道破，其實也很簡單，程式碼是別人寫的，只有原作者才真的了解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。這是來自於人類內心深處對於陌生事物的原始恐懼。
讀懂別人寫的程式碼，讓你收穫滿滿
不過，基於許多現實的原因，程式人時常受迫要去接收別人的程式碼。例如，同事離職了，必須接手他遺留下來的工作；也有可能你是剛進部門的菜鳥，而同事經驗值夠了、升級了，風水輪流轉，一代菜鳥換菜鳥。甚至，你的公司所承接的專案，必須接手或是整合客戶前一個廠商所遺留下來的系統，你們手上只有那套系統的原始碼（運氣好時，還有數量不等的文件）。
諸如此類的故事，其實時常在程式人身邊或身上持續上演著。許多程式人都將接手他人的程式碼，當做一件悲慘的事情。每個人都不想接手別人所撰寫的程式碼，因為不想花時間去探索，寧可將生產力花在產生新的程式碼，而不是耗費在了解這些程式碼上。
很遺憾的是，上述的情況對程式人來說很難避免。我們總是必須碰觸到其他人所寫成的程式碼，甚至必須了解它、加以修改。對於這項需求，在現今開放原始碼的風氣如此盛行的今日，正如之前的「程式設計2.0」文中所提到的，你可以透過開放原始碼學習到新的技術、學習到高手的架構設計，大幅提高學習的效率及效果。你甚至可以直接自開放原始碼專案中抽取、提煉出自己所需的程式碼，站在巨人的肩膀上，直接由彼端獲得所需的生產力。從這個觀點來看，讀懂別人所寫的程式碼，就不再只是從負面觀點的「被迫接收」，而是極具正面價值的「汲取養份」。
這其中的關鍵究竟在何處呢？若是一語道破，其實也很簡單，程式碼是別人寫的，只有原作者才真的了解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。這是來自於人類內心深處對於陌生事物的原始恐懼。
讀懂別人寫的程式碼，讓你收穫滿滿
不過，基於許多現實的原因，程式人時常受迫要去接收別人的程式碼。例如，同事離職了，必須接手他遺留下來的工作；也有可能你是剛進部門的菜鳥，而同事經驗值夠了、升級了，風水輪流轉，一代菜鳥換菜鳥。甚至，你的公司所承接的專案，必須接手或是整合客戶前一個廠商所遺留下來的系統，你們手上只有那套系統的原始碼（運氣好時，還有數量不等的文件）。
諸如此類的故事，其實時常在程式人身邊或身上持續上演著。許多程式人都將接手他人的程式碼，當做一件悲慘的事情。每個人都不想接手別人所撰寫的程式碼，因為不想花時間去探索，寧可將生產力花在產生新的程式碼，而不是耗費在了解這些程式碼上。
很遺憾的是，上述的情況對程式人來說很難避免。我們總是必須碰觸到其他人所寫成的程式碼，甚至必須了解它、加以修改。對於這項需求，在現今開放原始碼的風氣如此盛行的今日，正如之前的「程式設計2.0」文中所提到的，你可以透過開放原始碼學習到新的技術、學習到高手的架構設計，大幅提高學習的效率及效果。你甚至可以直接自開放原始碼專案中抽取、提煉出自己所需的程式碼，站在巨人的肩膀上，直接由彼端獲得所需的生產力。從這個觀點來看，讀懂別人所寫的程式碼，就不再只是從負面觀點的「被迫接收」，而是極具正面價值的「汲取養份」。
進公司以來，到目前為止也接過不少別人寫的程式碼
的確很多時候一如文中所說『寧可自己重新寫過一遍程式碼』
因為別人寫的程式風格可能跟自己的差很多...
最重要的可能是埋藏許多不知名的陷阱、地雷
三不五時賞給你一個access violation
今天下班之前，就跟阿明發現一個陳年的bug
對已經delete的物件呼叫其release method執行dll提供的釋放資源的方法
>"< 被不是自己埋的炸彈炸個正著
雖是如此，接別人寫的程式碼也可以學到不少東西
程式碼的佈局、命名風格、... 時常發現許多嘆為觀止的地方
比VCL提供的TThread更輕巧好用的執行緒物件
比TCriticalSection更好用的執行緒同步控制方法
今天在一番努力之下
包裝STL提供的list容器變成Ring link-list (早在上一個Project就該這麼做了)
讓程式碼變的很簡短
template真好用~~
全站熱搜
留言列表
