和一個真正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模式, 模塊化拆分等.
大體的套路都是類似的, 只不過是有具體實現方式的區別.
如果是前後端技術棧切換, 可能還會有一個整體思路的切換.
如果你是一個有經驗的人, 那麼換一個技術棧, 一定會有一些你可以移植複用的經驗, 解決問題的思路等, 甚至你自己可能沒有意識到.
心態
確實會有焦慮, 尤其是當自己碰到問題總是需要求助別人的時候.
爲了緩解這種焦慮, 通常的做法是(聽上去有點老套, 但是咱們複習一下):
- 如果是通用問題, 利用搜索引擎, 和自己已有的經驗和知識嘗試解決一下. (如果成功了會增添自信心).
- 合理提問題和求助於同事. 在不過多耽誤人家時間的情況下, 並且提供一些有價值的線索. (另外, 找一些看上去和善的同事.)
在內心裏合理化這個犯錯以及提問的行爲:
- 每一次問題的提出和解決都是一個學習內化的過程.
- 如果犯同樣的錯誤也不用太自責, 記憶都是在重複中得到強化的. 並且確實有時候雖然被提醒過但是得自己親自犯了錯纔會加深印象.
- 保持空杯心態. 有時候會想到自己的工齡和年齡而焦慮, 但是空杯心態讓我們保持年輕和活力.
雖然這塊聽上去像雞湯一樣, 但是我覺得還是挺重要的.
總結
其實對於一個有學習能力的開發者, 轉換任何一個新的技術棧, 掌握基礎和上手做具體的任務其實並不難. 只要任務拆分得足夠細.
難的是一個全面的知識體系和實際上手的工作經驗, 針對許多實際的困難問題的解決.
因爲你並不知道有什麼和用什麼, 以及通常是怎麼做的.
這些確實是需要時間慢慢積累的, 否則程序員的飯碗也太好搶了.
不斷地學習確實是一個程序員(或者說任何職業)不可避免的事情.
以上, 一點不成熟的個人感受.