和一個真正iOS開發的區別?

學習iOS的這段時間, 我一直在思考和感受著自己和一個真正做了幾年iOS的dev之間的區別.

同時也在反向思考, 我自己和一個新學Android的人, 又有什麼區別.

也許在技術轉型中, 這些學習的思考和陣痛都是有共性和不可避免的.
在此分享一下感受, 如果有人也有技術轉型, 可以看到有些心路歷程是不可避免的, 不必焦慮.

當然我也在思考一個技術人是不是應該不斷轉型, 還是在一個方向深耕, 這是另一個複雜的話題了, 這裡按下不表.

工具環境類

工具和環境, 這是上手一個新技術要面臨的第一個問題.

比如:

• IDE使用和快捷鍵, 如何debug.
• build不過的種種原因等.
• iOS的真機調試有更多的限制, 需要profile證書等, 不像Android似的插上線就能build.
• tv如何pair.
• pod和swift package這兩種不同的依賴, 都是如何引用本地和更新的.
• 單元測試不能連著真機跑, 要在模擬器上跑等.
• Xcode的一些設置和format工具的使用.

幸運的是, 這些問題基本上上網搜就會得到答案, 如果同事有空就可以幫忙解答.

工具使用和build相關的問題基本上解決幾次就會記住, 不要被這些問題嚇倒.
有時候因為Xcode的升級或者庫的改動, 也會反覆遇到各種新問題, 這時候冷靜沉著, 搜索嘗試就可以了.

語言類

其實任何現代化的語言都是講道理的, 所以並不難學.
Swift和Kotlin很像, 可以類比著學.

確實會有一些不一樣的語法和關鍵字.
我的建議仍然是跟上一條一樣, 先學個基礎, 就可以幹活, 有些特殊的可以現學現查.

如果你工作在一份已有的代碼庫, 那就更幸運了, 裡面充滿了現有的例子.

有一些常用的套路, 比如if let, guard let, enum的取值.

還有delegation和protocol, extension等, 看代碼就會發現這些是比較常用的.

還有可能會令初學者望而生畏的是, 一些UIKit的方法可能會出現一些古怪的符號, @啊#啊什麼的, 那些也是記住固定的寫法就行了, 都是固定場合, 沒有什麼特別可怕的.

但是如果真的遇到OC的代碼, 還是有一點可怕的, 我還沒學.

最後值得註意的是Swift和iOS中的代碼風格和命名規範.
比如我曾經給一個方法命名getXXX()返回一個值, 被建議去掉get, 因為那是java和android的習慣, 他們習慣直接用名詞. (但是除了get以為, fetch或者request等動詞又可以用, 我不理解, 但是我尊重.)

代碼風格可能每個項目都有自己不同的要求. 我還沒有研究過到底哪個才是宇宙最正確.
只能鋌而走險地儘可能遵守, 然後等待著下一個android寫法被髮現.

也不用特別擔心, 只要代碼清晰, 命名有意義, 問題不大.

知識類

知識類的學習似乎是非常的平面, 你不知道什麼知識點, 你看了看文檔/博客/視頻教程, 你知道了, 學習完成, 技能點點上.
知識類的學習建議同樣也是用最快的時間知道最基礎的內容, 然後挑重點瞭解常用重要的, 其他遇到再說.

因為你可能沒有那麼多的時間, 你總是要有個優先順序.

如果沒有人或者什麼任務給你劃重點那麼你可以自己劃, 我比較幸運的是Android和iOS其實平行的兩個平臺, 那麼我常常會想象如果我要給一個Android初學者制定學習計劃我可能會讓ta學什麼, 從而去找iOS中對應的什麼.

拿iOS來說, 它是一個mobile平臺, 它有自己官方的UI類庫, UIKit或者SwiftUI.
那我們就可以: 學UIKit的基礎, 幾個基本控制項, 瞭解tableView, collectionView. 學習網路請求, 學習常用的庫的使用.

這些都可以結合實際項目, 項目中用什麼就優先學什麼.

一個完整知識體系的構建是需要時間的.

其實我甚至有點懷疑”完整的知識體系”本身可能就是一個假命題. 即便在Android平臺工作了這麼些年, 其實很多方面我都不太瞭解, 因為沒有實際涉足過, 所以也談不上完整.
可能對Android來說, 我瞭解的只是一個知識的脈絡, 知道哪一部分大概有些什麼, 知道哪些地方是我的未知領域.

和有經驗的iOS dev相比, 知識的缺乏確實會對工作效率產生一些影響.

• 比如要我可能需要花一些時間瞭解一些基礎知識和已有做法.
• 在遇到問題的時候, 可能會因為一個我不知道的問題而卡住(比如單元測試掛了, 我在研究測試本身, 而實際上是因為選錯了設備), 而對其他人來說可能很簡單.
  對於知識來說最困難的部分是你不知道你不知道什麼.

這些必經的過程都是沒法避免的, 只能見一次學一次了.

通用編程邏輯

幸好還有一些通用的編程邏輯是適用的.
有經驗的開發比純新手開發的優勢就是在這塊.

面向對象的邏輯, SOLID原則, 代碼清晰易讀的規範等, 有很多的能力和經驗都是可以復用的.

而且因為Android和iOS如此相像, 這部分可移植的經驗還比較多.

比如頁面切換, 網路請求和認證, 數據追蹤sdk, 本地存儲.
更廣義層面的各種類MVVM模式, 模塊化拆分等.
大體的套路都是類似的, 只不過是有具體實現方式的區別.

如果是前後端技術棧切換, 可能還會有一個整體思路的切換.

如果你是一個有經驗的人, 那麼換一個技術棧, 一定會有一些你可以移植復用的經驗, 解決問題的思路等, 甚至你自己可能沒有意識到.

心態

確實會有焦慮, 尤其是當自己碰到問題總是需要求助別人的時候.

為了緩解這種焦慮, 通常的做法是(聽上去有點老套, 但是咱們複習一下):

• 如果是通用問題, 利用搜索引擎, 和自己已有的經驗和知識嘗試解決一下. (如果成功了會增添自信心).
• 合理提問題和求助於同事. 在不過多耽誤人家時間的情況下, 並且提供一些有價值的線索. (另外, 找一些看上去和善的同事.)

在內心裡合理化這個犯錯以及提問的行為:

• 每一次問題的提出和解決都是一個學習內化的過程.
• 如果犯同樣的錯誤也不用太自責, 記憶都是在重覆中得到強化的. 並且確實有時候雖然被提醒過但是得自己親自犯了錯才會加深印象.
• 保持空杯心態. 有時候會想到自己的工齡和年齡而焦慮, 但是空杯心態讓我們保持年輕和活力.

雖然這塊聽上去像雞湯一樣, 但是我覺得還是挺重要的.

總結

其實對於一個有學習能力的開發者, 轉換任何一個新的技術棧, 掌握基礎和上手做具體的任務其實並不難. 只要任務拆分得足夠細.

難的是一個全面的知識體系和實際上手的工作經驗, 針對許多實際的困難問題的解決.
因為你並不知道有什麼和用什麼, 以及通常是怎麼做的.
這些確實是需要時間慢慢積累的, 否則程式員的飯碗也太好搶了.

不斷地學習確實是一個程式員(或者說任何職業)不可避免的事情.

以上, 一點不成熟的個人感受.