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

Во-первых, молодец! Это потрясающе. Ты классный! 💪

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

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

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

Уровень доступа

Поначалу на модификатор private почти никто не обращает внимания. Между тем, каждый может мгновенно объяснить SOLID , если разбудить его среди ночи. Начитавшись разных умных статей, люди пытаются создать кучу классов по идее S (единая ответственность).

А потом с чистой совестью меняют собственность class A на class B и наоборот.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

В общем, если еще непонятно, то план такой: всегда и везде писать private , а когда компилятор жалуется — подумайте, а можно ли обращаться к этому свойству или функции извне? И если это так — удалите private .

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

В конце концов, у покупателя не должно быть доступа к кассовому аппарату, даже при использовании put , не говоря уже fetch .

Можно возразить: «Я прекрасно понимаю, какое свойство можно трогать, а какое нельзя даже без модификатора private ». Однако написание модификаторов уровня доступа является частью проекта. Я уверен, что вы не станете создавать проект дома с дверью на третьем этаже, ведущей наружу.

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

Кстати, аналогичная ситуация существует с var и let . Опять же, всегда используйте let , если только вы не уверены, что сразу измените значение.

Архитектура Простота

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

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

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

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

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

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

А для организации кода в веб-приложениях и настольных приложениях — когда одни и те же данные нужно было переупорядочить с разных точек зрения — появился шаблон MVC (т. е. отделение модели от ее визуального представления).

Вы уловили основную мысль: возникает проблема -> появляется решение. Проблема -> Решение.

Так почему же начинающие программисты сейчас начинают применять решения (архитектуры) в тот момент, когда проблемы еще не возникли? Туториалы сразу предлагают выбрать хотя бы MVP. В тестовых заданиях для одного/двух экранов всегда указано НЕ использовать MVC.

На собеседованиях человека, написавшего пару пет-проектов с одинаковыми одним/двумя экранами, спрашивают о проблемах VIPER. Откуда он мог знать о проблемах, если он еще не столкнулся с ними?

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

Они могут объяснить схему MVP простыми словами, но часто путаются, когда речь идет о протоколах со схожими названиями, таких как ViewInput и ViewOutput . В глубине души они уже воспринимают все это как какие-то накладные расходы 🙄🤯

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

Простота пользовательского интерфейса

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

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

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

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

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

правило 80–20 применяется здесь — создайте основу приложения, а затем добавьте дополнения. Противоположный подход приведет к тому, что придется разбираться со сложными нюансами и постоянно иметь дело с основной функциональностью, которая постоянно ломается.

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

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

Понимание основополагающих принципов и решение реальных проблем по мере их возникновения имеют решающее значение для эффективного развития.

Также опубликовано здесь