其實今天是想延續昨天繼續討論「每個專案的程式碼都該這樣開始」，為什麼會變成這個標題？

因為我寫的每篇其實都是怨念文，而我喜歡這首歌，又發現它也很切題。

思考「專案為什麼死掉」是一件「可以用各種不同方式描述、但最終會發現其實都是在描述同一件事」的事情。（好饒舌啊！）

為什麼會有專案？就是集合眾人之力、用管理的方式集合眾人的專長，一起合力（但不用合心）完成一件本來眾人個別單獨時絕對做不到的事情。
最後這個「眾人個別單獨時絕對做不到的事情」不一定要是「專案最初成立時所訂立的計畫」，可能是計劃中途修正了，可能是計劃中途的額外計畫，，也可能是必須要從計劃失敗的殘骸中挖掘出來的東西。
如果注意力完全只注意在原本的計畫任務上，因此錯失了其他的可能性，就算專案任務成功也可能只是「結案、收錢」，如果專案任務失敗真的就只是失敗，除此以外毫無意義。

就連「每個專案的程式碼都該這樣開始」都是從失敗的專案中累積的經驗，「如果一開始就知道這樣做，或許專案在施作進度掌握上就不會失敗了。」

所以...
順利的、華麗的完成專案任務、然後從這個成功中發覺整個專案的最大價值，誰不想呢？
但...「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的生命週期監聽機制？
不管是哪個，複雜度都會瞬間超越原本的規劃，但又可以讓整個專案變簡單。