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

Мы разрабатываем финансовое приложение, хранящее номер кредитной карты. Аналог PayPal Как бы вы гарантировали что номер кредитной карты не попадет в логи? Вот что я ответил на собеседовании: ⁃ Нельзя фокусироваться только на бекенде, нужно рассмотреть весь путь карты от веб-браузера и до БД. ⁃ Как можно раньше в приложении обернуть Номер Карты в объект CardNumber, у которого нет метода getCardNumber(): String. Но нам же его надо будет положить в базу данных, поэтому создадим getEncryptedCardNumber(). - Не забываем переопределить`toString()` чтобы он возвращал, что-то типа 4565-****-****-**** Теперь можно отдавать Джуну логировать. ⁃ В базе данных храним номер карты зашифрованным (шифруем на ключ пользователя или сервера — отдельная дискуссия) ⁃ Когда создаем инстанс CardNumber(cardNumber: String) то сразу же шифруем номер карты, и не храним его в открытом виде, чтобы ни случайный StackTrace нас не выдал ни Дамп памяти ⁃ Сканируем все логи ищя паттерн кредитной карты. Это и логи nginx, и балансировщиков и логов приложения и пр. ⁃ Сканируем логи тестов при сборке. Нашли номер кредитки — роняем билд ⁃ Но все равно остается опасность, что несмотря на то что мы спрятали номер карты как можно раньше в нашем приложении, он будет залогирован где-то на ранних этапах, типа балансировщиков. Поэтому можно предложить шифровать номер карты сразу на клиенте, используя публичный ключ сервера, и прямо в таком виде сохранять его в БД. И мы гарантируем что на всем пути от веб-браузера и до БД номер карты не попадет в открытом виде ни в какие логи.

Задачка на гибкость ума #1. Мы разрабатываем финансовое приложение, хранящее номер кредитной карты. Как бы вы гарантировали что номер кредитной карты не покинет пределы процесса (не попадет в логи, не будет отправлен в брокер сообщений, не будет сохранен в открытом виде в БД и т.д.) ? Эту задачку мне задали на реальном собеседовании. И мне она показалась интересной для брейншторма. Поделитесь что бы вы ответили в комментариях. А следующим постом я опубликую что ответил я

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

Кто с 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. 👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.