和一個真正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模式, 模塊化拆分等.
大體的套路都是類似的, 只不過是有具體實作方式的區別.
如果是前后端技術堆疊切換, 可能還會有一個整體思路的切換.
如果你是一個有經驗的人, 那么換一個技術堆疊, 一定會有一些你可以移植復用的經驗, 解決問題的思路等, 甚至你自己可能沒有意識到.
心態
確實會有焦慮, 尤其是當自己碰到問題總是需要求助別人的時候.
為了緩解這種焦慮, 通常的做法是(聽上去有點老套, 但是咱們復習一下):
- 如果是通用問題, 利用搜索引擎, 和自己已有的經驗和知識嘗試解決一下. (如果成功了會增添自信心).
- 合理提問題和求助于同事. 在不過多耽誤人家時間的情況下, 并且提供一些有價值的線索. (另外, 找一些看上去和善的同事.)
在內心里合理化這個犯錯以及提問的行為:
- 每一次問題的提出和解決都是一個學習內化的程序.
- 如果犯同樣的錯誤也不用太自責, 記憶都是在重復中得到強化的. 并且確實有時候雖然被提醒過但是得自己親自犯了錯才會加深印象.
- 保持空杯心態. 有時候會想到自己的工齡和年齡而焦慮, 但是空杯心態讓我們保持年輕和活力.
雖然這塊聽上去像雞湯一樣, 但是我覺得還是挺重要的.
總結
其實對于一個有學習能力的開發者, 轉換任何一個新的技術堆疊, 掌味訓礎和上手做具體的任務其實并不難. 只要任務拆分得足夠細.
難的是一個全面的知識體系和實際上手的作業經驗, 針對許多實際的困難問題的解決.
因為你并不知道有什么和用什么, 以及通常是怎么做的.
這些確實是需要時間慢慢積累的, 否則程式員的飯碗也太好搶了.
不斷地學習確實是一個程式員(或者說任何職業)不可避免的事情.
以上, 一點不成熟的個人感受.
作者: 圣騎士Wind出處: 博客園: 圣騎士Wind
Github: https://github.com/mengdd
微信公眾號: 圣騎士Wind
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/539198.html
標籤：iOS
上一篇：優先級反轉那些事兒