Software Quality

Software Quality

目前的主管一直想推動提升軟體品質相關的東西。

所以我們有Daily build了。

所以我們有Coding Style的研究了(甚至說不上推動)。

我耳朵旁邊還聽到Code Review,Unit Test。

因為我以前比較沒有了解或去實行這些程式的議題,所以其實還蠻陌生的。或是說我的腦海裡面有著不一樣的聲音。

好像問題不是在這裡?有種重要的環節漏掉了一章節的感覺。

我對我自己的期許是走向SA,軟體架構師。但是目前碰到一些問題,

沒有規格,或者是說其實我這個位子就該從需求變成規格,但是目前的公司也沒有人來教我要怎麼做,或是說這間公司根本沒有一個所謂的軟體需求-軟體規格-軟體實作的標準作業流程。

需求不明,需求改變太快。我們還是有所謂的規格書,但是那是遊戲規格書,企劃規格書。雖然那是我們唯一的文件,我們只好湊合著用。但問題在於,需求常常是會改變的,我們的企劃人員常常因為長官,或是來賓的一句話,就改變規格。就遊戲的本質來講是好的,可是對軟體開發卻是大大不好。需求變動太快,也就代表如果要寫測試的程式,就也必須跟著變動。這就帶入下一個議題。

作單元測試是一個很理想的工作,如果有了單元測試,那麼當我程式修改的時候,就知道改完了是否符合需求。改之前與之後應該要功能相同,這就是單元測試的好處。因此我不只要寫有作用的程式,我還要寫來測試我有作用程式的測試程式。(希望最後不用再寫用來測試我用來測試作用程式的程式,這種鬼打牆的狀態)所以我要做的工作就變成兩倍了。這還是在於我的程式碼會被重做的前提之下所帶來的好處。這個議題就跟寫文件一樣,我們公司並不寫文件,或是不看重寫文件(除非我們認為那種看展報告叫文件),甚至連註解都不寫。第一,不是每個程式設計人員都能寫文件,或是都知道怎麼寫文件,有些人就是有作文障礙,這只能怪這個教育體系。第二,寫文件的時間等於是加倍工時,同樣的要做同一件工作就變成花兩倍時間了。因此花兩倍到四倍時間只完成同樣的工作這簡直是自尋死路的最佳途徑,最後我們再來提這個問題。然後帶入下一個議題。

我們的部門之間是有隔閡的,這並非底層程式人員造成,而是專案本身就是同時進行,專案的平台差別也很大,所以程式碼幾乎不能共用。或者是另一種情形,當程式碼要共用的時候,他的需求等級就會變得比較高,我不能僅僅完成功能就好,我還要讓這份程式被別人所用的時候也運作正常,這相對來講增加了我寫程式的難度,換句話說增加了工作量。所以推行共用的程式碼是就底層的程式人員的角度而言是在找麻煩。

再來,是不是每個模組都要做單元測試,我想這可以談。但是我想沒人能回答我們遊戲專案適不適合作單元測試,我想這點可以跟其他部門研究一下。我相信單元測試的理想是不錯的,但是我們是否經得起這樣的虛耗。如果我們的下場是更長的開發期,換來一個比較穩定的遊戲專案,是否值得?

對我來講,比起做Unit Test,Code Review,更重要的是重視文件(至少註解),重視架構設計,找出評估程式的品質的方式並且化為考績(否則工程師或專案負責人只會在意時間是否來得及),重視程式碼的重覆使用,認真看待每個函式的架構設計,也就是不要重新造輪子。看待程式碼的品質要先能夠勝過時程的壓力。重視優秀工程師的薪水,而不是只要找熱血青年。

最後做個結論。

如果為了要寫文件,單元測試,code review,時程變成兩倍,怎麼辦?

如果沒做單元測試,明天展示,怎麼辦?

誰來做code review,以什麼標準,不過的時候怎麼辦?

如果資深的同仁的程式碼都沒有過標準,要修正嗎?

Code review沒過的時候是否就讓程式不能上傳?或是上傳慢慢修?這樣卡一個人在原處我們能夠接受嗎?時程很趕我們能夠一個人不做事嗎?

新人如何訓練,舊人如何訓練?怎麼樣建立code review的標準?不過的時候怎麼辦?

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s