Качество кода *

Unit-тесты во фронтенде: развеиваем мифы

После статьи о навыках джуниоров многие не согласились с моей оценкой unit-тестов. Давайте посмотрим, где они действительно полезны, а где создают иллюзию ценности.

Если вы начинающий разработчик, вас наверняка убеждали:
«Без unit-тестов никуда! Всё должно быть покрыто тестами!»
Но так ли это на самом деле?

Где unit-тесты полезны:

• Бизнес-логика и утилиты (форматирование данных, расчёты)

• Кастомные хуки (управление состоянием, формы)

• Критичные функции (редкий зверь во фронтенде)

Где они бесполезны (и даже вредны):

• UI-компоненты (скриншотные тесты часто ломаются из-за изменений вёрстки)

• API с моками (моки не показывают реальное поведение сервера)

• Тестирование библиотек (проверяете чужой код)

Что использовать вместо?

1. Интеграционные тесты — проверяют реальные сценарии

2. Zod для валидации API — предотвращает ошибки из-за неожиданных данных

3. Ручные проверки — быстрее и точнее, чем скриншотные тесты

Для джуниора unit-тесты — не приоритет. Важнее:

• Глубокое изучение фреймворка

• Умение работать с API

• Навык чтения и отладки кода

Не стоит тратить время на «тесты ради тестов». Сосредоточьтесь на том, что действительно поможет в работе.

Красные флаги в код-ревью: перегибы, которых лучше избегать

1. Фокус на мелочах. Если уделять много внимания опечаткам и код-стайлу, то времени уйдет много, а реальных результатов будет мало. Главное — это всё-таки архитектура, алгоритмы и производительность, а косметика только на втором плане. Зачем портить настроение себе и команде, если можно ничего никому не портить?

2. Поверхностный анализ. Забивать на проверку кода — тоже плохая идея. И дело даже не в багах, их отловит тестировщик. Дело в безопасности всей системы. Если какой-нибудь хакер найдет уязвимость, которую QA не нашел, — жди беды. Ну и техдолг никто не отменял: если не делать сразу хорошо, однажды придется переделывать.

3. Токсичность. Во время код-ревью лучше всё-таки искать потенциальные проблемы с кодом, а не учить коллег работать. То есть фокус внимания — не на поиске недостатков в чужой работе, а на самом коде. А личные предпочтения и вкусы относительно кода лучше обсуждать отдельно.

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

А каким должен быть хорошее код-ревью — в нашем блоге.

Мой код, мой кофе, мой хаос

Для ЛЛ: перечислены способы мотивации сотрудников, которые вам могут показаться банальными

Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.

Ну не суть. Я сидел рядом и наблюдал за этим словесным баттлом. Проект уже грозил загнуться, не начавшись.  

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

Разрешение конфликта

Чтобы выйти из тупика, я предложил компромисс: «Ребята, давайте так. Каждый из вас реализует свою часть проекта с использованием своей библиотеки. На проверку идей у вас 2 дня, потом сравним, что получилось». Они согласились, и весь накал спора тут же утих – оба погрузились в работу, стремясь доказать, что их выбор лучший.

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

В таких случаях я обычно:

• Развожу спорщиков по разным проектам

• Или принимаю сам решение какую технологию использовать далее

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

Мотивация-шмотивация

Несмотря на подзаголовок, я приведу реально применённые способы поднятия мотивации разработчиков:

1. Деньги-деньги, решают многое. Сюда же незапланированные премии.

2. Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.

3. Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).

4. Про лишние дни отдыха тоже понятно.

5. Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.

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

Этих пунктов может быть ещё очень много, везде индивидуально.

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

Если есть чем поделиться, как вас мотивировали - прошу в комментарии.

Gemini 2.5 Deep Think получила первую официальную золотую медаль IMO среди AI-систем

20 июля 2025 года Google DeepMind совершила прорыв: их модель Gemini 2.5 в режиме Deep Think стала первой AI-системой, официально получившей золотую медаль на Международной математической олимпиаде (IMO). Разбираемся, что это значит для развития искусственного интеллекта и когда технология станет доступна разработчикам.

Что произошло на IMO 2025?

Gemini 2.5 Deep Think набрала 35 из 42 возможных баллов, решив 5 из 6 олимпиадных задач за отведённые 4,5 часа. Главная особенность — все решения проходили на естественном языке без формальных переводов в системы вроде Lean или Coq.

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

Важно: OpenAI заявляла о золотом уровне для своих моделей o1/o3, но официального признания от комитета IMO они не получали.

Архитектура Deep Think: мульти-агентное мышление

Технологический прорыв Deep Think заключается в нескольких ключевых инновациях:

1. Множественные потоки рассуждений

Модель запускает несколько параллельных "агентов", каждый из которых исследует свой путь решения. Затем результаты объединяются для финального анализа — подход, схожий с Grok 4 Heavy от xAI.

2. Увеличенное время на размышления

В отличие от обычных языковых моделей, Deep Think намеренно замедляет генерацию ответа, позволяя внутренним процессам глубже проанализировать проблему.

3. Специализированное обучение с подкреплением

Применяются алгоритмы RL, которые поощряют не только правильность решений, но и чёткость доказательств и качество формулировок.

Доступность и ценообразование

Здесь начинаются проблемы. Google выпустила две версии Deep Think:

1. IMO Gold версия — доступна только избранным математикам и исследователям

2. Bronze версия — публично доступна через подписку Google AI Ultra

Стоимость Bronze версии:

• $124.99/мес первые 3 месяца

• $249.99/мес в дальнейшем

• Включает: Deep Think, Veo 3 (генерация видео), 30 ТБ хранилища

Ограничения Bronze версии:

• Время ответа: 30-60 секунд на сложные запросы

• Ограниченное количество запросов в день

• Упрощённые возможности по сравнению с IMO-версией

Критический взгляд: стоит ли овчинка выделки?

Реакция комьюнити неоднозначная. Основные претензии:

1. Неоправданно высокая цена: многие пользователи отмечают, что подписка Ultra даёт те же квоты API, что и бесплатный аккаунт

2. Медленная работа: 30-60 секунд ожидания не подходят для продуктивной работы

3. Неясные перспективы: Google не сообщает, когда IMO-версия станет доступна публично

Значение для индустрии

Успех Deep Think на IMO знаменует переход от "умных автодополнений" к системам, способным к настоящему рассуждению. Это открывает новые возможности:

• Научные исследования: помощь в доказательстве теорем и решении сложных задач

• Инженерия: анализ комплексных технических проблем

• Образование: персонализированное обучение математике и логике

Что дальше?

Google обещает API-доступ к Deep Think "в ближайшие недели", но пока только для "доверенных партнёров". Полноценная IMO-версия может остаться исследовательским инструментом надолго.

Для разработчиков это означает ожидание: пока что Deep Think — это скорее демонстрация возможностей, чем готовый продукт для интеграции.

Выводы

Gemini 2.5 Deep Think действительно совершила исторический прорыв, став первой AI-системой с официальной золотой медалью IMO. Однако коммерческая реализация пока разочаровывает: высокие цены, ограниченный функционал и неясные перспективы развития.

Если вам нужна скорость и код — оставайтесь с GPT-4, Claude или o1. Если же готовы платить за глубокие рассуждения и не спешите — Deep Think может стать интересным инструментом.

BPN vs MVM

В двух, приложенных к этому посту файлах (здесь и здесь), показан код для решения одной и той же задачи в мобильном приложении. А именно: запустить обратный отсчёт перед началом игры.

В одном файле эта задача реализована в архитектуре BPN (Business Process Notation), о которой рассказывал раньше здесь. А во втором файле тот же код организован по архитектуре MVVM.

Код и в том, и в другом файле написан с помощью Claude Sonnet. В случае с BPN структурировал код вручную, следуя бизнес-процессам. А во втором случае попросил Клода сделать рефакторинг, используя традиционный современный подход и он выбрал MVVM.

Что можно сказать в итоге, сравнивая архитектуру в том, и другом случае. 

Объём кода

В BPN варианте 270 строки кода с комментариями, в MVVM - 524.

Т.е., в MVVM случае кода практически в 2 раза больше.

Количество сущностей, объектов.

BPN - один класс и 3 раширения к нему.

MVM - 6 классов, 1 структура, 3 протокола, каллбэки, фабрика, расширение.

Архитектура

BPN - монолит.

MVVM - вью и модель, анимация и аудио как сервисы, роутер, отдельная структура для хранения значений свойств и т.д.

Что лучше

Как всегда, каждый из подходов имеет свои плюсы и минусы.

В BPN нравится, что можно видеть модель процесса, в данном случае модель одной из задач приложения.

Что такое “Модель”

Наиболее традиционны 2 понимания термина “модель”.

В одном случае, это структура данных, модель объекта.

Например:

struct Person {

let firstName: String

let lastName: String

var age: Int

}

В другом случае, под моделью понимается всё, что не относится к интерфейсу.

Но есть и третье понимание модели - это модель приложения, или модель отдельных процессов внутри приложения. Т.е., составные части приложения (процесса) и их последовательность.

В BPN файле такая модель проступает наглядно:

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

В файале MVVM блоков кода гораздо больше и нужно несколько раз проскоролить чтобы увидеть их в выпадающем меню. И увидеть целостную модель здесь сложнее.

Conclusion

На относительно небольших проектах архитектура MVVM может быть избыточна. Здесь могут использоваться более простые варианты.

BPN позволяет видеть целостную модель задачи (процесса, приложения).

Выводим Соера на чистую воду разбирая дискуссию с ним про принципы SOLID

Топ перлов

• Если ты манки-патчишь объекты, то ты функциональщик.

• Ты должен сначала залезть на гору, а потом уже решить надо было тебе сюда или нет.

• Если люди по разному воспринимают принцип - это здорово, ведь он подталкивает людей к размышлению.

• SOLID позволяет легче (т.е. не задумываясь) принимать не идеальные (т.е. сомнительные) решения.

Упомянутые материалы

• Деконструкция SOLID

• Систематизация вариантности типов

• Инверсия контроля на голом Инверсия контроля на голом TypeScript без боли

Копилка благодарностей

Возможно, покажется странным, зачем публиковать, но пока я готовился к поиску новых возможностей и приключений, это начало звучать как кредо. Поэтому подумал почему бы не поделиться?:)

Дисклеймер: На этот раз я не использовал никаких AI тулов для помощи:)

Мои принципы работы:

1. Этические принципы.

   Почему: когда у бизнеса есть определенные принципы разработки программного обеспечения, он обычно отдает приоритет созданию уникальной ценности для конечного пользователя. Это очень помогает в определении того, как команда общается друг с другом, как выглядит и функционирует приложение, как пишется код (задавая ограничения и свободы внутри). Также, имея этические принципы, становится более понятно, когда можно использовать AI (в конечном продукте или в IDE), а когда нет.

2. Пользовательский и командный опыт.

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

   Значение: ценю опыт других людей и считаю, что культура обмена опытом стоит потраченного времени.

3. Ценность через заботу и инновации.

   Верю, что приложение должно быть простым, сфокусированным и стоить времени людей, которые им пользуются. В сочетании с развивающимися технологиями, особенно с AI (облачными или локальными LLM's), думаю, что очень многое можно переосмыслить и фундаментально пересмотреть, сделав пользовательский опыт приоритетом.

4. AI:

   Использую Cursor (в основном) для написания кода. Но в то же время думаю о AI как о коллеге, который может научить меня новому, переосмыслить старое. В то же время каждое мое решение, где и почему я его использую, основано на этических принципах — это позволяет мне создавать быстрее, но с более высоким качеством для конечного пользователя и разработчика.

5. Разработчик, дизайнер и QA как пользователь.

   На мой взгляд, каждый, кто может получить доступ к коду, тоже является пользователем.

   Значение: написание полезной документации, создание полезного API, обеспечение доступности дизайн-системы для дизайнера, получение любой обратной связи (через ревью кода или предварительный просмотр приложения) чрезвычайно важно. На мой взгляд, этот процесс делает лучше не только продукт, но и каждого человека, участвующего в его создании.

6. Прототипирование.

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

7. Тайминг.

   Обычно я использую простую формулу, чтобы получить наиболее точное время: Команда + Известные знания + Мой опыт + Мой опыт в кодовой базе | домене.

   Значение: при оценке того, как долго может разрабатываться фича/баг/приложение, мне обычно нужно знать людей, которые работают со мной, затем кодовую базу и затем объединить это со всем, что я знаю.

Надеюсь, этот пост вдохновит и окажется полезным в какой-то степени :-)

Пожалуйста, поделитесь своими мыслями в комментариях :-) это поможет сделать эту ветку видимой для других и станет отличной поддержкой и мотивацией :-)

Спасибо за ваше время и хорошего дня!

Карма vs Инженерная честность: Почему рейтинги убивают экспертизу

Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.

Социальная инженерия вместо экспертной оценки

Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:

Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив").
Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь").
Осмелился быть лаконичным без смайликов? → Минус ("агрессия").

Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.

Карма как инструмент подавления инакомыслия

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

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

Что делать?

1. Игнорировать карму как погрешность системы (но тогда зачем она?).

2. Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".

3. Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.

Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.

P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко.
P.P.S. Карма — временна. Культура дискуссии — вечна.

Глубокий спец vs Фулстек. Я наверное никогда не устану говорить об этой теме, потому что для меня фулстек это нормальное состояние разработчика, в смысле легко достижимое, а не история про то что это обязательно плохой спец во всем. Более того, для меня норма, когда разработчик:

- Может в бек в несколько языков
- Может во фронт
- Умеет и настраивает пайпланый от Docker Compose до Github Actions
- Может сетапить и настраивать облака

(дисклеймер: речь не о том, что таким должен быть каждый, а что это не рокет сайнс все это уметь на хорошем уровне, достаточным чтобы классно делать проекты)

Что обычно имеют ввиду под глубоким спецом? Что человек прямо досканально знает все, быстро дебажит, создает качественный и поддерживаемый код (это ведь подразумевается?).

Знает ли досконально все? Вообще не факт, а скорее всего нет. От того что человек занимается только чем-то одним, не означает что он сидит и как не в себя копает во внутрь по этой теме. Как правило я вижу другую картину, если делать долго и упорно одно и тоже, то в какой-то момент это все делается на автомате, а дальше человек просто останавливается в развитии (соседний фреймворк не считается) ну либо становится тем, о ком я пишу выше.

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

А качественный код? Вот тут вообще никакой корреляции. Да, мы все слышали, что приходят беки и пишут фронт, после которых надо все переписывать, но это не ситуация, которую я рассматриваю. Мы все таки говорим про фулстеков, то есть тех кто целенаправленно учит, а не пишет фронт, потому что попросили, а он не сечет и не планирует учиться писать правильно. Что касается в целом подходов, то люди с более широким кругозором и опытом пишут обычно лучше. Потому что качество кода проявляется не в мелких деталях, что вы например в курсе про более крутой хук. Это все локальные оптимизации. Качество оно про более высокий уровень.

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

p.s. Больше про разработку я пишу в своем канале Организованное Программирование

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

баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'

А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода

вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').

Бесконечный 'анализ'

'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'

Ответственность - это не про нас
Любимый приём - щедро размазать вину:

'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').

Реальный кейс (чтобы было не абстрактно)

В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.

А потом... уволился.

Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может

Как понять, что ваш техлид центральная часть системы самообмана?

главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать

Что прикажете с этим делать?

тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.

ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.

Задавать всего один вопрос

'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.

Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.

Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.

P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение

Выложили в открытый доступ Kodify Nano – модель для кодинга

Это уже вторая опенсорс-модель от MWS AI (ранее MTS AI) – первую, Cotype Nano для работы с текстами, выпустили в конце прошлого года. 

Ключевые характеристики:

• 1,5 млрд параметров; 

• контекст  32 768 токенов;

• ключевые языки: Python, Java, JavaScript, C# и Go 

Функции:

генерация и автодополнение кода;

документирование разработки;

генерация юнит-тестов;

объяснение чужого кода. 

Встраивается в среды разработки, работает в формате чат-ассистента. Поставляется в трех версиях, все можно скачать на Hagging Face:

Kodify‑Nano – рекомендуется на видеокартах Nvidia c не менее, чем 10 Гб памяти.

Kodify‑Nano-GPTQ (4bit) – квантизированная версия Kodify Nano, которая в три раза меньше оригинальной модели. Рекомендуется на видеокартах Nvidia c не менее 6 Гб памяти.

Kodify‑Nano-GGUF – сконвертирована для работы с Ollama/llama.cpp. , на случай, если нет мощной видеокарты. Есть варианты 16 бит, 8 бит и 4 бита.

Мы рекомендуем использовать модели с нашим собственным плагином (скачать тут), он уже настроен для работы с Kodify Nano. Есть версии для VS Code и IntelliJ IDEA (и других IDE Jet Brains). 

Знаем, 1,5B параметров – это совсем немного. Основная корпоративная модель – Kodify 2, вышедшая ранее, – тоже не гигант, 7B. Вот тут в статье рассказываем, почему пошли по пути создания легковесных моделей, и что делаем, чтобы они справлялись со своими задачами достойно. 

Каковы задачи Абстрактной Фабрики?

Новая серия курса «Паттерны и практики написания кода» целиком посвящена разбору достаточно громоздкого паттерна — Абстрактной Фабрики. Вместе с бэкенд-инженером Юрой Афанасьевым на примерах разберем, что это такое и как она реализуется.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Порождающие паттерны: какие они и в чем их назначение?

В новой серии третьего сезона курса «Паттерны и практики написания кода» перейдём от теории к практике и погрузимся в мир прикладных паттернов. В предыдущем видео мы узнали, что паттерны делятся на три группы: сегодня вместе с бэкенд-инженером Юрой Афанасьевым начнём рассматривать первую из них — порождающие паттерны. 

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Как правильно работать с паттернами кода?

Всем привет! Это третий сезон курса «Паттерны и практики написания кода». Первая серия вводная: в ней бэкенд-инженер Юра Афанасьев знакомит вас с историей паттернов и их функциями, а также рассказывает, как с ними правильно работать.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Как писать REST API — 9 правил

REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль взаимодействия между клиентом и сервером через HTTP. Он определяет принципы построения API, обеспечивая стандартизированный и эффективный обмен данными между различными системами.

1. GET-запросы не должны что-то сохранять, удалять или изменять. Нельзя менять какие-либо данные на стороне сервера при GET-запросе. Почему? GET-запросы часто кешируются на стороне клиента.

2. POST запросы для загрузки/создания сущностей, PUT для изменения в сущности, а PATCH - для мелких изменений в сущности.

3. Наименование эндпоинтов. Должен присутствовать единый стиль, и желательно во множественном числе, ибо это более лаконичнее. Например, эндпоинт /users. Можно и единственное число использовать, но обосновано.

4. Иерархия. Нужно соблюдать единую иерархию для построения запросов. Конструкции /users/1/friends/3/items/4 будет неудобно использовать разработчикам клиентских приложений. Нужно избегать такую иерархию, нужно конкретно указывать что нам нужно, не перезагружать данными.

5. Соблюдайте версионирование API. Допустим: /api/v1/get_all_users и /api/v2/get_all_users. При выходе новой версии не всегда разработчики готовы переписать логику клиентских приложений, и для этого нам нужно разделять версии API

6. Чувствительные данные. Очень важный момент. Например, передача различных паролей в Query-параметрах запрещено, только в теле запроса.

7. Из 6 вытекает 7е правило: не логируйте персональные и прочие секретные данные. Было несколько случаев, когда из-за логирования параметров утекали данные пользователей.

8. Расширение ответов. Во-первых, не передавайте массивы в самом верхнем уровне ответа. JSON-ответ от сервера не должен быть массивом, только словарь (ключ-значение). Если мы будем возвращать список, в будущем нам будет неудобно расширить ответ сервера, добавив дополнительные параметры. А также иногда в API разработчики делают обязательные параметры, например помимо самих данных параметр success и error, чтобы клиентское приложение могло понять, что произошла ошибка, или наоборот, успешно выполнилось.

9. Работа с датой и временем. Есть два метода - использование Unix Timestamp (количество секунд прошедших с 1 января 1970 года). Это в какой-то степени более удобно для машины, но менее удобно для клиентского разработчика. И второй метод как раз делает формат даты и времени более понятным - это ISO 8601 (2025-04-05T12:00:00.100Z). Этот метод более удобный, т.к. мы понимаем дату и часовой пояс, точное время.

10. Бонусное правило, лично мое. Относится не только к REST API, но и в принципе к программированию. Пишите код так, как будто эта поэма, книга. Попробуйте сами поработать со своим API, будто вы его не писали. Разделение ответственности, единая точка отказа, Don't Repeat Yourself и даже Keep It Simple, Stupid. Все это конечно-же вариативно.

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

Вот продукт готов, покупатели и менеджеры довольны... Они твои пользователи.

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

Да, да.... это я, твой коллега, твой первый пользователь, твой продукт - это код, я им пользуюсь.

Почему ты не подумал обо мне: не написал README, не оставил инструкций, не озвучил подводные камни? Почему мне нужно провести реверс-инжинириг, просто что бы запустить или задеплоить проект?

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

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

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

Регулярно на Хабре выходят статьи с рекомендацией использовать moment.js. В комментариях обязательно начинают советовать какой-нибудь dayjs или js-joda, но не потому, что они чем-то сильно лучше, а потому, что первый задепрекейчен авторами.. в пользу luxon.

Что за мания такая у JS-еров использовать раздутые тормозные библиотеки? Есть же быстрый и миниатюрный $mol_time с гораздо более удобным и функциональным API, почти полностью поддерживающим ISO8601, в отличие от всех остальных библиотек.

Что мотивирует людей довольствоваться не самым лучшим решением в индустрии? Я, наверно, странный, но я не могу этого понять.

Должен же тимлид смотреть Merge Request (Pull Request)? 

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

• контролировать качество кода программистов команды;

• следить за соблюдением принятых стандартов;

• управлять рисками кодовой базы команды;

• обучать участников команды через ревью их кода;

• держать руку на пульсе того, чем занимаются участники команды. 

Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет. 

Для разрешения данной ситуации вы можете:

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

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

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

 Как поступить?

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

Максимально возможное покрытие фитнес-функциями (автоматические форматтеры, автотестеры, анализаторы кода). Согласуйте с техлидами внедрение в проект автоматических анализаторов и добавьте их в пайплайны репозитория. Ни один MR не пойдёт на ревью до тех пор, пока не будет соответствовать установленным стандартам. Так вы сэкономите массу времени.

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

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

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

В итоге, если тимлид вместе с техническими лидерами выстроит жёсткую систему доставки инкремента на продакшн, ему самому не обязательно просматривать каждый MR своей команды. Исключение составляют лишь те случаи, когда «душа просит».

P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`

Ну что, народ, что называется "тащусь" от новой сегодняшней версии ChatGPT CodeCopilot.

Там теперь появились три окна. Слева знакомый чат, в центре код, причём теперь уже с возможностью редактировать прямо здесь. А справа ещё менюшка с несколькими опциями. Там и комментарии, и логи, и борьба с багами и др. В целом, стало даже немного похоже на Xcode.

Мне же особенно понравилась опция Code Review. Это круто! Типа он проходит по коду и даёт рекомендации.

For example:

I've reviewed the code and suggested improvements for logical consistency, potential crash prevention, layout calculations, and readability. Let me know if you need further refinements! 🚀

Даже не знаю, как это назвать. Реально круто!

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

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

Смотря назад, я понимаю что поворотным моментом в моей карьере стал период, когда я увлекся функциональными языками и курсом СИКП, по которому потом во многом строилось обучение на Хекслете. Произошло это так, я видел что вокруг меня, многие профессионалы, говорят и используют функциональные языки и какие-то связанные с этим подходы. В тот момент речь шла про erlang, scheme/racket (для сикпа), clojure и haskell, которые я в разной степени начал изучать. На эрланге даже получилось сделать проект codebattle.hexlet.io, который потом, спустя много лет переписали на elixir (это опенсорс).

Изучение этих языков многое перевернуло в моей голове и дело даже не в том что они функциональные, а в том, что в среде программистов на этих языках поднимались вопросы, с которыми я раньше не сталкивался. Я понял что смотрел на разработку не на том уровне. Весь мой предыдущий опыт был скорее в стиле вот чистый код, вот мартин, вот фаулер, вот ООП, вот паттерны. Как оказалось, несмотря на здравые мысли в этой части, все же это была оболочка, а не фундамент. А фундамент лежал в таких областях как управление состоянием, изоляция побочных эффектов, конечные автоматы, statefull/stateless части системы и тому подобное.

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

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

p.s. Делюсь опытом программирования в своем телеграм-канале организованное программирование