<rmcreative>

Последний пост из недели backendsecret. Бизнес, ошибки, карьера, бэкапы, тимлидство, баги и полезные мелочи.

Реалии бизнеса

У бизнеса (в особенности это выражено у продуктовых компаний) всё упирается в деньги. Если более кривое решение стоит дешевле и не сильно повредит в долгосрочной перспективе, его и будут делать.

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

Понимание «кривого» у бизнеса и у разработчиков расходится.

Например, красиво — это когда golang, микросервисы, Kubernetes, авто-масштабирование в AWS, 100% покрытие юнит-тестами, на фронте Angular и взаимодействие через grpc. А то, что надо было интернет-магазин с 10-ю покупками в день сделать — это разработчику бывает не интересно.

Свои грабли

Давным-давно в одном тогда ещё не очень крупном проекте использовали для отладки продакшн-базу. Удобно было на реальных данных. Ввели рекуррентную оплату, насохраняли кредиток. В одно прекрасное утро сидели мы искали багу во времени оплаты. Раз 5 пробежали дебаггером…

Ожидаемо закончилось снятием денег со многих клиентов пять раз. Клиентов были тогда ещё не миллионы, но сотни тысяч были. Менеджеры с саппортом проблему разрулили, насколько помню, за 4+ месяца и с потерей части клиентов.

Сейчас это очевидно, но на старте моей карьеры бывало и не такое… очень приличную часть опыта я набрал на таких вот случаях.

Факапы бывают разные. В каждом случае необходимо разбираться. В одном я точно уверен: если повторяется снова и снова — это уже не обучение и совершающего такое надо карать.

Про карьеру

Если хотите сверх-быстро развиваться, старайтесь устраиваться в проекты, где вы наименее опытный.

Про бэкапы

Нельзя считать что у вас есть бэкап, если вы из него ни разу не пробовали восстановить систему.

Про тимлидство

Теория разбитых окон прекрасно применима к проектам. Не оставляйте мусор. Удаляйте сразу.

Всегда ищите возможности для автоматизации. Рутина скучна и заниматься ей — тратить время впустую.

«Джедайские техники» — книга про то, как жить когда сделать нужно слишком много. Чтиво не самое приятное потому что плотная каша (читается медленно, необходимо делать перерывы для осмысления), но полезное. Главное дочитывать до конца. В конце как раз про основную ошибку — предпочтение рабочего личному.

Про баги

«Магии» в разработке не бывает. До причин «магического» всегда можно докопаться. Если расследование зашло в тупик:

1. Используйте бинарный поиск.
2. Составьте баг-репорт с подробным описанием (даже если работаете один).
3. Покажите репорт коллегам. Попросите высказать мысли.

Сложные баги:

1. Большинство проблем конкурентного доступа под нагрузкой.
2. Баги в интерпретаторе или компиляторе.
3. Баги, которые воспроизводятся только на проде или только в определённой среде.
4. Баги в приложениях с потоками (я писал около года под Android).

Бинарный поиск работает и для поиска бага. Если не ясно где он и о чём, делим систему пополам, ищем в какой части из двух… ну и так далее.

Полезное

• Никогда не мог запомнить формат crontab. Смирился и пользуюсь https://crontab.guru/.
• yED — полезный бесплатный инструмент для рисования диаграмм.
• Если вы всё-ещё читаете логи прямо с сервера или получаете их почтой, попробуйте https://rollbar.com/ и https://sentry.io/ .

rollbar/sentry - это только про ошибки. Скидывать туда логи не надо. Это не замена ELK.

Когда похожая ошибка вылезает 1000 раз, тот же rollbar показывает что «была ошибка X», 1000 раз, вот последний. И выкидывает её наверх потому как, видно, важная.