Open-Closed Principle в Swift

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

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

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

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

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

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

🟢lvl: jun

Let's go to practice

💋 KISS

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

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

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

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

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

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

🟢 lvl: jun

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

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

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

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

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

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

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

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

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

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