和一个真正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模式, 模块化拆分等.
大体的套路都是类似的, 只不过是有具体实现方式的区别.
如果是前后端技术栈切换, 可能还会有一个整体思路的切换.
如果你是一个有经验的人, 那么换一个技术栈, 一定会有一些你可以移植复用的经验, 解决问题的思路等, 甚至你自己可能没有意识到.
心态
确实会有焦虑, 尤其是当自己碰到问题总是需要求助别人的时候.
为了缓解这种焦虑, 通常的做法是(听上去有点老套, 但是咱们复习一下):
- 如果是通用问题, 利用搜索引擎, 和自己已有的经验和知识尝试解决一下. (如果成功了会增添自信心).
- 合理提问题和求助于同事. 在不过多耽误人家时间的情况下, 并且提供一些有价值的线索. (另外, 找一些看上去和善的同事.)
在内心里合理化这个犯错以及提问的行为:
- 每一次问题的提出和解决都是一个学习内化的过程.
- 如果犯同样的错误也不用太自责, 记忆都是在重复中得到强化的. 并且确实有时候虽然被提醒过但是得自己亲自犯了错才会加深印象.
- 保持空杯心态. 有时候会想到自己的工龄和年龄而焦虑, 但是空杯心态让我们保持年轻和活力.
虽然这块听上去像鸡汤一样, 但是我觉得还是挺重要的.
总结
其实对于一个有学习能力的开发者, 转换任何一个新的技术栈, 掌握基础和上手做具体的任务其实并不难. 只要任务拆分得足够细.
难的是一个全面的知识体系和实际上手的工作经验, 针对许多实际的困难问题的解决.
因为你并不知道有什么和用什么, 以及通常是怎么做的.
这些确实是需要时间慢慢积累的, 否则程序员的饭碗也太好抢了.
不断地学习确实是一个程序员(或者说任何职业)不可避免的事情.
以上, 一点不成熟的个人感受.
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
