本篇列出2019年上半年我所在的遊戲公司在程式開發上的一些問題，在一個有效率的團隊中應該將這些問題排除。
儘管目前是2019年了，但我相信仍有很多公司在用舊思維老方法在進行軟體程式的開發，而老舊且錯誤的開發方法造成產出越來越慢，品質越來越低，開發人員抱怨連連，流動率越來越高，然後形成一個向下沉淪的惡性循環。而我目前待的公司有下列我看到的問題。
沒有使用統一的開發環境資料庫
每一個開發者在自己的本機開發時，都必須在本機建立一個資料庫，也就是更新程式碼的時候你的開發環境可能會壞掉，因為另一位開發者可能加了某個schema且在程式中有用到該新增的欄位或資料表，若你更新程式碼但沒同步更新你的資料庫，你用更新的程式碼在本機就無法正確執行。
正確的做法應該是開發團隊應該共同使用一個共用的開發資料庫來避免環境上的差異。
雖然有使用版本控管，但使用方式錯誤。
雖然有使用SVN，卻沒有切任何的branch，所有開發者更新及提交都只使用同一個branch，也就是trunk。而QA則是另一個完全不同的SVN庫，在Dev要合併程式碼到QA的程式碼時，是手工將Dev的程式碼複製貼上到QA的方式。也因此開發者不能隨時提交程式碼，因為要合併程式碼給QA測試時，開發者A的程式碼和開發者B的程式碼會參雜在一起，如果QA只要測A的功能，但上面卻混著B的程式碼，負責將Dev合併到QA的人頭就大了，最終導致必須回退到之前沒有B的程式碼的狀態，然後等A開發者的程式碼測完後，再請B重新提交一次。
沒有使用Maven套件管理工具
程式中依賴的jar函式庫都是手工加的，第三方函式庫也是。
正確的方式是現在2019年了應該用Maven來管理專案依賴的jar。
沒有建置私有的Maven repository
因為沒有使用Maven，也沒有建置公司內部的Maven repository，因此公司內部開發的工具jar等無法有效地管理與共享，結果就是lib中的jar全部上到SVN，然後新人一來checkout專案下來時，還必須手動在Eclipse的Java Build Path的Libraries將資料夾的jar加入到專案的build path。
正確地做法你該為你的公司或開發團隊建立專屬的Maven repository。
程式碼與外部資料檔耦合太高。
程式在啟動時，會去載入外部設定檔的資料，但程式碼的邏輯是直接將所有模組的外部設定檔資料載入，並沒有依照目前有開啟的模組來決定是否載入所需的外部資料。所以一旦另一個開發者新增了某個模組，代表他也必須新增該模組的外部資料檔，一旦少了該外部資料檔，就算你在你本機的專案將沒使用到的模組關閉，執行依舊會導致如NullPointerException的錯誤。
正確地做法是程式必須依有使用到的模組來載入需要的外部資料檔就好。
開發流程錯誤
表面上有切Dev，QA，Prod環境，但事實上沒有，這部分到現在我還未涉略很深仍不知所以然。
沒有使用bug追蹤系統
沒有導入問題追蹤系統如Redmine。雖然建了一個MantisBT但沒人使用，等於沒有用。因此加新功能的說明，發現的問題等都無法追蹤紀錄。目前的方式還是用口耳相傳，導致今天發現了小bug，或小部分可重構項目，或可優化的部分，只有你知道，因為你跟別人說別人也不會memo起來，而你也只能記在自己的筆記簿，變成是你自己的事情。
方法沒有撰寫註解
儘管我是信奉方法名稱即註解的信仰者，但我仍認為每個方法應該有註解適當地描述該方法做什麼事，因為不是每位開發者的英文都很好，所以註解很重要。欠缺註解的結果就是不熟的人很難理解該方法到底幹了什麼，總是得跳進去程式碼堆中去搞清楚是怎麼一回事，你無法把那個方法當作一個黑箱(black box)，如果這個方法邏輯又深又廣那就可怕了。
解決方法是code review和程式碼提交前審核。
沒用的程式碼沒有拔除
沒用到的程式碼，或是註解掉的程式碼應該拔除，而不是放在那擾亂之後的人。
解決方法是code review和程式碼提交前審核。
拼字錯誤
寫程式最重要的就是正確地命名，最基本的就是命名拼字的正確，在2019年有Google和複製貼上，為什麼還會拼字錯誤呢？例如loan寫成laon，或是customer寫成costomer都是不可饒恕的。
解決方法是code review和程式碼提交前審核，裝個sonarlint檢查更是簡單。
沒有留言:
張貼留言