#Книги #Рекомендации

О понятности

«Я сделал это письмо длиннее, чем обычно, потому что у меня не было времени сделать его короче и понятнее». Блез Паскаль

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

Перекладывать ответственность на читателя за декодинг речи и мыслей — графоманская и незрелая позиция, какой я сам боле(ю)л.

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

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

Читаю книгу Ильяхова "Ясно понятно". Читал давно "Пиши, сокращай" 2015 года издания. Не мог полностью её принять. Избыточное сокращение казалось убивает уникальность и добавляет недосказанности, неочевидности, неясности. Как с тем примером про цикл for each и reduce в функции.

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

Сейчас увеличение "ясности" — особенно актуально. Когда языки программирования стираются метаязыками и разговорными. Когда мы меняем гуглинг на чатгпт, а IDE на MCP и терминалы. Когда наступает сингулярность и размываются грани взаимодействия людей и машин. Ценность понятности вырастает.

В iOS-безопасности нет «поставил и забыл»: инструменты и атаки меняются быстрее релизов.

Если сомневаетесь, что на клиенте всё прикрыто, новый сезон конференции Podlodka iOS Crew 22-26 сентября поможет закрыть дыры.

В программе:

• Региональные ограничения и поведение устройства. Как iPhone определяет доступные фичи для страны, что проверять и как воспроизводить это на практике — со Светославом Карасевым (hh ru).

• Обфускация в iOS. Какие подходы реально мешают реверсу, какие инструменты выбрать и как собрать свой пайплайн на SwiftSyntax — с Павлом Каретниковым (Газпромбанк).

• AppSec для iOS. От ландшафта атак до хранения данных и сети — практики, ошибки и советы, как внедрять безопасную разработку в командах разного размера.

• Финальный разбор мини-CTF. Неделю собираем флаги, в пятницу — разбор находок и выводы для прода — с Никитой Красновым (Альфа-Банк).

🔗 Подробности и регистрация: https://podlodka.io/ioscrew

Для подписчиков скидка 500 р по промокоду: ios_crew_16_7V9XMN

Скрытая цена генерации юнит тестов с помощью AI

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

Я этот хак узнал случайно. Как-то я писал несложную, но извилистую логику замены ссылок. И подбирал разные тесткейсы для курсора. Ожидая что с такой рутинной работой он изи справится. Но он всегда упускал какие-то корнер-кейсы. Тогда я взял юнит-тесты андроид разрабов и тупо ему сказал "Смотри, вот есть юнит-тесты на котлине. Напиши мне код на Swift, чтобы работал успешно на этих тесткейсах". И всё. Он сделал за 2 минуты именно тот код, что мне нужен.

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

Знание доменной области (domain knowledge) — важная обязанность любого разраба. Например, кто-то пишет банковское приложение и знает особенности, правила, практики общей работы. И то, что на нее может повлиять. Например, выпилы приложений из сторов чаще в финтехах. А за неуплату налогов чаще строже карают чем за убийства...

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

Вот и автор не советует злоупотреблять автогенерацией тестов ведь:

1️⃣ Ручное написание тестов помогает понять домен
Когда разработчик сам думает, как покрыть разные случаи, ему приходится разобраться, как на самом деле устроены правила бизнеса (например, страховки, исключения, лимиты).

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

3️⃣ ИИ-тесты хороши как вспомогательный инструмент, но не как полный заменитель
Автоматически сгенерированные тесты — хорошая основа или дополнение, но ручной подход даёт более глубокое понимание и гибкость.

4️⃣ Поверхностные знания бизнес-логики
Если разработчик довольствуется “зелёным” результатом тестов, не вникая, он может не увидеть, где логика нестандартная или изменится. В дальнейшем это может привести к ошибкам, когда правила домена эволюционируют.

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

Почему MVx архитектуры всегда получаются плохо

Увидел офигенную статью у Миши Левченко про MVx паттерны. Мы много раз похожие мысле поднимали тут:
- В посте про переоценку UI-архитектур
- В "О, нет! Ты выбрал неправильную UI архитектуру!"

Мне нравится тренд, что индустрия начинает уходить от состояния "начинающего иллюзиониста" к "осознанным практикам". Уходим от затычек ввиде VIPER, TCA и любой другой MVx паттерн. Мы не пытаемся затыкнуть дыру очередным шаблоном, думая что он поможет избавиться от проблем. Хаотично не бежим изучать очередной архитектурный фреймворк.

Автор круто описал проблемы MVx паттернов:

1️⃣ Проблема остатка (remainder issue)
Когда ты пытаешься разбить фичу на компоненты по правилам MVx, часто остаются части, которые не вписываются идеально.
В итоге: много шаблонного кода, повышенная сложность, увеличение времени на тесты, на обучение новых разработчиков.

2️⃣ Проблема масштабируемости (scalability issue)
Даже если у тебя сейчас всё красиво разделено и “работает”, с ростом функционала фичи начинают “разбухать”.
В итоге: код становится труднее поддерживать, тестировать; компоненты жестко связаны, сложно изменять без побочных эффектов.

3️⃣ Проблема разрывов в логике (gaps or breaks in logic flow)
Проблема разрывов - это когда мы не можем гарантировать последовательность выполнения логики, потому что она была разорвана на части в процессе программирования.
Это усложняет написание тестов, ведёт к багам, т.к. сложно проследить все пути, по которым логика может пойти.

У меня тоже накопилось много контента, опыта и мнений по поводоу System Design vs Бездумная архитектура. Этими постами и контентами тоже мотивируюсь больше писать об этом.

К теме архитектур

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

Ща читаю снова кучу книг и материалов про system design для большой статьи. И самое сложное это удерживать и связывать все в голове. Дип ресерчить и комбинировать.

Особенно на контрасте это с клиповым и зумерским (не в обиду) мышлением. Где короткие видосы сделали нашу ОЗУ головного мозга размером с рыбки.

Или пытаюсь осилить стратегию Crusader Kings 3 уже третий раз. Не потому что прикалывает, а просто понимать все нюансы и стратегии для тренировки нейронки мозга.

Братья, что можете посоветовать из хороших книг или стратегий? А может чего-то другого

System Design-интервью: зачем они нужны и почему не всегда работают

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

1️⃣ Time to Offer

Сегодня 60% собеседований — это типовые задачи и вопросы. Часть из них кочует из компании в компанию.

Банально, задача с написанием юнит-теста на аналитику мне попадалась за 5 лет в нескольких разных компаниях. Казалось бы, найм супер упрощен. Есть сборник вопросов, достаточно пару раз сходить на собесы и ты уже +- понял правила игры. Да и интервьюров обучать не сложно. Просто есть методичка — проверяй по ней.

Но даже с таким простым подходом time to offer (время на получение оффера) обычно от 2 до 8 недель. Теперь представьте как увеличится время, если прогонять каждого не по максимально шаблонному собесу, а по сложному процессу. Где и критерии оценки очень размыты. Да и каждый интервьюр — это дорогой спец без свободных слотов на 1.5 часа собесов. Time to offer легко станет х2

2️⃣ Сложность критериев

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

Сис диз сложнее в оценке. Чтобы секция работала, нужно:
- подготовить интервьюеров,
- выровнять критерии оценки,
- договориться о «весе» каждого аргумента.

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

3️⃣ Кандидаты разного уровня

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

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

В найме цель не в том, чтобы провести "модное" интервью. Цель нанять подходящего инженера вовремя. Если систем дизайн удваивает Time to Offer и отталкивает кандидатов, он превращается не в инструмент, а в тормоз бизнеса.

Когда сломал индустрию

Жиза

Как вайбкодинг убивает твое критическое мышление

Первое правило it — перепроверяй. Себя, других, статьи из интернета, слова менеджера, обещания руководителей, лозунги компании.

Доверие — дорогая валюта и часто ценится теми, кто ей не разбрасывается.

Для меня все советы «не верьте всему что пишет чатгпт» выглядят очевидными. Банально от того, что есть баги везде. Заканчивая конспирологией и теориями о полит-инструментах.

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

1️⃣ не заменяй свое мнение на ответы ChatGPT

2️⃣ истинный рост происходит когда самостоятельно борешься с трудностями 🥷

3️⃣ в сложных знаниях доменной области не всегда важен навык кодинга

4️⃣ Вставляя бездумно код ты не понимаешь обьемы технического долга

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