Но если у тебя есть тесты и нормальный CI/CD, то так уж и быть

После релиза целый спринт дадим на рефакторинг!

Кто с GraphQL работал, над мемом не смеется.

Решение выглядит по-джуниорски, но у GrpahQL были веские причины сделать именно так.

Прохладная былина как не надо
В Проде перестал отвечать один из сторонних сервисов, возвращающий квитанции. Точнее отвечал HTTP 400 Кодом. Пошли к разработчикам сервиса выяснять. Было несколько версий:
— Такой квитанции нет и никогда не было
— Квитанция есть, но связанные с ней сущности не нашлись
— Нам не хватает прав, чтобы получить эту квитанцию, и сервис делает вид, что её нет
— Изменился URL запроса квитанции

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

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

А как в GraphQL
1. Если запрос дошел до endpoint’а, в любом случае вернется HTTP 200 и один из ответов, прописанных в схеме. Например, Receipt | ReceiptNotFound | NotEnoughPermissions.
2. Вернулось что-то отличное от 200 — ищи проблему в инфраструктуре.

Что это даёт:
— Клиенту не надо гадать, какую ошибку вернёт сервер на конкретный запрос. Все прописано в схеме.
— Невозможно спутать ошибку бизнес-логики с инфраструктурной.
— Не нужно обсуждать всей командой, какой код ответа использовать для бизнес-ошибок: “I am Teapot” или что-то более традиционное.

Если у вас нет GraphQL и публичный API
— Выберите какой-нибудь разумный код для ошибок бизнес-логики.
— Никогда не возвращайте 200 и подробности в теле. Разработчики проверят, что вернулся 200 и посчитают, что всё хорошо.
— Снабжайте ответ подробностями: что произошло и как это исправить.

Делайте хорошо. А плохо не делайте. Мир вам.

Кстати, какой HTTP статус вы используете для ошибок бизнес-логики?

Внимание, друзья! Инсайдерская новость для всех, кто стремится преуспеть на собеседованиях!

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

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

В программе курса:
🔹 Мастерство самопрезентации и составления резюме – уроки у лучших, ведь кто, как не индусы, знают эту тему лучше?
🔹 Секреты прохождения кодинг-интервью, чтобы сделать их менее стрессовыми
🔹 Полезные советы по системному проектированию
🔹 Как успешно пройти проверку на «культурную совместимость» с компанией
🔹 Искусство торговли за лучший оффер
🔹 Как определить, подходит ли вам компания и ее культура
🔹 Советы по карьере

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

Задачка на гибкость ума #1.

Мы разрабатываем финансовое приложение, хранящее номер кредитной карты.

Как бы вы гарантировали что номер кредитной карты не покинет пределы процесса (не попадет в логи, не будет отправлен в брокер сообщений, не будет сохранен в открытом виде в БД и т.д.) ?

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

Мы разрабатываем финансовое приложение, хранящее номер кредитной карты. Аналог PayPal
Как бы вы гарантировали что номер кредитной карты не попадет в логи?

Вот что я ответил на собеседовании:
⁃ Нельзя фокусироваться только на бекенде, нужно рассмотреть весь путь карты от веб-браузера и до БД.

⁃ Как можно раньше в приложении обернуть Номер Карты в объект CardNumber, у которого нет метода getCardNumber(): String. Но нам же его надо будет положить в базу данных, поэтому создадим getEncryptedCardNumber().

- Не забываем переопределить`toString()` чтобы он возвращал, что-то типа 4565-****-****-**** Теперь можно отдавать Джуну логировать.

⁃ В базе данных храним номер карты зашифрованным (шифруем на ключ пользователя или сервера — отдельная дискуссия)

⁃ Когда создаем инстанс CardNumber(cardNumber: String) то сразу же шифруем номер карты, и не храним его в открытом виде, чтобы ни случайный StackTrace нас не выдал ни Дамп памяти

⁃ Сканируем все логи ищя паттерн кредитной карты. Это и логи nginx, и балансировщиков и логов приложения и пр.

⁃ Сканируем логи тестов при сборке. Нашли номер кредитки — роняем билд

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

Чем старше я становлюсь, тем меньше у меня требований к программистам. Но больше к лидам…

Сегодня я проводил техническое собеседование в Thoughtworks с парнем, у которого 2 года опыта.

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

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

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

Но вот еще лет 5-7 назад я бы его гонял и в хвост и в гриву. А вы замечаете за собой похожее?

Ещё один важный критерий хорошего программиста: желание разбираться в предметной области.

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

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

Вышел Thoughtworks Technology Radar #30

105 пунктов и 4 главные темы:

Искусственный интеллект в помощь разработчикам. GitHub Copilot, Codium AI, , Aider и Continue оказывают влияние на каждый аспект жизненного цикла разработки ПО.

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

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

Архитектурные паттерн для LLMs (Больших языковых моделей). Казалось бы только появились эти ваши Chat-GPT и прочее, а уже есть гайдлайны по архитектуре.

Скачать радар #30

Не забудьте репостнуть коллегам!

Случилось то, что неизбежно происходит с каждым энтузиастом эргономичного рабочего места — я обзавёлся сплит клавиатурой, а конкретнее — ZSA Moonlander. Эта идеальная игрушка для гика помогает от боли в локтевом нерве и причиняет иную боль. Давайте по порядку.

Преимущества

Слои раскладки. Все сплиты глубоко кастомизируемы, а потому вам больше не потребуется ломать пальцы на шорткатах в четыре кнопки. Настраиваете слои раскладки и получаете, например, такое:
— Hold T — открыть новую вкладку в браузере
— Hold W — закрыть текущую вкладку
— Отдельная клавиша на скобки (), чтобы не зажимать Shift
— Отдельная клавиша $, чтобы ещё быстрее набирать $foo = $bar
— Свой слой макросов для Idea, чтобы не упражняться в йоге для пальцев, пытаясь быстро выжать ⌥+⌘+L одной левой

Можно настраивать раскладки всё свободное время. Что может быть лучше, чем сидеть по вечерам и раскидывать по слоям скобки и макросы, ощущая интеллектуальное превосходство над ~98,51% населения планеты?

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


Как клавиатура делает больно

Производитель честно предупреждает, что первый месяц будет мучительно больно
— Скорость печати показала отрицательный рост. Было 60 слов в минуту, стало 15
— Новый ZSA Moonlander стоит под 400 $, но я купил БУ за полцены
— Придётся покупать вторую домой. Говорят, если привыкнуть, на обычной уже работать не хочется

Как я докатился до этого

Раньше я жил как нормальный человек, но потом нашёл на сингапурской свалке кресло Herman Miller Embody, которое в магазине стоит полторы тысячи американских долларов. Находка положила начало моему пути эргономиста. Я стал сидеть прямо, с локтями на подлокотниках и ладонями на клавиатуре. Но с обычной это оказалось неудобно, поэтому я обзавёлся сплитом. Через месяц напишу об ощущениях и результатах.

Мы с @slobodator заключили джентльменское пари на 50 евро: смогу ли я довести до конца обучение слепой 10-пальцевой печати или брошу это занятие и вернусь к старой доброй традиции печатать 4,5 пальцами.
Андрей ставит на то, что я брошу!

Срок: 2 месяца
Минимальна скорость печати: 150 зн\мин

Пока я полон оптимизма и новая клавиатура подпитывает меня.
Вернусь к вам через 2 месяца 😎

Буквально мы с Серёжей

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

Рассмотрим на примере. Представим что у нас есть вот такой класс:

class Disease {
 var confirmed: Confirmed
}

enum class Confirmed {
 YES, NO, NOT_SPECIFIED
}

Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
 // какие-то проверки
 this.confirmed = c
}

У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

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

Правильнее сделать примерно так:

fun confirm(){
 // какие-то проверки
 this.confirmed = Confirmed.YES
}

fun decline(){
 // какие-то проверки
 this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES

Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

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

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

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

Можно подумать, что так делают только джуны, но нет. Так пишут и солидные дядьки с бородой.

И речь не об энтитях, что мы сохраняем в базу данных, а о модулях в принципе. Если это библиотека, значит, ей будет невозможно пользоваться без предварительного изучения внутренностей. Если что-то спрятанное за интерфейсом, придётся найти реализации и смотреть, в каком порядке что вызывать. В микросервисах — выяснять, на каком стеке он сделан и какая СУБД пользуется.

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

Благотворность низкой связанности, на наш взгляд, справедлива и для внутреннего дизайна. Потому как о какой производительности мы можем говорить, если у нас всё знает про всё?

В каждой шутке есть доля шутки

А теперь серьезно. Делать сложные системы — сложно, и всё тут. Нет никакого волшебного фреймворка, паттерна или базы данных, которая сама по себе сделает ваш код поддерживаемым, мягким и шелковистым.

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

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

Хороших выходных!

Когда ты играющий тренер программирующий тимлид

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

Да, говорит, парное программирование повышает качество кода. Но мы этого добиваемся, введя двойное код-ревью.
Я спрашиваю: и сколько времени вы закладываете на ревью кода и правки после ревью?
Столько же, говорит, сколько и на первоначальный кодинг фичи!

И пока я не нашёл листочек, не порвал его на две части и не показал ему наглядно, что даже по его критериям парное программирование не станет дороже, он не мог этот факт принять.

А в реальности я уверен, что процесс ещё и ускорится, так как разработчикам не придётся переключать контекст со своей задачи на "чужую" и обратно.

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