失败的升级维护...

以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.在旧框架还没优化完毕的情况下,就忽然被要求要采用新技术(因为这疑似「能带来很多好处」)。

但不管是哪个,专案都会死。


<<:  那些被忽略但很好用的 Web API / FullScreen

>>:  [Day05]我就静静的看着你

Day 14 CSS <网页布局-浮动布局>

浮动属性float用於创建浮动 使其移动到另一边 直到左或右边缘触及包含块或另一个浮动框的边缘 语法...

第六章

大家在玩CMS之前应该都有先在本地端做测试的习惯吧,那应该会有遇到那种像是使用了XAMPP在本地端架...

【Day13】[资料结构]-二元树Binary Tree

二元树(Binary Tree)是最广泛被使用的树状资料结构,简单来说即为每个节点最多只能有两个子节...

【在 iOS 开发路上的大小事-Day11】透过 CocoaPods 来管理第三方套件

前情提要 一般在开发的时候,有些功能可能自己写不出来,但是网路上已经有别人写好的,那我们只需要将其引...

DAY21 MongoDB Profiler 如何监控效能差的操作

DAY21 MongoDB Profiler 如何监控效能差的操作 有处理过资料库效能问题的大概都知...