我已经担任iOS开发人员超过六年了。 我碰巧在几个不同的公司和团队中工作。 我既从事外包工作，也从事外包工作，甚至有机会参加创业。 现在，经过几年的商业开发以及在大学里进行了几年编程之后，我开始为应用程序开发的定性方法选择一些原则或规则。 起初这是给我朋友的建议。 给他一些建议，我以为我刚开始自己的发展道路时就缺乏这种建议。 我能说些什么，是我最近才意识到的一些时刻，而有些时刻已经在一个新的工作场所。 因此，这个主意提出了一些技巧，我想在五到六年前与自己分享一些技巧。 我敢肯定，再过五年，我今天会对自己说些什么。 但是我们可能会留待将来使用。
您的代码不正确
我要像以前一样对自己说的第一件事是：“您的代码很糟糕！”。 在普通百姓中，“ govnokod”。 在开发车间的外国同事也有“猴子代码”。
不，这不是您的想法。 我不想强调我曾经是一个糟糕的编码器，现在我的代码是完美的。 我想改写此信息，并传达此建议中的三个关键点。
“您的代码过去是而且将是不好的！”第一刻：没有完美的代码，没有人奠定理想的体系结构，也没有这样的代码，不会存在任何错误。 我认为许多人以为自己无法弄清新图书馆或新技术。 或者我们中的某些人在遵循OOP和SOLID的所有原理的情况下尝试完美编写功能时走到了极点。 这反过来导致了很多时间，有时甚至导致了死胡同。 有时，在尝试编写完美的代码时，诞生了带有开发人员知道的甚至可能更多的模式的完整列表的怪兽。
用我的话来说，我想传达的想法是，您首先不应该担心，不要担心代码的质量。 不可能预测所有事情。 而且，最好是放松自己，写得容易些，而且如您所知，要比徒劳地承受痛苦和烦恼更好。 凭经验，决策将由自己决定。 有时有必要“ nagovodnodit”，他们会遇到此狗屎代码将引起的问题，并且一劳永逸地理解，最好不要这样做。
我刚才提到的第二个时刻是几乎不可能预测所有事情。 是的，随着经验的增长，您将了解自己的工作，并且可以预测项目的开发路径。 但是它带有经验。 而且，如果经验还不够，那么您不应尝试使代码通用。 在很多情况下，您想了很久，一开始就仔细考虑然后编写的功能只是简单地丢到了应用程序之外。 此外，在某些情况下，应用程序更改仅是因为在客户看来，它们似乎都不同。 经过长时间的艰苦努力，接口从设计到代码的转换，突然出现了100,500个更改。 这仅仅是开始，因为在第一次重做之后，将会有越来越多的新编辑。 在开发人员没有足够经验的情况下，此过程不仅会花费很多时间，而且也不会带来最令人愉悦的感觉，这些令人不快的想法会把这些令人讨厌的想法抛诸脑后，使您的开发过程从一个有趣的教训变成痛苦的痛苦。 因此，请多加注意，不适合您的理想。 有时你可以说一点。
第三点：这又是纯粹的心理时刻，即来自其他开发人员的批评。 众所周知，所有国内开发商都在考虑其他任何代码-狗屎代码。 即使向他显示了自己的代码（他不认识），他也很可能称他为狗屎。 通常，这种批评伴随着评论家本人的道德满足。 正如经验丰富的开发人员所指出的那样，最经常称呼别人代码的人就是那些一度novnovkovodil超过别人的人。 有人尖叫“ govnokod”的声音越大，他在路上留下的“蛋糕”越多。
此外，任何使自己回想起年轻的处女都必须承认他是成名的新密码。
因此，我建议您使用“您的代码曾经是并且将来会很糟糕”这样的表述，以防止并非总是具有建设性的批评。 我还想指出的是，由于开发不会停滞不前，您的代码将总是很糟糕。 每年代码质量只会提高。 因此，当前的代码最终将变成govnokod。
分而治之
我不想只建议govnokod，因此，我将开始就如何避免该错误代码提供建议。 我想从我为自己保留的原则开始。 不，这不是继承或多态，也不是SOLID的原理之一。 我称这个原则为分而治之。
是的，有分解之类的东西。
分解-将整个部分分解。 同样，分解是一种科学的方法，它利用问题的结构，使您可以用一系列较小的任务代替一个大问题的解决方案，尽管它们相互关联，但更为简单。
正如维基百科所说。 但是，这只是我所阐述的原则含义的一部分。 绝对可以，您需要将项目和任务分成较小的部分。 但是我的意思是在项目中分离逻辑组的概念方法。
我首先提到的这个原则是用户界面和应用程序业务逻辑的分离。 看来我现在是证据的直接负责人。 但是！ 在实践中，这些界限常常模糊不清，事实证明ViewController或Activity包含业务逻辑。
我认为“登录”屏幕的示例将简单易懂。 开发人员在这里开始实施MVC体系结构。 似乎有一个单独的视图，就像应该添加带模型的控制器一样。 但是到了某个时候，他们认为：“为什么我需要用一个按钮在屏幕上添加几个类？” 目前，我强烈建议您放弃这种恶毒的想法，并严格遵守“分而治之”的原则，以将UI和业务逻辑分开。 即使体系结构需要添加ViewModel类（其中将包含一两行代码），您也应该这样做。 因为在很多情况下，随着时间的流逝，最初只有一个按钮的屏幕会变得难以想象。 如果提前遵循逻辑组件的分离，那么这将极大地方便将来的生活。
在必须将屏幕从一个项目转移到另一个项目的情况下，您尤其可以感觉到UI和逻辑严格分离的本质。 或者在不同条件下，业务逻辑中使用不同算法的情况下。 例如，通过将授权屏幕划分为多个组件，我们将来可以替换其中一个组件而不会影响其他组件。 对于相同的数据，我们可以使用新的授权方法替换View或Model。
不要仅将这两层限制为“分而治之”的原则。 对于严格的分隔，我将为移动应用程序添加屏幕和导航逻辑的分隔。 那是什么意思
我的实践促使我通过分别取出导航逻辑来简化针对特定屏幕的编码。 屏幕（尤其是iOS的屏幕）是UIViewController，有时是UIView，而对于Android Activity或Fragment，则不应使用它们来显示自身以及切换到其他屏幕的功能。 这些类中的每一个仅应关心在特定屏幕上发生的事情，或者仅是在渲染特定屏幕并与业务逻辑类（Presenter，ViewModel等）进行交互时。
这些只是您需要从根本上遵循分离的许多示例中的两个。 遵循这一原则将极大地促进该项目的进一步工作。 即使govnokod包含在任何单独的组件中。
单一风格
从先前的建议无缝地开始，我想继续进行下一个建议，即严格遵守项目中的一种样式。
那是什么意思
首先，这里的关键词非常严格。 最初，我们选择一种组织项目，文件管理，代码风格等的单一方法。 这将显着改善项目的整体外观，并极大地方便项目的导航，通过代码进行搜索，并加快将新开发人员引入项目的过程。 我认为不值得提醒的是，过一段时间后，我们自己可以使用我们的旧代码成为这个新人。
选择架构并遵循
再次，根据先前的建议，我们顺利进行至下一个建议，即体系结构的选择。 我要传达的主要思想不是谈论最佳架构，也不是说您需要选择这个而不是另一个。 不行 首先，没有理想的架构可以完全涵盖项目中所有可能的情况。 我曾经听过这些话：“如果有理想的架构，那么我们的开发人员将被解雇为不必要的人，而将其替换为生成理想架构的脚本。”
我认为，要点不是选择最佳架构，而是再次严格遵循已经选择并开始应用的架构。 无论是VIPER，REDUX，MVP还是MVC。 上述每种体系结构当然都有优缺点。 随着时间的流逝，越来越多的新方法用于项目架构的设计。
我将更具体地谈谈我的想法。 如果您已经开始使用VIPER，请严格遵循其原则。 即使对于一键式屏幕而言，似乎有太多文件无法创建代码行，在任何情况下都不要绕过这些规则。 因为在这样的时刻，govnokod诞生了，然后它像雪球一样，一切都在增长。
我建议您熟悉最流行的体系结构，并在开始新项目之前选择自己喜欢的体系结构或最流行的体系结构。 我强烈建议您选择第二个选项，即从最受欢迎的架构开始 可以轻松找到许多问题的答案。 选择架构时，应特别注意该架构的不足之处，在这种情况下，建议使用该架构。
例如，如果一个有两个开发人员的小项目，那么您不应该选择VIPER，因为这是一个相当繁琐的体系结构，对于大型项目和大型团队非常有用。 因此，在任何情况下创建VIPER的代码都不会比业务逻辑本身的代码多很多倍。
就个人而言，我现在更喜欢MVVM +路由器架构。 它在我是一个开发人员的小型项目中效果很好。
底线：最主要的不是您选择哪种架构，而是您如何遵循它。
我还想补充一点，如果该项目不是从头开始开发的，那么首先您需要熟悉当前的体系结构和项目的总体样式，并开始遵循它。 您不应大声疾呼存在govnokod（返回第一个建议）并开始重做所有操作。 例外可能是项目完全混乱或缺乏通用样式。
重构暂停
最后，我想说的是，暂停重构是一个好方法。 重构是质量应用程序开发中非常重要的部分。 是的，我们不会立即编写完美的代码，但是将其原样放置也不是一件好事。 当您需要引入新功能时，原始实现常常没有扩展能力。 毕竟，几乎不可能预测项目的未来版本中的所有可能更改。 同样，没有架构可以保证所有情况的100％覆盖率。 因此，对现有代码进行更改以使其适应新功能很重要。