💎 Single Responsibility in Swift

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

Сейчас опустимся до деталей и посмотрим на реальный код на самом простом примере

🟢lvl: jun

DIP (Dependency Inversion Principle)

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

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

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

🟢lvl: jun

🍏 iOS simulator

Вы не ждали, а он пришел.

Встречайте симулятор иосника. Помните я отказался от марафонов и всяких инфоцыганских замашек и решил замутить что-то продуктовое?

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

Основная идея проста — сделать лучший симулятор для тренировок. Где будет баланс прикладной практики и фаном.

⭐️Что наc ожидает?
⁃ максимально рыночные вопросы собранные сотнями часами практик менторства и десятками годами работы в крупных компаниях
⁃ Статьи и учебные материалы
⁃ Реальные и полезные задачи
⁃ Интерактивные испытания
⁃ режим паники. в любой момент все может сильно усложниться
⁃ Доступ в секретный чат для обсуждений
⁃ Элементы геймфикации от нуля до Стива Джобса
⁃ Ежедневные испытания
⁃ Каждое задание будет вызывать челендж и азарт
⁃ Много новых и крутых фич

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

Open-Closed Principle в Swift

Идем дальше по самым популярным принципам.

Этот принцип в иос часто путают с extension (расширениями), но это далеко ошибочное от источника представление.

Принцип открытости/закрытости гласит:

❕ Программные сущности должны быть открыты для расширения и закрыты для изменения.
Принцип открытости/закрытости — одна из движущих сил в архитектуре систем.

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

⏺ Проще говоря, мы должны расширять программы без их изменения.

🟢lvl: jun

Let's go to practice

💋 KISS

Отвлечемся от SOLID к менее популярным, но иногда даже более важным принципам.

KISS (keep it simple, stupid)
Как-то в разговоре с коллегой он сказал, что я выдумал этот принцип. Ведь такое название и его расшифровку мог придумать только какой-то гопарь и ни один адекватный человек не будет воспринимать нэйминг всерьез.

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

По названию нетрудно понять, что он требует. У него много трактовок, но попробуем пройтись по основным:

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

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

🟢 lvl: jun

🎚 Антипаттерны в продуктовой разработке

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

Одна из турбулентностей для пришедших галлерных разработчиков в продуктовку — это простои. Я сам страдал после аутсорса. Человеку с ресурсным мышлением очень сложно работать в больших и крупных компаниях. Всегда будут большие процессы доставки нашего кода и придется развиваться в других плоскостях. Уметь коммуницировать, понимать процессы, менторить, вести задачи. Иными словами тут приходит уже не модный t—shaping.

Для тех, кто 8 часов привык не останавливаясь кодить — это очень больно. Но крупному бизнесу чаще нужно больше.

Какие же антипаттерны в продуктовой разработке?

🔴 не думать о бизнесе. Почему это плохо, ведь есть же бизнес-аналитики и продакт менеджеры? На самом деле очень большое кол-во слоев аналитиков и продакт менеджеров — это одна из самых проигрышных стратегий. А знание бизнеса для инженера — уменьшает неопределенность на проектирование и понимание задачи.

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

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

🔴 Непринятие творческих подходов — это снова из заказной. Где эксперименты не приветствуются, ведь все завязано на сроках и контрактах. Здесь умирает способность к инновациям.

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