成为中级iOS开发人员的提示

中级是标签。 对不同的人意味着不同的事情。 这篇文章非常主观,但是这些对我进步到我认为是中级iOS开发人员有帮助。 它还假设您已经对UIKit,协议和泛型之类的基本知识已经有了足够的了解,因此我不介绍这些内容。

学习高级iOS技术

从本质上讲,这是非常主观的,但是我建议您理解或至少意识到的事情是:

  • 何时(以及如何)使用线程
  • CI和自动化工具(Fastlane,Jenkins,Travis或类似工具)
  • 测试—单元测试,集成测试,UI测试,快照测试
  • 如果可以访问,则App Store可以连接。 分发到TestFlight和App Store,用户和角色,证书和密钥都是好东西
  • 帮助您遵循SOLID原则的抽象,例如Coordinator模式,这些概念将迫使您更好地构建代码。 通过实验找到最适合您的方法很重要
  • 可访问性是大多数人会忽略的东西,因此这是与众不同的好方法。 当然,这对于您的用户也是正确的做法。 动态类型是您最容易使用的一种,也许是最广泛使用的一种。 配音和色盲设计也是不错的起点。
  • 何时使用框架。 框架是一种非常强大的工具,可以为您节省时间和金钱,但是知道何时(并且更重要的是何时不使用)是一种技能
  • 我敢肯定还有更多,但这些都是我想到的

这里有很多东西,所以更多的是要了解外面的事物并知道何时使用它们,而不是详细地详细了解每个事物。 这样,当有人要求您做某事时,您将知道最佳的做事方式,而无需立即知道如何做。

您将能够回答“是的,这是可能的”或“我知道这个伟大的工具”,而不是“我不确定,让我研究一下”。 最好对可以实现的目标有一个大概的了解。 将来也可能会节省您的时间。 我曾经一起破解过自己的电池记录实用程序,然后发现iOS内置了该实用程序。几乎与我不了解Swiftlint自动更正功能的时间一样糟糕。

当然,在尝试做任何事情之前进行大量研究都是不可行的,但是如果您对许多有用的技术有一个全面的了解,那么您将会知道从什么开始或推荐什么。

习惯于架构模式并知道何时使用它们

习惯一种做事方式然后陷入其中是很常见的。 也许对我们第一个可行的解决方案的联系过于紧密感到不自在或感到骄傲。 MVC没什么错,但是它是最容易被滥用的,因此赢得了良好的声誉,这也许是因为它是我们大多数人开始学习的地方。

我认为在编程中很明显,知道一种以上的做某事的方法是一项有用的技能。 这不仅是了解适合该工作的工具,而且还有助于加深您对该领域的了解,并让您了解为什么以这种方式做事。

如果您想探索建筑的各种首字母缩写,那么一个很好的起点是objc.io的《 App Architecture》一书(但是我希望他们能涵盖VIPER)。

您不必在实践中使用它们。 了解通用模式及其相关的词汇表将使您更轻松地阅读他人的代码,并使选择具有比您更喜欢的架构模式不同的新代码库更为顺畅。

与设计师合作时要自以为是

您的工作是制造最好的产品。 如果您与设计师合作,很容易挑战自己完全按照规范构建应用。 但是该规范可能不适合您所了解的业务需求。 或者它可能具有一些令人愉悦的新颖工作流程,其中标准的iOS应用程序模式就足够了(Snapchat重新设计后劲)。

与设计师一起提出这些问题是您的责任,以便您可以迭代它们并最终为用户构建更好的产品。 始终确保遵循《人机界面指南》,您的设计人员可能对此一无所知。

帮助别人

您可能会骗自己以为,由于您不是该领域的专家,因此您不应该教导其他人,但这不是真的。 您不需要了解某个主题的所有知识,只需要了解比与之交谈的人更多的知识即可。

如果有机会指导其他人,则承担该责任。 您将被迫清楚地解释一些事情,从而学到很多东西,巩固自己已经知道的知识。 但是请确保知道有多少帮助。 如果仅在它们前面键入所有代码并希望他们以后再理解,那将无济于事。 这是为正确答案提供指导的问题,当它们迷路而不会故意模糊时提供正确提示。

您也不必亲自帮助某人。 松弛的通道或StackOverflow是让您教书的好方法。

了解如何与他人合作

对于我来说,这可能是最难的事情,我认为您永远无法真正掌握它。 我很难学的一件事是当需要说些什么时说出来。 我认为很多人都害怕这样做,因为他们担心失业,并希望问题会消失。 如果您恰当而富有建设性地表达自己的感受,那么您将受到感谢而不是受到批评。 员工和雇主的关系是双向的过程,如果没有必要,双向反馈是健康的。

如果您看到不公正的内容,请大声说出来。 这个问题可能会变得更好而不是更糟,您将不胜感激。 请记住,诚实和残酷诚实之间是有区别的。

代码审查始终是一个棘手的话题。 在大多数情况下,人们批判的原因是因为他们试图像您一样制造出优质的产品,所以很容易让人产生深深的评论,而不是理解。

如果您在具有多种编码风格的团队中工作,那么在请求请求中使其与您的要求保持一致的好处不值得因为评论而引起摩擦。 如果您使用可自动在拉取请求中强制执行样式的工具,或者您的团队使用短绒棉,那将是很棒的选择。 人们更喜欢被机器人而不是人类嘲笑。

代码审查应该是关于反馈的。 反馈既包括批评也包括赞赏。 如果您指出自己喜欢的事情或解决问题的好方法,这将提供一个更好的工作环境并在团队之间建立信任。

包起来

希望对您有所帮助。 我想粗略地定义一些令人困惑的地方。 我确定每个人组成中级iOS开发人员的清单都是不同的,但是我试图涵盖那些我希望有最共同点的内容。 让我知道是否还有其他重要领域,或者您是否同意/不同意以上任何内容。

进一步阅读

  • 苹果的人机界面指南
  • iOS辅助功能
  • Fastlane教程
  • John Sundell的测试文章