以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
浮动属性float用於创建浮动 使其移动到另一边 直到左或右边缘触及包含块或另一个浮动框的边缘 语法...
大家在玩CMS之前应该都有先在本地端做测试的习惯吧,那应该会有遇到那种像是使用了XAMPP在本地端架...
二元树(Binary Tree)是最广泛被使用的树状资料结构,简单来说即为每个节点最多只能有两个子节...
前情提要 一般在开发的时候,有些功能可能自己写不出来,但是网路上已经有别人写好的,那我们只需要将其引...
DAY21 MongoDB Profiler 如何监控效能差的操作 有处理过资料库效能问题的大概都知...