Лучший способ структурировать iOS-проект

Важно поддерживать структуру проекта в чистоте и порядке. Когда вы работаете над большим проектом с сотнями файлов в большой команде, вы хотите, чтобы вы и ваши товарищи могли найти все, что вам нужно, в течение нескольких секунд. Проект должен быть организован с самого начала, и все члены команды должны следовать той структуре, которая у вас есть, потому что некоторые разработчики могут уйти, а новые могут присоединиться.

В этой статье я расскажу вам о некоторых распространенных ошибках, которые допускают junior-разработчики, и поделюсь тем, как я структурирую каждый проект, над которым работаю.

Самая распространенная ошибка

Давайте рассмотрим этот короткий пример проекта с архитектурой MVC:

Кажется, что все упорядочено. Все представления находятся в одной папке, все контроллеры вместе в папке /Controllers, а модели сгруппированы в папке /Models. В проекте такого размера, когда у вас 3-5 экранов, это может сработать.

Но давайте будем реалистами и представим, что мы работаем над проектом с 20+ экранами и имеем как минимум 20 контроллеров представления. Это будет огромный беспорядок. Вы не можете просто поместить файлы в одну папку только потому, что у них есть что-то общее, например, наследование от одного класса. Потому что в этом случае вы получите папки с 30+ файлами внутри, а найти что-то в таких папках очень сложно.

Хорошо структурированный проект

Ваш проект хорошо структурирован, если любой, кто не знаком с ним, чувствует себя в нем комфортно.

Это значит, что ваши папки и файлы должны быть организованы и названы так, чтобы любой мог найти то, что ему нужно, в течение нескольких секунд. Если я исправил некоторые ошибки в представлении, а затем мне нужно сделать некоторые исправления в контроллере, я не хочу открывать папку /Controllers с 30+ файлами внутри и искать нужный мне контроллер.

Лучшая практика

При группировке файлов и папок следует придерживаться следующего правила:

В первую очередь держите вместе файлы, которые связаны друг с другом или имеют что-то общее.

Что это значит? Позвольте мне объяснить. Допустим, у вас есть простой MVVM-модуль, который содержит контроллер представления, представление, модель представления и несколько дополнительных вложенных представлений. Все эти файлы должны быть помещены в одну папку. Это потому, что все они связаны друг с другом, потому что все они являются частями одного модуля.

В проекте на скриншоте слева все модели представлений находятся в одной папке, все представления вместе, и то же самое для всех моделей. Мы уже обсуждали это, это не самое лучшее решение.

Теперь посмотрите на скриншот справа. Он выглядит более структурированным. У нас есть папка для каждого модуля, эти папки содержат View Controller, View Model и модель для конкретного модуля. Затем все модули группируются вместе в папке /Modules. При такой организации мы знаем, что все модули находятся в папке /Modules, а все файлы, относящиеся к конкретному модулю, находятся в папке с названием модуля, например, /SomeModule.

Теперь мы знаем, как группировать модули. Но есть еще несколько вещей, которые мы можем иметь в проекте. Это сервисы, кастомные многократно используемые представления, расширения и ресурсы (цвета, шрифты, строки, url и так далее).

Переиспользуемые представления

У нас может быть 2 типа многоразовых представлений. Представления, которые мы собираемся использовать во всем приложении, например, кнопки и текстовые поля. И представления, которые используются только в одном конкретном модуле, например, вы решили создать отдельное представление заголовка для одного из ваших модулей.

В первом случае все эти представления должны находиться в одной папке, например, /UIComponents. И внутри этой папки вы можете сгруппировать их в зависимости от их суперклассов, например, /Buttons и /Textfields.

А представления, которые относятся к конкретному модулю, должны быть размещены внутри папки модуля в отдельной папке для компонентов пользовательского интерфейса, например, /Subviews или /Components.

Сервисы

Когда речь идет о службах, все довольно просто. Вы помещаете все службы в папку /Services или /Managers. А внутри корневой папки сервисов вы создаете новую папку для каждой службы, которая у вас есть. Вы создаете папку для каждого сервиса, поскольку у вашего сервиса может быть еще несколько файлов, связанных с ним. Представьте, что вы работаете над сервисом APIService. Вам нужен файл для его протокола, для списка конечных точек, для DTO (объектов передачи данных), которые вы получаете, и так далее.

Прочие файлы

Мне не нравится иметь много папок и файлов в корневом каталоге проекта. Поэтому я предпочитаю помещать все эти файлы в одну папку с именем /Common, когда дело доходит до других вещей, таких как ресурсы, расширения, JSON/CSV файлы и т.д. Внутри папки /Common вы создаете другие папки для имеющихся у вас файлов, например, /Resources, /Extensions, /JsonFiles и так далее.

Такой подход помогает сохранить корневой каталог чистым.

Заключение

Организовать свой проект с самого начала — важная задача. Все остальные разработчики, которые присоединятся к вашей команде, будут следовать уже созданной вами структуре.

Спасибо за ваше время. Надеюсь, вам понравилась эта статья и вы нашли ее полезной.

Источник