iT邦幫忙

2021 iThome 鐵人賽

DAY 10
0
Mobile Development

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

Android工程師說:只有「不當Android工程師」才是「好工程師」

開發Android需要經歷些什麼樣的心酸?...不是說iOS開發不會有心酸事,一想到「天線門」、「TouchID出現又消失」.......,嘴角總是會不經意露出「爽快的微笑」。

看到Fushia出現(或每次有發展進度上新聞),總是一堆「疑似C++工程師」在那邊忍住笑意的說「Google要拋棄Android」了,——大家都有自己的辛酸事,大家都會覺得「別人過好爽」(像「Android的市佔率」跟「Java的物件導向好學習、好上手、好開發」),但事實上並不是。

開發Android有多心酸呢?
前面有提到:大型專案經常「最早的雛形成品開發很容易,但真正進入專案階段,就問題連連。」
為什麼?
到底會碰到些什麼情況?

(下面這個情況,雖然在這幾年沒再發生了,但我覺得挺經典的。)

在Android中,「活動」的內容可以自行設定,但如何啟動、如何初始化、如何卸載釋放,就必須要由系統來掌控。(這稱為生命週期。)
在Android4/5時,開發到一半,伴隨著專案規模成長,經常從天外跑出一個現象就是:請系統啟動某個剛完成、準備測試的特定功能,結果這個功能最後雖然啟動了,卻連續的執行了兩次初始化;不單單是連續執行了兩次初始化,事實上,這是兩個不同的「活動」,(同一個物件、不同實體,)但第一個活動初始化完成後就石沈大海了!(不是初始化了嗎?為何不執行回收釋放動作呢?)

所以如果雛形所確立的框架中,會在初始化執行某些功能,則這些本來計劃在初始化中執行的功能會非常不穩定。
例如要進行連線......本來只要執行一次,會變成執行兩次。

這問題不難修正。
問題在於專案管理結構:很多負責開發核心雛形的工程師不太願意承認「他寫好的雛型框架會發生這種事情」,即使承認了,進行的修正也未必適合所有正在進行中的專案,個別專案試用新的解決方案的成本可能會差異很大。

一個問題完之後是另一個問題...「為什麼不能承認、然後進行修正?」

這可能是因為他的工程師素養中並沒有「平行溝通」這種東西。

有個現象是:如果GoogleDev中寫了篇文章,(不管這文章是否權威、是否專業精準,)只要它有提到這個現象發生,這位工程師就有很高的機會承認「對!我寫的核心發生了這個現象。」
反過來說,如果GoogleDev沒有出現過類似的文章,那他面對這個問題的方式大概就會變成「聳聳肩,說:一定是某某工程師的程式碼有問題,請他自己檢查一下、Survey一下癥結就好了。」

這類工程師做事情大概就是簡單三個原則:「凡事都只認官方文件。」「凡事都只認權威的文章。」「盡可能花心思去精通這些管道釋出的文章,而不是認真培養程式建構的技能。」

先不要評論。
最初寫程式,有個DK和簡單的小作家能寫份「.txt」文件就夠了。
雖然DK偶爾會無法執行,但排除方式都挺一拍兩瞪眼的。

後來,開始有了IDE/專案建構工具/版控軟體........
解決問題的方式(可能性)開始極速倍增。
DK版本 x IDE版本 x 專案建構工具版本 x 版控軟體 x 防火牆設定 x …… = 直接尋求別人的意見去解決你碰到的問題時可能會得到的答案數量。這些答案中超過一半都是錯的,剩下的一半答案幾乎都只是讓問題收到的錯誤訊息變得不一樣,(所以一樣是錯的。)

這些問題有個特性:解決方式通常沒有邏輯,無從推論,大概就是某個不可思議的參數、必須要使用某個特定不可思議的值。

如果身為工程師,工作和解決問題的方式不再是以「邏輯」、「結構」、或演算法之類的事情為主,而是要不停的在「別人提供的制式程序」中查找,那請問工程師還能叫工程師嗎?

甚至,習慣在這樣的環境下工作的工程師可靠嗎?

(本來想要在這篇文章中把Google裝來痛罵一頓,這樣才能更契合標題,但時間精力有限,還是明天吧!)


上一篇
愛用iPhone的設計師可以多恐怖?
下一篇
那些註定要沒什麼用的專案開發法
系列文
我的怨念齊天高 之「為什麼我的專案死掉了!」20

尚未有邦友留言

立即登入留言