10 хитростей, позволяющих избежать использования спагетти-кода при разработке iOS

Узнайте, как писать чистый и поддерживаемый код

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

Спагетти-код - это хорошо известный термин среди разработчиков. Это относится к неструктурированному проекту, который сложно понять и поддерживать. Большинство проектов с нестандартным кодом вызвано плохой практикой разработки программного обеспечения, такой как избыточность функций и несогласованное именование.

Некоторые разработчики могут возразить, что это неизбежно из-за сжатых сроков, большого количества запросов на добавление функций и опыта разработчиков. Однако, как хорошие разработчики, мы всегда должны искать лучший способ решения наших задач.

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

Для работы кода недостаточно. - Роберт К. Мартин, Чистый код: руководство по созданию гибкого программного обеспечения

Почему чистый код?

Есть три основных фактора, по которым мы должны держать наш код в чистоте.

1. Легко отслеживать ошибки

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

2. Расширяемость

У каждого продукта или приложения есть план для будущих добавлений функций. Недавно созданный проект iOS должен быть хорошо подготовлен к расширению новыми входящими модулями без частых серьезных изменений.

3. Легко понять и передать

Не оставляйте свой уродливый код на чистку другим разработчикам. Мы должны взять на себя ответственность сделать его максимально простым для чтения и чтения. Это должно быть легко понять не только вам, но и другим разработчикам.

Как избежать спагетти-кода

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

1. Планируйте хорошо, кодируйте лучше

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

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

2. Читаемость кода

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

1. Следуйте надлежащим рекомендациям по проектированию для именования, как указано в документации Swift.

Имена переменных и методов должны описывать их.

2. Включите средство проверки грамматики для более точных имен переменных и методов. Перейти к Edit Format > Spelling and Grammar

3. Используйте SwiftLint, чтобы обеспечить соблюдение одних и тех же стилей и правил написания во всем проекте.

4. Комментарии важны для быстрого изучения кода разработчиками. Проверьте здесь правильные рекомендации. Кроме того, на недавней конференции WWDC21 Apple представила новые инструменты документации Xcode под названием DocC.

5. Будьте последовательны в написании кода. Например, если все контроллеры представления используют segue для навигации, другие контроллеры представления должны следовать тому же подходу и не использовать pushViewController(). Таким образом, любую проблему, связанную с навигацией, легко устранить, взглянув только на segue вызовы и prepareForSegue.

3. Избегайте изменяемых глобальных переменных.

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

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

4. Правильное управление UserDefault

UserDefault очень полезен для хранения постоянных данных в различных типах данных.

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

5. Возможность повторного использования

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

Например, у нас есть несколько строк кода для изменения стилей фона, которые используются в нескольких контроллерах представления. Самое простое решение - добавить новую функцию в расширение UIViewController. Поэтому, если нам понадобится изменить стиль в будущем, мы можем легко обновить конкретную функцию в этом расширении.

Разве не все так просто? Я рекомендую уделять больше времени правильному структурированию кода для обеспечения гибкости в будущем.

Кроме того, я всегда стараюсь, чтобы каждый из моих UIViewController был простым, разбивая его на несколько UIView компонентов. Я создал учебник, чтобы объяснить процесс.

6. Избегайте ада обратных звонков

Есть несколько способов правильно вызвать несколько вложенных функций обратного вызова.

Используйте тип Result для чистого чтения данных обратного вызова.
Как недавно было объявлено на WWDC21, Apple представила в Swift 5.5 функцию async / await, которую мы можем использовать для решения этой проблемы. Помимо этого, мы также можем использовать библиотеки обещаний, такие как PromiseKit и Then. Потрясающие!

Простой способ (но немного беспорядочный), отличный от упомянутых выше, - избежать одновременного вызова методов обратного вызова и выполнения обработки данных. Вместо этого попробуйте разделить вызовы методов и процессы. Сравните два фрагмента кода в приведенном ниже примере.

7. Всегда используйте Codable.

Codable, стандартная библиотека Swift, была представлена в WWDC17, чтобы позволить разработчикам автоматически анализировать данные JSON и кодировать с использованием кодируемого и декодируемого протокола.

Никогда не используйте тип [String: Any] или Dictionary для чтения свойства данных JSON. Это делает наш код более сложным и трудным для обновления, когда наш бэкэнд обновляет новое свойство или структуру. Благодаря использованию decodable нам больше не нужны сторонние библиотеки для сопоставления данных JSON с определенной объектной моделью. Вы можете обратиться к более подробным объяснениям в этой статье.

8. Контроль доступа

Я понимаю, что не все будут пользоваться контролем доступа. Однако, если мы рассмотрим преимущества его использования, мы сможем написать лучший код. Фактически, это улучшает время компиляции и производительность приложений.

Например, если мы указали private доступ к переменной, другие классы не смогут получить к ней доступ. Его можно установить только в пределах одного класса. В результате, если нам нужно обновить извне, мы можем написать public функцию, которая выполняет конкретное обновление этой переменной. Основная цель - отслеживать изменения переменных, чтобы можно было легко идентифицировать любые ошибки или ошибки.

Нам также может потребоваться сохранить все функции как private, если они доступны только в одном классе. См. Простой пример ниже.

В этом примере класс HeaderView скрывает все переменные, кроме функции updatePost(). Это хорошая практика, чтобы убедиться, что объект post может быть установлен только из этой функции.

Другой полезный пример - использование final для класса, если мы подтверждаем, что класс не будет использоваться в качестве подкласса другими (не может быть унаследован).

9. Внедрение зависимостей

Я бы сказал, что внедрение зависимостей (DI) является дополнением к функциям контроля доступа, которые мы обсуждали в предыдущем пункте. DI кажется сложной схемой, но это не так. Это просто шаблон для принудительной передачи объекта зависимости при создании объекта.

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

В простом примере ниже возникает ошибка, потому что экземпляр SettingViewController не может быть создан, если объект Profile не передан в методе инициализации. Это супер круто.

10. Партнерская проверка кода

Хорошая команда разработчиков должна включить этот процесс в свой рабочий процесс, чтобы гарантировать, что они напишут хороший код, прежде чем отправлять его в производство. Это процесс, в ходе которого разработчики просматривают законченный исходный код друг друга и предоставляют отзывы, прежде чем он будет одобрен и объединен с основным рабочим исходным кодом.

В настоящее время все используют системы контроля версий, такие как GitHub и Bitbucket. Итак, мы должны быть знакомы с термином запрос на вытягивание (PR). Разработчик, завершивший модуль (в отдельной ветке), отправит PR в первичную / главную ветвь. Затем код будет рассмотрен другими разработчиками. Код будет напрямую объединен с целевой веткой, если рецензент одобрит. Рецензент может также отказать в одобрении, предоставив отзыв для улучшения.

Недавно Apple объявила об усовершенствовании инструмента совместной работы в Xcode 13 на WWDC21, который позволяет разработчикам выполнять интерактивные проверки кода и запросы на вытягивание прямо внутри Xcode.

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

Что дальше?

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

Есть несколько других расширенных методов, которые мы можем попробовать реализовать в нашем проекте iOS, например, принятие чистой структуры, реализация шаблона проектирования (синглтон, координатор и т. Д.), Использование шаблона архитектуры (MVVM, VIPER и т. д.) и добавление юнит-тестов.

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

Надеюсь, эта статья поможет вам улучшить свои навыки разработки. Пожалуйста, поделитесь, и спасибо за чтение. Мы будем благодарны за обратную связь. Удачи кодированию!