Blogs

Как вы догадались, я считаю, что разработчики всех мастей должны обращать внимание на правильное выполнение вещей больше, но обо всем по порядку. Disclaimer Опыт, которым я хочу поделиться, я наблюдал у других и в своих проектах. Когда я говорю обобщенно разработчики, я имею в виду всех, кто выполняет задачи: тестировщики, фронтендеры, бэкендеры, дизайнеры и так далее. Проект - это конфликт Проект - это здоровый конфликт интересов его участников: Продакт оунер хочет, чтобы time-to-market был минимален, а конверсия и воронка - прямыми, как труба....

О компании Компания Clever (далее просто компания или Clever) разрабатывает e-commerce платформу для бизнесов с 2005 года. Целевая аудитория - компании, которые продают лицензии программ. Под капотом интеграция платежных систем, репорты, отчеты по воронкам продаж, и все это в большом монолитном приложении. Если вы покупали Parallels для своего макбука в течение последних пары лет, то вы точно проходили через платежные страницы Clever. Компания продуктовая, работает чуть больше ста человек. Из них больше половины - разработчики, организованные в команды по направлениям (юнитам)....

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

В Auth0 есть два способа получить токен: Создать аккаунт для пользователя Создать m2m клиент с определенными правами. Разработчики Auth0 дали возможность хранить дополнительную мета-информацию в аккаунтах и клиентах. Если в аккаунте человека нет ограничения на объем данных - в поле можно записать текст размером до 16 мб - то для m2m у нас в распоряжении только 10 полей по 255 символов каждый. Даже на небольшой массив места не хватит. В проекте мы активно применяем метаинформацию аккаунтов для формирования токена, такие же правила хотим применить и для m2m клиентов....

От автора блога Посмотрел доклад Анастасии Калашниковой “Правила осознанной карьеры разработчика” по наводке блоггера. Тема мне показалась интересной, орешил сделать конспект. Рефлексия для меня - это умение остановиться и спросить себя, а не хурму ли я делаю и какие будут последствия в будущем. Действительно, во время работы легко увлечься рутиной и забыть рефлексировать. Тем не менее, нужно останавливаться, ведь это еще и часть обучения. Мало послушать доклад, важно еще и понять, не зря ли его ты послушал и какие полезные советы и практики можно извлечь из него, а тут без рефлексии никуда....

Решил обновить домен для моего блога и сменить его на mgorbatyuk.dev. Мой блог хостится на GitHub Pages, поэтому смена домена не заняла много времени. Есть подробная документация, но мне стало интересно, есть ли удобный туториал а-ля “делай это, затем это, потом то, далее сё, и получишь результат” без дополнительных пояснений. Спросил у ИИ, и он дал такой туториал. Круто, что можно задавать уточняющие вопросы. В работе я постоянно пользовался GitHub Copilot и до релиза Chat GPT, мне он помогал генерировать разные утилитарные методы, которые не зависили от бизнес логики: хэширование пароля, чтение из файла, валидации, etc....

TLDR: Я считаю, что на проекте за качество ответственны только разработчики, значит они должны думать больше о качестве, чем о бизнес-ценности. Но есть нюанс. Disclaimer: под термином “разработчики” в посте я имею в виду и программистов, и тестировщиков. Code quality Разработчики должны понимать, что деньги для них берутся не из тумбочки, но и проект вряд ли будет приносить деньги, если стабильность оставляет желать лучшего. В интернете масса статей, где пишут, что нужно соблюдать баланс между качеством и скоростью доставки на продакшн, но такой совет звучит как “варить суп до готовности” - непонятно, как искать этот баланс....

Disclaimer: Советы ниже - вредные, доверять им не стоит. Антипаттерны придуманы не мной. В статье я стараюсь дать примеры, на которых будет видно, почему такие подходы и назвали антипаттернами Код юнит-тестов - это не second-class код, его тоже нужно писать поддерживаемым, читаемым и понятным для остальных ребят в команде. Курсивом - вредный совет, обычным шрифтов - пояснение. 0. Кукушка (Cuckoo, aka Stranger) Твой класс делает запросы к внешним системам? Отлично, проверь и вызовы тоже вместе с выходными данными....