當學生時期一直有寫這種反省文的習慣. 出來工作我想也應該持續這個習慣. 當學生和當上班族當然有很多不同. 其中之一就是寫 code 的習慣, 像是 revision control, naming, testing 和 code review. (剛好跟最近大家一直轉載的 投票結果出爐！對軟體工程師來說最困難的是… 很類似.)
版本控制
我們公司基本上是使用集中式的原始碼管理系統. 所以在寫程式上有相當程度不方便. 如果是簡單的小修改也就算了, 如果是要開發新功能, 或者要動到好幾個檔案, 而且好幾百行的程式時, 我個人覺得還蠻不方便的. 畢竟不能夠把半成品直接 check in 到源碼庫. 解決這個問題的方法就看個人了. 有人是直接備份檔案夾, 我是偏好使用 git 做個人的備份.
不過還是有一些習慣有待培養, 像是把 git 當作是工作日誌. 這點我覺得還蠻重要的. 我常常忘記做這件事. 尤其是想測資料或者修改小東西時, 常常會先改先測再說, 結果常常忘記自己跑的某些資料是要做什麼用的, 或者某些修改有什麼用.
測試應該也可以套用這個概念利用 git. 其實 QA team 就是這樣做, 要跟他們學習一下. 不過有點困擾的是, 我們公司不允許 check in 測試程式進去源碼庫, 所以自己的一些測試碼沒辦法保留或共享, 這點我還蠻不能理解的. 難道某個工程師離職後, 他負責的 module 就要重頭開始嗎? 不過說歸說, 我的 test code 寫的量不是很多.
其實我不是 TDD 的信徒. (其實我也不太喜歡 refactoring) 不過我真的覺得需要 TDD 或者說弱化的 TDD. 因為我算是不太細心的人. 如果沒有 test case 輔助, 我覺得會很危險.
Naming & Commenting
老實說這真的是很煩的事, 無怪乎榮登第一名寶座. 當有人覺得這不重要時, 是一件很糟糕的事, 但是當大家都覺得很重要時, 就變得很煩人.
理想上, Code 本身就是最好的文件, 但是現實是, 這幾乎是不可能. 除非真的是功能或架構很簡單的程式. 即使是真的很努力要把程式寫得好懂的人, 通常也會面臨到每個人的思考方式不同的問題. 對 A 好懂的東西, 不見得對 B 好懂. 對菜鳥好懂, 可能對老鳥來說就太繁瑣, 反而妨礙閱讀.
我個人是屬於喜歡寫注解的人. (如果給我足夠的時間的話) 尤其是用到演算法或數學式時, 我習慣在註解中解釋或加上citation. 因為從源碼去回推數學式或演算法真的非常痛苦. 尤其是那種發展很多年的程式, 通常都會有很多針對 special cases 的最佳化, 如果其中還有用到 magic number, 真的不知道要怎麼 debug.
如果 code review 時, 大家都在討論 comments 和 naming, 有時候真的很煩人. 如果說很明確有違反 coding style, 或者錯誤命名時, 這比較沒有爭議; 但有時候會花很多時間在 "怎麼命名比較好", "那個名字比較好" 之類的議題, 難免覺得蠻浪費時間的. 舉個例來說, 對於會傳回布林值的函式, 我個人習慣用動詞開頭, 所以看起來會像是 IsPrimeNumber() 或者 IsDuplicated() 之類的.
if (IsPrimeNumber(x))
{
....
}
if (IsDuplicated(y,z))
{
....
}if (PrimeNumber(x))
{
....
}
if (Duplicated(y,z))
{
....
}
沒有留言:
張貼留言