بسم الله الرحمن الرحيم
السلام عليكم ورحمة الله وبركاته
🚀 Запускаю телеграм-канал на тему бэкенд разработки
🗓 Планирую делиться контентом как на общие темы бэкенда, так и в частности на темы языка Go. Основной упор будет сделан на объяснение простым языком, потому что сложный я не знаю чтобы было понятнее большинству читателей.
🤲 Прошу АллахIа облегчить мне это дело и заложить для меня в нем благо в обоих мирах
И вся хвала принадлежит только АллахIу!

Немного о себе.

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

Спустя год, когда пора было уже выпускаться из ВУЗа и определяться с будущим, решил, что тестировать достаточно и пора писать код самому.

В названии было сказано, что будет «немного», поэтому перейду сразу к настоящему времени. А если будет спрос, как-нибудь распишу подробнее про свой маршрут.

Что мы имеем на данный момент:
- 7 лет в IT
- из них почти 5 на бэкенде
- опыт работы как в мелких, так и в крупных компаниях
- на данный момент работаю в лучшей IT компании в России (по моей субъективной оценке)

Вполне достаточно, чтобы начать делиться опытом, согласны?

Джуны никому не нужны?

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

"Выходят некоторые статьи, якобы, что вакансии программистов упали в России, и что джуны никому не нужны"

Об этом кричат отовсюду сколько себя помню в этой сфере, независимо от обстановки в России. По ощущениям, обычно это пессимистичные джуны сами же и делают. Мое мнение: это не стоит твоего внимания.

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

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

P. S.
Как минимум в 2х компаниях, где я работал, была практика найма и обучения джунов. Что-то мне подсказывает, что это определенная бизнес-модель, которая себя оправдывает. Не думаю, что такие компании перевелись.

السلام عليكم ورحمة الله وبركاته

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

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

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

Подумайте за меня и отпишитесь 👇

Проблемы на проде.

На часах 2:00, жду пока катится уже шестой по счету деплой с попыткой поправить продакшэн, в общем есть время поделиться размышлениями.

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

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

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

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

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

Но радость была недолгой, потому что я стал наблюдать дальше и понял, что воркер не случайно завис в первый раз. Была какая-то причина, рестарт ее естественно не устранил, и воркер завис повторно. А коллеги уже разошлись.

Спустя часов 6 одинокого расследования, я наконец-то нашел причину, хвала АллахIу. Я все не мог понять, как моя несчастная ветка привела к таким проблемам, при том, что я ее тут же откатил. На деле оказалось все куда хитрее.

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

Мораль:
- Бэкенд это нелегко, но интересно
- Не нужно паниковать, говори спокойно о проблеме, а там на деле может окажется что и косяк то не твой
- Если косяк коллеги, не торопись на это указывать, может следующий будет твой

NFR.

NFR расшифровывается как Non-functional Requirements, то есть нефункциональные требования. Может показаться сложным, но если вдуматься, название хорошо отражает суть.

Зайдём чуть издалека. Мы как программисты пишем определённые программы. Обычно у этих программ есть заказчик, будь то менеджер в компании, друг дяди или даже мы сами. И у этого заказчика справедливо бывают какие-то требования к необходимой ему системе, то есть ожидания, как она должна работать.

Есть функциональные требования - ожидания от функций системы. Например, к телефону функциональное требование - чтобы он звонил или имел камеру. К твоему бэкенду может быть требование возможности авторизовываться или получать время в разных таймзонах.

И есть нефункциональные требования (они же NFR), к которым, исходя из названия, можно отнести все остальные ожидания. Если с функциями все понятно, то что же тогда там за ожидания от НЕ функций, спросишь ты? А их оказывается может быть очень много.

Короткий перечень показателей, по которым могут быть NFR:
- Latency / Response Time - время ответа. То, за сколько твой сервер отвечает на запрос. Я, как заказчик, хочу узнавать время в Мекке за 200мс, а твоему серверу на подсчеты нужно 2 секунды - не пойдёт, прогиб NFR не засчитан.
- RPS (requests per second) - количество запросов в секунду. Твой сервер может отлично работать, когда его тестирует заказчик, но будет ли он работать, когда им начнут одновременно пользоваться тысячи людей?
- Errors Rate - процент ошибочных ответов. Если на каждый пятый (или даже сотый) запрос я получаю вместо результата неизвестную ошибку, это едва ли можно назвать стабильно работающей системой. Я (опять же как заказчик) хочу минимальное количество непредвиденных ошибок, например не больше 0,01% от общего количества запросов.

Это довольно краткий экскурс в тему, дабы было общее понимание, что это такое и зачем оно нужно. Надеюсь, было полезно. А ты слышал раньше про NFR?