You can't always get what you want

其实今天是想延续昨天继续讨论「每个专案的程序码都该这样开始」，为什麽会变成这个标题？

因为我写的每篇其实都是怨念文，而我喜欢这首歌，又发现它也很切题。

思考「专案为什麽死掉」是一件「可以用各种不同方式描述、但最终会发现其实都是在描述同一件事」的事情。（好饶舌啊！）

为什麽会有专案？就是集合众人之力、用管理的方式集合众人的专长，一起合力（但不用合心）完成一件本来众人个别单独时绝对做不到的事情。
最後这个「众人个别单独时绝对做不到的事情」不一定要是「专案最初成立时所订立的计画」，可能是计划中途修正了，可能是计划中途的额外计画，，也可能是必须要从计划失败的残骸中挖掘出来的东西。
如果注意力完全只注意在原本的计画任务上，因此错失了其他的可能性，就算专案任务成功也可能只是「结案、收钱」，如果专案任务失败真的就只是失败，除此以外毫无意义。

就连「每个专案的程序码都该这样开始」都是从失败的专案中累积的经验，「如果一开始就知道这样做，或许专案在施作进度掌握上就不会失败了。」

所以...
顺利的、华丽的完成专案任务、然後从这个成功中发觉整个专案的最大价值，谁不想呢？
但...「You can't always get what you want」...

就这样结束这篇文？好像怪怪的...对了，继续把「每个专案的程序码都该这样开始」讲完。

3.专案无大小，没有简单的专案，但也预设所有的专案都应该很简单。
像昨天提到的「实作一套更新画面的机制」，那其实是个陷阱题。
这样的机制是不可能直接用昨天描述的方式运作的，因为它会造成Leaking，——被UiJob指定为工作内容的View有可能并不会因为它所属的Activity/Fragment被回收了就跟着被回收。

例如开启了一个连线工作，并且在连线启动时指定了「连线收到回传时要用什麽样的UiJob去完成工作」。但连线可能中途被转为在背景执行，当下启动连线的Activity/Fragment也必须关闭、所有的UiJob都失去了执行的必要与价值了！
但UiJob可能会持续待在「等待执行的伫列」中，即使将伫列清除、即使将UiJob回收了，里面的View却有可能依旧待在记忆体中.......UiJob原本要处理的就有可能会变成一个回收机制无法处理的垃圾资料。

要怎麽修正、或怎麽补完？
简单说，这个UiJob机制需要搭配Activity/Fragment也有随着自己的生命周期去清除UiJob伫列的功用。

怎麽做？
直接去扩充Activity产生一个具有这个功能的父类别？
注册一个Activity的生命周期监听机制？
不管是哪个，复杂度都会瞬间超越原本的规划，但又可以让整个专案变简单。