StringConcat - разработка без боли и сожалений

Кто с 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 статус вы используете для ошибок бизнес-логики?

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

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

Когда-то я работал в одной небольшой компании. Писали сложную слоёную штуковину с десятками таблиц в БД и кудрявой бизнес-логикой. Над нами стоял технический погонщик, который принуждал всех писать тесты на каждый метод сервиса. Тесты для слоёнки писать было сложно и занудно. Зато, когда QA находили баг и я лез в глубины бэка искать его причины, погонщик спокойно спрашивал: — А ты написал тест? Если написал — сиди ровно. И в 95% случаев он оказывался прав: баги находились где угодно, но только не на бекенде. Много лет спустя я запускал другой проект, в котором пирамиду тестирования мы построили изначально. Приготовились к двум ночам дебага, настроили связи между микросервисами, дёрнули рубильник… и оно просто заработало. Коллеги, которые не строили пирамид раньше, ходили растерянные по офису и не верили, что оно дышит и сегодня ночью можно спокойно спать. Мораль. Мы, конечно же, ни к чему не призываем. Каждый сам выбирает, спать ему по ночам после релиза или нет.

Из внутреннего: однажды у тимлида

В комментариях к посту товарищ Roma Jadrovski написал верное замечание. Если сохранить сущность, как это указано у нас, а затем изменить её состояние методом, в хранилище окажется уже как бы не совсем она. То есть:

// В одном конце вселенной 
entity.setField(value1)
repo.save(entity)

// Во другом конце вселенной
entity.setField(value2)

// В третьем конце вселенной
entity = repo.get(id)
entity.getField() == value1 // false ???

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

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

Мы с Серёжей постоянно нудим, что писать тесты нормально и здорово для всего, кроме разве что совсем примитивных вещей типа геттера/сеттера. Есть ещё одна вещь, которой вроде не нужны тесты — ин-мемори хранилище. Это паттерн Fake, который позволяет нам заменить весь data access layer с базой данных на легковесное хранилище в памяти, часто реализуемое на какой-нибудь HashMap. В прод такое, конечно, не идёт, но чтобы показать прототип пользователям и заказчикам годится и сильно экономит время. Так вот, код в этом случае выглядит максимально примитивно: fun save(e: Entity) { storage[e.id] = entity } или fun find(id: EntityId) = storage[id] Кажется, что тут ошибиться негде, но даже в такой фигне я делаю ошибки. Недавний рекорд — 3 ошибки на 3 строки кода. Перепутал в фильтре not, > и < и забыл смержить результаты. Пришлось три раза передеплоивать кластер и напрягать мозговину, пока не нашёл. С тестами на это ушло бы меньше времени и нервов. Поэтому я не одобряю, когда забивают на тесты, например, в контроллерах. Пусть там иногда совсем нет логики, зато есть вагон спринговых аннотаций. За их обработку отвечают тёмные электрические силы, отчего они иногда работают по неочевидным правилам. Ну и нельзя исключать тупые опечатки в коде. В общем, писать тесты нужно. Не написал тест — считай, что не написал код.

Кто такой CTO, что он умеет и как ему живется (не очень) Ютуб подкинул видео Simon Raik-Allen о позиции CTO — Chief Technical Officer или Технический директор. Краткие выводы: 1. CTO — ещё более несчастное животное, чем тимлид. Ему нужно усидеть одной задницей на трёх стульях между продавцами, Большими Боссами (CEO) и инженерами (VP of Engineering). 2. Чтобы быть CTO, нужно понимать бизнес, шарить в технологиях и погонять разрабов, чтобы красили забор в срок. 3. Видеть общую картину, контекст, подтекст и всё прочее, что от разработчиков обычно ускользает, и чётко прикидывать цену любого решения в долгосрочной перспективе. Например, решение переписать монолит на микросервис может привести к фиаско и стоить бизнесу слишком дорого, а может, и наоборот. Ролик на Ютубе: https://www.youtube.com/watch?v=alQzU0Uob5Y

А мы по прежнему ищем ведущего разработчика) https://spb.hh.ru/vacancy/90016905

Test-driven Development (TDD), не замедляет вас. Он делает вас быстрее!. Люди говорят, что TDD да и даже написание тестов занимает много времени, потому что нам приходится писать много тестов. Если у вас нет времени на написание тестов, это значит у вас есть время на: • отладку вашего кода • исправление ошибок на продакшене • исправление сломанных CI/CD пайплайнов • постоянный запуск вашего приложения вручную • ручной ввод тестовых данных снова и снова Разработчики часто забывают учитывать все часы, потраченные на отладку, исправление дефектов и поддержку не протестированного кода. Хорошее тестовое покрытие устраняет все эти потери, экономя огромное количество времени и нервов. Тесты не дорого, Исправлять одни и те же ошибки снова и снова Дорого. P.S. Лично мне нравится код писать, а не в формочки тыкать. А Вам?

Если для китайцев главное не потерять лицо, то для американцев — не оказаться вторым. Пример. Мой сын участвовал в местном чемпионате по дворовому футболу. Каждой команде выделили родителя — тренера. Команде моего сына достался американец с ролексом, белыми зубами, в общем, победитель по жизни. На брифинге организаторы попросили родителей не давить на детей, главное не победа, а повеселится и поучаствовать. Я вначале удивился: чего это они нагнетают, моим родным китайцам спортивные успехи детей индифферентны, главное, чтобы хорошо учились. Но наш тренер тут же закричал, что его команда пришла побеждать и точка. Первый матч команда выиграла, но во втором проиграла. Шансы на выход в финал стали призрачными и наш тренер уехал домой. Выводы. Если вы работаете в международной компании, и уж тем более руководителем, учитывайте менталитет. Хакатон с чествованием победителей сильно взбодрит американцев. Но азиаты просто не поймут, зачем это всё. А немцы вообще не придут, потому что рабочий день закончен. Или, скажем, тестировщики начнут играть с разработчиками в футбол, перекидывая задачи из DEV в QA и обратно. Вы решите самого активного футболиста повесить на стену позора. Американцев и китайцев это мотивирует меньше косячить, одним нельзя быть лузерами, а другим важно сохранить лицо. А вот российские программисты демотивируются и будут на кухне обсуждать вашу тиранию и планы по слому системы. Но это, конечно, моё субъективное мнение. Если у вас другое — велкам ломать копья в комментах.

State of Developer Ecosystem Подъехали результаты большого ежегодного исследования разработчиков от JetBrains. 👉77% разработчиков используют ChatGPT, а 46% – CoPilot. Самый частый сценарий – задавать вопросы общего характера про программирование. 👉Выгорание за свою карьеру переживали 73% разработчиков. 👉Для 58% первым шагом к обучению программированию было формальное образование. На втором месте – книги, но уже только 10%. 👉Только у 63% разработчиков в проекте есть юнит тесты. 👉Среди языков программирования единственным растущим остался Rust. 👉Три самых высокооплачиваемых языка: Scala, Go, Kotlin. 👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.

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

Правильной и неправильной архитектур не бывает, зато бывают «дорогие» — поддержание которых на плаву потребует больше усилий, чем экономит их использование. Чтобы понять, не стала ли архитектура проекта «дорогой», пройдите по опроснику. Для каждого вида свой набор вопросов. Монолитная Достаточно ли команда инвестировала в модуляризацию? Какое выбрано направление зависимостей между этими модулями? Не предполагается ли наплыв пары миллиардов пользователей в ближайшее время? Микросервисная Может ли команда независимо деплоить микросервисы? Если один из микросервисов ушёл отдохнуть, смогут ли оставшиеся продолжить работу? Достаточно ли команда вложила в devops-практики или таскает исполняемые файлы на прод руками? Подтверждено ли автоматическим тестированием совместимость микросервисов? Достаточно ли команда инвестировала в мониторинг? Слоеная Договорились ли вы с командой, какой вариант слоёнки вы используете: открытые или закрытые слои, каково направление зависимостей, особенно между доменом и data access layer. Какие слои, собственно, у вас есть? Куда вы положили слои, выбивающиеся из стройного ряда API Layer, Business layer, Data Access Layer? Например, где лежит взаимодействие с другими сервисами? Уверены ли вы, что приложение не слипается в big ball of mud и вы хорошо отделили один слой от другого? Hexagonal\Clean Architecture Вся ли команда понимает принципы этой архитектуры и почему она выбрана для проекта? Достаточно ли вы изолировали слои и контролируете направление зависимостей между ними? Если кто-то притащит в домен половину вашего любимого фреймворка, то через сколько часов или дней вы это заметите? Event-Driven architecture Как вы понимаете, отвечает ли код бизнес-процессам или нет? Как вы ищете проблему в коде, когда поняли, что что-то идет не так? Может ли текущая версия любого сервиса запроцессить event, пришедший ей 2 года назад? Те же вопросы стоит задать микросервисной архитектуре, только с лампой в лицо опрашиваемому, поскольку цена ошибки тут много выше. А какие вопросы вы бы задали, светя лампой в лицо опрашиваемому тимлиду\архитектору?

Разыскивается Backend Lead (Kotlin) Воспользуюсь служебным положением и поделюсь вакансией. Ищу себе в команду бекенд-лида со знанием котлина, который разделяет те ценности, о которых мы тут вот уже несколько лет рассказываем. Кому интересно, оставляйте отклик на HH.

Как IT-специалисту вырасти до $360.000 в год? Мы открыли доступ к лекции о лучших инженерных практиках Thoughtworks из нашего основного курса. Знания этих практик увеличивают стоимость специалиста на рынке до 30.000 $ в месяц. В ролике к этому посту Серёжа подробно рассказывает, откуда эта цифра и как всё взаимосвязано. Лекция откроется сразу после прохождения опроса. Он займёт 5 минут, а нам поможет заточить курсы под ваши потребности и чаще радовать вас качественным контентом :3 Опрос и лекция: https://forms.gle/RxjaKxMMdQkVsEF98