Короче, Мартин говорит, что без TDD невозможно сделать нормальный, чистый код.

Наверное, для многих эта страница будет финишной🥲

так и не закончив путь в поиске идеальной работы

Следом идем с перегрузкой операторов (operator overloading):

📌 создавать кастомные операторы нужно через выражение (pre/post/in)fix operator.

Например infix operator ~>

📌 у разных операторов есть свой приоритет. Например в выражении 2+3-6/3 высокий приоритет будет у оператора /

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

- Создание кастомных операторов
- Перегрузки в свифте

Про покраску кнопок

⚡️⚡️⚡️⚡️

Многие разрабы думают: «а зачем мне ваши тесты, алгоритмы и архитектуры ведь я только кнопки крашу?»

Но это ошибочное мышление. Возьму практические примеры.

Есть такая штука, как backend driven ui. Она есть во многих больших компаниях (сбер, Яндекс, авито). Если кратко, то вместо разраба экран могут создать даже менеджер. Как через те же Wordpress, tilda, jopmla с сайтами.

Для меня это эволюция систем отрисовки. Автоматизация разработки интерфейса. Комбинация дизайн системы + бэкэнда.

Для этого вам нужна хорошая дизайн система с уже разработанными компонентами. И бэкэнд.

Бэк отправляет вам json, который позволяет отрисовать на экране любой интерфейс из готовых компонентов. Это дико экономит и ускоряет разработку

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

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

Вот тут вам и нужно качать свои навыки по улучшению стабильности таких крупных и важных систем. Улучшения качества компонента, который используется в 20 экранах и имеет разные состояния в зависимости от фичафлагов, а/б тестов. Улучшение архитектуры и ее поддержка. Сбор обратной связи от продуктовых команд для инфраструктурных

🗯️Вы перестаете красить кнопки и становитесь инженерами большой системы.

📕 "Дилемма инноватора"

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

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

Автор делит технологии на "поддерживающие" и "подрывные". Большие компании пытаются много поддерживать, но слишком недооценивают маленькие стартапы. А когда рынок начинает расти, то не успевают адаптироваться.

Также интересно, как Apple и IBM украли технологию выввода информации на экран в растровой графике у Xerox PARC. Убив ее.

А первый поисковик назывался WANDEX. Позже его наработки украли Яндекс и Гугл.

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

#books

💻 Как оценить хорошую архитектуру?

Основной принцип хорошей архитектуры — простота.
Наилучшим дизайном считается простейший дизайн.

Что это значит? А значит, что текущая архитектура должна делать ровно то, что от нее требуется. Без маниакальной работы на перспективу.

Как говорит Мартин, подход усложнения был популярен в 1980х, 1990х. Программы долго запускались, а тестировать их было сложно. Так система пыталась быть сложнее, чем необходимо. Сейчас же стоимость автотеста дешевле, что легко экономит стоимость разработки

👍 Принцип YAGNI один из тех, который поможет нам оценить качество архитектуры.

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

💳 Если многолетнее присутствие в системе этого крючка будет дорого стоить, а вероятность того, что он в конечном итоге понадобится, низка — вряд ли имеет смысл его добавлять.

😂 UIGestureRecognizer

Наверное, повешать обработчик жестов — самый популярный способ для обработки событий. Обычно мы прикрепляем пару gesture'ов для вьюхи для тапа, свайпов и тп.

👆 Gestur'ы делятся на два типа:

✦ дискретные — вызывает экшен метод ровно один раз

✦ продолжительные — выполняет многократные вызовы экшен методов. например, UIPanGestureRecognizer вызывает экшен каждый раз, когда меняется положение пальца

🚗 Gestur'ы получают события касания раньше, чем вьюхи.

- Хэндлинг жестов
- Responder chain для хэндлинга событий

⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️

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

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

К черту этот хипстерский SwiftUI. Мы любим запах артрита и радикулита.

Поэтому начнем изучение того, что уже мертво — Obj-c

📘 "Идеальная работа" Р. Мартин

Каждый начинающий программист слышал о книгах Мартина. Трудно преуменьшить значимость его работ.

Только вот одна деталь. Не стоит торопиться бежать читать. В этом деле важна наваренность. Это блюдо требует медленного томления. У них нет терпения на незрелых. В их требованиях опыт и насмотренность.

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

Книги, как маяк. Плыть к нему дорого и далеко не всегда нужно обычному рынку.

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

Тут есть над чем поспорить. И чему вдохновиться.

#books