State of Developer Ecosystem

Подъехали результаты большого ежегодного исследования разработчиков от JetBrains.

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

Если для китайцев главное не потерять лицо, то для американцев — не оказаться вторым.

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

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

Первый матч команда выиграла, но во втором проиграла. Шансы на выход в финал стали призрачными и наш тренер уехал домой.

Выводы. Если вы работаете в международной компании, и уж тем более руководителем, учитывайте менталитет.

Хакатон с чествованием победителей сильно взбодрит американцев. Но азиаты просто не поймут, зачем это всё. А немцы вообще не придут, потому что рабочий день закончен.

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

Test-driven Development (TDD), не замедляет вас.

Он делает вас быстрее!.

Люди говорят, что TDD да и даже написание тестов занимает много времени, потому что нам приходится писать много тестов.

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

Разработчики часто забывают учитывать все часы, потраченные на отладку, исправление дефектов и поддержку не протестированного кода.

Хорошее тестовое покрытие устраняет все эти потери, экономя огромное количество времени и нервов.

Тесты не дорого, Исправлять одни и те же ошибки снова и снова Дорого.

P.S. Лично мне нравится код писать, а не в формочки тыкать. А Вам?

А мы по-прежнему ищем ведущего разработчика)

https://spb.hh.ru/vacancy/90016905

Кто такой CTO, что он умеет и как ему живется (не очень)

Ютуб подкинул видео Simon Raik-Allen о позиции CTO — Chief Technical Officer или Технический директор.

Краткие выводы:

1. CTO — ещё более несчастное животное, чем тимлид. Ему нужно усидеть одной задницей на трёх стульях между продавцами, Большими Боссами (CEO) и инженерами (VP of Engineering).

2. Чтобы быть CTO, нужно понимать бизнес, шарить в технологиях и погонять разрабов, чтобы красили забор в срок.

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

Ролик на Ютубе: https://www.youtube.com/watch?v=alQzU0Uob5Y

Мы с Серёжей постоянно нудим, что писать тесты нормально и здорово для всего, кроме разве что совсем примитивных вещей типа геттера/сеттера.

Есть ещё одна вещь, которой вроде не нужны тесты — ин-мемори хранилище.

Это паттерн Fake, который позволяет нам заменить весь data access layer с базой данных на легковесное хранилище в памяти, часто реализуемое на какой-нибудь HashMap. В прод такое, конечно, не идёт, но чтобы показать прототип пользователям и заказчикам годится и сильно экономит время. Так вот, код в этом случае выглядит максимально примитивно:

fun save(e: Entity) {
storage[e.id] = entity
}

или

fun find(id: EntityId) = storage[id]

Кажется, что тут ошибиться негде, но даже в такой фигне я делаю ошибки. Недавний рекорд — 3 ошибки на 3 строки кода. Перепутал в фильтре not, > и < и забыл смержить результаты. Пришлось три раза передеплоивать кластер и напрягать мозговину, пока не нашёл. С тестами на это ушло бы меньше времени и нервов.

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

В общем, писать тесты нужно. Не написал тест — считай, что не написал код.

Ребята, есть тут кто тесты не пишет принципиально?

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

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

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

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

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

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

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

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

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

Тесты для слоёнки писать было сложно и занудно. Зато, когда QA находили баг и я лез в глубины бэка искать его причины, погонщик спокойно спрашивал:

— А ты написал тест? Если написал — сиди ровно.

И в 95% случаев он оказывался прав: баги находились где угодно, но только не на бекенде.

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

Мораль. Мы, конечно же, ни к чему не призываем. Каждый сам выбирает, спать ему по ночам после релиза или нет.

Но если у тебя есть тесты и нормальный 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 назад я бы его гонял и в хвост и в гриву. А вы замечаете за собой похожее?