Groovy 是一個彈性很高的語言，並且同樣一個動作可以有很多種寫法。不過以開發團隊管理者的角度來看，對於這樣的語言導入團隊其實是一種很大的挑戰。在開發團隊運作過程中，產出的程式碼並不是只有撰寫的人才會接觸到，為了確保程式碼的品質會進行 Code Review，或是為了工作的負載會有不同的開發人員接手進行程式碼的除錯或維護。
所以為了維持開發流程的順暢，程式碼的一致性就相對地重要，而維持一致性常見的手法就是訂定團隊的 Coding Convention。然而，像這樣具有很大彈性的語言，在訂定 Convention 時不容易拿捏訂定的準繩。如果訂得太具體、詳細了，有些成員覺得瑣碎記不住或是覺得麻煩而配合度不高；但訂得太抽象又會在實作上有很多的例外而流於形式，或是在 Code Review 時因解讀不同產生爭議。
另外還有一個對管理者來說很頭大的問題，就是要如何讓 Convention 的內容成形。要導入團隊沒有經驗的語言，在訂定 Convention 時大多還是求助於外援。如果是具有歷史的語言，在資料的蒐集上可能相對容易一些。但是如果是年輕的語言，可供參考的資料並不多，有可能會需要投入時間及人力來達成。但是要形成一份可發揮功效的 Convention，通常要對語言的規格有一定程度的了解，並且對於應用在實際開發工作上可能遭遇的問題做出考量，或是針對團隊的習性進行微調。這是會產生可觀的人力時間成本，是否要投入會是一個很煎熬的抉擇。
在「隱藏的機會成本不管有多巨大都會被犧牲」的現實面之下，大多只能無奈的選擇可以展現績效的方案。「且戰且走」會是常用的選項之一，也就是藉由專案經驗的累積來逐步形成 Convention 的內容。其後遺症可想而知，導入初期的專案裡程式碼的寫法百家爭鳴、每一個 Convention 階段的專案程式碼撰寫風格都不儘相同。回頭去改過去專案的程式碼不符合帳面上的成本效益，放著不管又要承受著成員接手意願不高，或是系統修改時出錯可能性較高的風險。
另外一個衍生的問題是，「且戰且走」初期一般就是訂定幾個原則性的抽象大綱，期望開發人員能夠依循大綱的精神來自我要求，以提高程式產出的品質。殘酷的現實是總會遇到有一部份自我中心的開發人員，其抱持的心態覺得程式碼打得愈少效率愈好，並引以為豪。不僅是在寫法上極盡所能地精簡，同時在命名上也是能縮寫就縮寫，有慣例用慣例、沒慣例就自己訂。當成員間程式碼撰寫方式看法相左時，這樣的成員能溝通的還算好，花點時間就是了。最糟糕的情況是遇到自視甚高、缺乏同理心的，不論如何溝通都依然堅持己見，並且還在團隊中造成「破窗效應」。
就像前面提到的，程式碼在一個團隊裡會需要看的又不是只有 Compiler。程式碼本身也是一種文件，易讀性是一個很重要的品質指標。從變數、函式的命名、程式碼的排版、指令的排列順序、空白行的使用到程式區塊的分配，都應該要隱含著「導引閱讀程式碼人員理解程式邏輯」的效果。
從效率的角度來看，節省掉的打字時間是可以省個幾分鐘。不過現在的 IDE 都夠成熟，自動完成大多都是基本的功能，靠 IDE 的功能就算是命了一個很長名字的變數，真正需要打完全名的機會根本微乎其微，能省掉的時間其實很有限。同時，精簡的程式碼在偵錯的操作上很容易出現一個問題是，太多指令同時發生在同一行程式碼，單步執行時會不容易有效隔離並觀察到出問題指令所造成的影響。但是寫出一堆不易理解的程式，除了其他人閱讀時要額外多花掉的時間，再加上看錯所產生一連串後續修復的時間成本、使用者因程式運作錯誤所付出的成本，絕對超過省下的那幾分鐘。
有經驗的老手應該都清楚，繕打程式碼的時間其實佔開發一套系統的比例不算高，大多數的時間還是花在規劃和構思系統的流程與架構。執著在打字的效率上其實是不夠理性的行為表現，甚至「爭論程式碼寫法」所產生的時間成本都高於「照規定要求完成工作」的時間成本。
有人可能會認為這是個小事、問題不大，加個註解幫助閱讀就好了。我想這是一個沒有認真寫過註解的人才會有的想法，要寫出一段能允當表達程式設計意圖的文字，其實是很花時間的一件事。隨手寫下的簡短註解，往往有一個很常見的經驗是「在過一段時日再回頭去看時，文字比程式還難了解」；或是註解只是在重複程式執行的動作，看程式和看註解的效果一樣。如果是這樣的註解，與其浪費時間在打這些字，還不如回頭去好好地把程式碼變得更易讀。
當然，有很多人會覺得以目前的軟體從業環境，很多的程式碼都是在急就章的時程下產出或是用過就丟。與其花心思在這種枝微末節上，還不如早打完早收工去享受人生。這是每一個人對於工作的態度，沒有所謂對錯的問題，端看你想要讓你的工作成果是精品還是平價品。想要打造出精品，差別就在所謂的魔鬼細節裡，會需要付出很大的成本嗎？我的經驗是「不需要」，只要養成習慣，自然而然的就會展現在工作的成果裡！
0 意見:
張貼留言