程式碼共有(collective code ownership)這個概念指的是每個人都有責任修正瑕疵,而且團隊中的任何人也都可以修改應用程式的任何部分。這種做法不僅有助於提升軟體品質,也能鼓勵團隊成員主動發現問題、解決問題(而不是主管有交代才做)。
然而,在委外開發的案子,組織卻可能反其道而行,明令禁止團隊成員修改程式碼,理由是方便釐清責任歸屬。也就是說,如果將來軟體品質出了甚麼大問題,或功能不符規格,便可完全歸咎於外包廠商(乙方),讓他們沒有藉口,說委託的那一方(甲方)也有修改程式,才造成那些問題。
但是,光以這個理由就禁止自己人修改程式碼,這樣的決策適當嗎?如果甲方的團隊成員能夠對軟體品質做出重大的貢獻,為什麼不考慮一些折衷方案呢?例如開放修改特定的子系統或模組,或者定期進行 code review,這樣至少還多幾雙眼睛可以幫忙看程式碼的品質,團隊成員也能及早熟悉程式的架構與撰寫模型。在開發過程中,如果沒有加入甲方的意見,而只是完全交由乙方進行設計,恐怕日後發現程式底層架構有問題時,要改也來不及了。
我碰過的真實案例:甲方的主管既明令禁止團隊成員修改程式碼,卻又一天到晚擔心一旦結案,現有的團隊成員無法接下這麼大的專案的維護工作--豈不自相矛盾?一方面不讓自己的團隊成員盡早接觸程式碼,一方面又希望哪天專案驗收、保固期結束後,自己的團隊能馬上接手......這怎麼可能呢?
如果軟體專案的任何重大決策,主要考量都是將來出問題時要能夠追究責任,而且是追究別人的責任,那麼對於自己的團隊成員,自然也會不允許他們犯錯,以免將來在談判桌上攻防之際被對方找到弱點。這種管理方式,對缺乏創意與軟體開發經驗的主管來說,的確是最容易的選擇。在凡事究責的文化裡,一旦有人犯錯,就要求解釋前因後果、寫一堆報告,宛如變相的懲罰。為了避免懲罰,開發人員做起事來會變得綁手綁腳,就算有好的 idea,也不敢放手嘗試。然而,在軟體開發的世界裡,這種從嘗試錯誤中學習與累積經驗的過程,幾乎是無可避免的,也是必須的。
欲降低嘗試錯誤所造成的衝擊,其實可以先在一個隔離的、可任意進行測試的環境,讓那些構想、實驗完成測試之後,再移入正式產品的程式碼。呃....再講下去就要扯到測試,離題太遠了。總之,程式碼共有的概念是信任團隊成員,讓他們都有程式碼的修改權,而且不怕他們改壞了。當然,前提是得要有版本控制和足夠的測試才行囉。
然而,在委外開發的案子,組織卻可能反其道而行,明令禁止團隊成員修改程式碼,理由是方便釐清責任歸屬。也就是說,如果將來軟體品質出了甚麼大問題,或功能不符規格,便可完全歸咎於外包廠商(乙方),讓他們沒有藉口,說委託的那一方(甲方)也有修改程式,才造成那些問題。
但是,光以這個理由就禁止自己人修改程式碼,這樣的決策適當嗎?如果甲方的團隊成員能夠對軟體品質做出重大的貢獻,為什麼不考慮一些折衷方案呢?例如開放修改特定的子系統或模組,或者定期進行 code review,這樣至少還多幾雙眼睛可以幫忙看程式碼的品質,團隊成員也能及早熟悉程式的架構與撰寫模型。在開發過程中,如果沒有加入甲方的意見,而只是完全交由乙方進行設計,恐怕日後發現程式底層架構有問題時,要改也來不及了。
我碰過的真實案例:甲方的主管既明令禁止團隊成員修改程式碼,卻又一天到晚擔心一旦結案,現有的團隊成員無法接下這麼大的專案的維護工作--豈不自相矛盾?一方面不讓自己的團隊成員盡早接觸程式碼,一方面又希望哪天專案驗收、保固期結束後,自己的團隊能馬上接手......這怎麼可能呢?
如果軟體專案的任何重大決策,主要考量都是將來出問題時要能夠追究責任,而且是追究別人的責任,那麼對於自己的團隊成員,自然也會不允許他們犯錯,以免將來在談判桌上攻防之際被對方找到弱點。這種管理方式,對缺乏創意與軟體開發經驗的主管來說,的確是最容易的選擇。在凡事究責的文化裡,一旦有人犯錯,就要求解釋前因後果、寫一堆報告,宛如變相的懲罰。為了避免懲罰,開發人員做起事來會變得綁手綁腳,就算有好的 idea,也不敢放手嘗試。然而,在軟體開發的世界裡,這種從嘗試錯誤中學習與累積經驗的過程,幾乎是無可避免的,也是必須的。
欲降低嘗試錯誤所造成的衝擊,其實可以先在一個隔離的、可任意進行測試的環境,讓那些構想、實驗完成測試之後,再移入正式產品的程式碼。呃....再講下去就要扯到測試,離題太遠了。總之,程式碼共有的概念是信任團隊成員,讓他們都有程式碼的修改權,而且不怕他們改壞了。當然,前提是得要有版本控制和足夠的測試才行囉。
沒有留言: