iT邦幫忙

2021 iThome 鐵人賽

DAY 20
0
Mobile Development

我的怨念齊天高 之「為什麼我的專案死掉了!」系列 第 20

失敗的升級維護...

以Android的環境特性來看,這種事情遲早要碰到...

「核心功能的元件要整個換掉。」

這種事情理論上不難處理,但發生時經常讓專案的工程品質競爭力崩潰。

萬一元件再多個地方被使用,那就要修改多個地方,——很多時候不單單是修改使用的元件而已,還要修改使用過程的邏輯,去調用原本無法取得的參數、環境、跟權限。當需要在很多地方做這麼多事情時,下一次發布更新的品質就令人堪慮。

什麼?貴專案的測試人力充分、計畫充實?恭喜!你們選擇用「硬力拆解」的方式對付這個問題。對那些沒有人力資源的團隊來說,很遺憾的,這種事情基本上無解、只能預防。

曾在「每個專案的程式碼都該這樣開始」講過「實作每個常用介面跟物件」,這就是預防的絕對手段。

假設:未來全面棄用OnClickListener,新元件也不提供「onClick(View view)」這樣的函數作為接口...

要怎麼用「實作每個常用介面跟物件」來預防這種事情發生呢?

回頭把上次的範例挖出來,並且加點料.......

abstract class ProjectClick implements OnClickListener{
   void onClick(View v){
     click(v);
   }
   abstract click(View v);
   
   void callbackView(View v){
     v.setOnClickListener(this);
   }
}

這個「callbackView(View v)」是為了方便解說而設的權宜之計,實務上有可能會造成很多限制而失去它本來追求的功效,所以除了實作以外再改用其他模式可能會更理想。

總之,假設新的元件就稱為「ClickCallback」吧!而它提供的接口是個「clickEvent(ClickEvent e)」,需要藉由「ClickEvent」去取得View,那就可以在不更動所有使用ProjectClick的情況下,讓整個專案的所有Click都適用新機制。

如下:

abstract class ProjectClick implements ClickCallback{
   void clickEvent(ClickEvent e){
     click(e.getView());
   }
   abstract click(View v);
   
   void callbackView(View v){
     v.setOnClickCallback(this);
   }
}

上面這是期望值。

而下面這是糟糕的現實。

使用新元件並不是件很簡單的事情,但事實上「推廣大家使用新元件」「跟大家解釋新元件基本用法」「為了辨明新舊元件優劣而開啟論戰」的人很多,但願意正視「這種升級有多困難」的人很少。

因為「教學」變成一門龐大的生意,而這門生意的主要客群是「尚未入行的新鮮人」,偶爾會有「不用把時間都花在加班熬夜改程式」的專案管理或技術經理。

結果?

1.現有專案慢慢成了技術孤兒,到了網路論壇上漸漸沒人討論它,光是發問都會惹來「為什麼還不用新元件?不要那麼排斥學習新技術啊!」的「攻擊」。
2.在舊框架還沒優化完畢的情況下,就忽然被要求要採用新技術(因為這疑似「能帶來很多好處」)。

但不管是哪個,專案都會死。


上一篇
布林值判斷的一些豆技巧(弄不好也是會造成專案死掉的)
系列文
我的怨念齊天高 之「為什麼我的專案死掉了!」20

尚未有邦友留言

立即登入留言