Узнайте, как содержать его в чистоте
Важно поддерживать структуру вашего проекта в чистоте и порядке. Когда вы работаете над большим проектом с сотнями файлов в команде, вы хотите, чтобы вы и ваши товарищи по команде могли найти все, что вам нужно, в течение нескольких секунд. Проект должен быть организован с самого начала, и каждый в команде должен следовать той структуре, которая у вас есть, потому что некоторые разработчики могут уйти, а к вашей команде могут присоединиться новые.
В этой статье я покажу вам некоторые распространенные ошибки, которые допускают младшие разработчики, и поделюсь тем, как я структурирую каждый проект, над которым работаю.
Самая распространенная ошибка
Давайте взглянем на этот короткий пример проекта с архитектурой MVC:
Кажется, все улажено. Все виды находятся в одной папке, все контроллеры вместе внутри папки /Controllers, а модели сгруппированы в папке /Models. С проектом такого размера, когда у вас есть 3-5 экранов, это может сработать. Но давайте будем реалистами и представим, что мы работаем над проектом с более чем 20 экранами и не менее чем с 20 контроллерами представлений. Будет огромный бардак. Вы не можете просто помещать файлы в одну и ту же папку только потому, что у них есть что-то общее, например. унаследованы от того же класса. Потому что в этом случае вы получите папки с более чем 30 файлами внутри, и найти что-то внутри таких папок очень сложно.
Признак хорошо структурированного проекта
Ваш проект хорошо структурирован, если кто-то, кто не знаком с ним, чувствует себя с ним комфортно.
Это означает, что ваши папки и файлы должны быть организованы и названы так, чтобы каждый мог найти то, что ему нужно, за несколько секунд. Если я исправлял какие-то баги в представлении, а потом мне нужно сделать какие-то исправления в контроллере, я не хочу открывать папку /Controllers с 30+ файлами внутри и искать нужный мне контроллер.
Лучшая практика
При группировании файлов и папок следует придерживаться следующего правила:
Храните вместе файлы, которые в первую очередь связаны друг с другом или иным образом имеют что-то общее.
Что это значит? Позволь мне объяснить. Допустим, у вас есть простой модуль MVVM, который содержит контроллер представления, представление, модель представления и некоторые дополнительные подпредставления. Все эти файлы должны быть помещены в одну папку. Это потому, что все они связаны друг с другом, потому что все они являются частями одного модуля.
В проекте на скриншоте слева все модели видов находятся в одной папке, все виды вместе, и одинаковы для всех моделей. Мы обсуждали это раньше, это не лучшее решение. Теперь взгляните на скриншот справа. Он выглядит более структурированным. У нас есть папка для каждого модуля, который у нас есть, эти папки содержат контроллер представления, модель представления и модель для конкретного модуля. Затем все модули группируются внутри папки /Modules. При такой организации мы знаем, что все модули находятся в папке /Modules, а все файлы, относящиеся к конкретному модулю, находятся в папке с именем модуля, например /SomeModule.
Теперь мы знаем, как группировать модули. Но есть еще несколько вещей, которые мы можем иметь в проекте. Это сервисы, настраиваемые повторно используемые представления, расширения и ресурсы (цвета, шрифты, строки, URL-адреса и т. д.).
Многоразовые представления
У нас может быть 2 типа многоразовых представлений. Представления, которые мы собираемся использовать в приложении, например. кнопки и текстовые поля. И представления, которые используются только в одном конкретном модуле, например, вы решили создать отдельное представление заголовка для одного из ваших модулей.
В первом случае все эти представления должны находиться в одной папке, например. /UIComponents. И внутри этой папки вы можете сгруппировать их в зависимости от их суперклассов, например. /Buttons и /Textfields.
А представления, относящиеся к конкретному модулю, должны быть размещены внутри папки модуля в отдельной папке для компонентов пользовательского интерфейса, например. /Subviews или /Components.
Услуги
Это довольно просто, когда дело доходит до услуг. Вы помещаете все службы в какую-то папку /Services или /Managers. А внутри папки корневой службы вы создаете новую папку для каждой имеющейся у вас службы. Вы создаете папку для каждой службы, так как с вашей службой может быть связано еще несколько файлов. Представьте, что вы работаете над APIService. Вам нужен файл для его протокола, для списка конечных точек, для DTO (объектов передачи данных), которые вы извлекаете, и так далее.
Другие файлы
Мне не нравится иметь много папок и файлов в корневом каталоге проекта. Вот почему я предпочитаю помещать все эти файлы в одну папку с именем/Common, когда речь идет о других вещах, таких как ресурсы, расширения, файлы JSON/CSV и т. д. Внутри папки /Common вы создаете другие папки для ваших файлов, например. /Resources, /Extensions, /JsonFiles и так далее.
Такой подход помогает содержать корневой каталог в чистоте.
Заключение
Очень важно организовать ваш проект с самого начала. Все остальные разработчики, которые присоединятся к вашей команде, будут следовать структуре, которую вы уже создали.
Спасибо за ваше время. Надеюсь, вам понравилась эта статья и вы нашли ее полезной. Не стесняйтесь поделиться своим мнением по этой теме в комментариях.
Check out my other articles about iOS Development https://medium.com/@artem.khalilyaev
