Transcription
Я уже несколько лет работаю Java разработчиком в Финтехе и недавно вспоминал то время, когда как раз только сам обучался этой специальности и искал информацию о том, как, собственно, выглядит рабочий день программиста, какие задачи перед ним стоят. Потому что много было материалов про разницу там бэкэнда и фронтэнда, какой язык первый выбрать, а вот именно какие задачи будут стоять и справлюсь ли я с этими задачами и вообще в целом моё ли это.
Да, у многих такая мысль возникает на старте обучения, даже в конце обучения, перед выходом на первую работу много сомнений и непонятно, что, собственно, ждёт на рабочем месте, как будет выглядеть день. Видео таких и статей было не очень много. приходилось как-то по крупицам собирать информацию от коллег, знакомых, кто в этой сфере работает. Э, сейчас глянул, тоже как-то не особо много таких видео. Вот решил записать своё, поделиться своим опытом. Может, кому-то будет полезно. Кто-нибудь сравнит со своим опытом работы, что-нибудь напишет в комментариях. Буду рад почитать.
Значит, как всё обычно устроено. Вы приходите на проект, в команду, которая занимается, как правило, либо вот одним приложением, либо группой из нескольких приложений, из нескольких микросервисов, если они находятся вот в вашем ведении вашей команды. А обычно в команде 2-4 разработчика, максимум я встречал 10, но, как по мне, это уже многовато, потому что, во-первых, на ежедневных созвонах очень много времени тратится, пока каждый выскажется. Во-вторых, в целом начинается толкучка на проекте и путаница, потому что кто-то обязательно накосячит и много кто будет там пересекаться при работе с кодом, и придётся вот это всё разруливать. Это всё не очень удобно. А, но всё зависит, конечно, от продукта, от степени его важности, от его загруженности, ну, и от того, сколько людей нужно для того, чтобы этот продукт поддерживать.
Также в команде желательно, чтобы были тестировщики один или несколько. Количество будет зависеть от специфики работы. Я дальше об этом расскажу ещё. Также желательно присутствие аналитиков на проекте, которые общаются с руководством, с бизнесом. И бизнес-требования, которые требуются от приложения, переводят с русского языка на технический для того, чтобы составить разработчикам задание, что нужно, собственно, сделать. Ну и Teamлит - это ваш непосредственный будет руководитель, перед которым вы будете отчитываться каждый день на созвонах, который будет раздавать вам задачки и с которым в основном вы будете взаимодействовать по вопросам того, как у вас вообще идёт работа, сколько всего выполнено.
Есть ещё DevOps инженеры, но в наших реалиях их, как правило, дефицит. И специфика такая работы, что они обычно прикреплены к нескольким командам. и не участвуют в ежедневных созвонах. И прави, как правило, про них вспоминают только, когда что-то ломается.
И вот вы попадаете в вашу команду. На первом этапе, пока выдают все доступы, вам дают время немножечко привыкнуть к проекту, изучить кодовую базу, поразбираться. сразу же не будут загружать какими-то сложными задачами. Скорее всего, дадут какие-нибудь таски на написание тестов, что-то такое несложное. Ну, в целом, потому что даже опытные разработчики, когда приходят на большой, сложный проект, а на Джаве, если проекты старые, они, как правило, большие и сложные, то даже опытным разработчикам дают какое-то время, чтобы просто привыкнуть и прощупать код, потому что технологии хоть много где схожие, но стиль написания, архитектурные подходы, как вообще всё хранится и организовано, они могут сильно отличаться в зависимости от того, на какой проект вы попадёте.
Работать вы будете, скорее всего, с спринтами, то есть раз в 2 недели будете всей командой встречаться, и ваш руководитель будет раздавать всем задания на ближайшие 2 недели, в зависимости от того, кто сколько нагрузки может взять и кто насколько быстро работает. Ээ это всё тоже учитывается. И от вас потребуется только ежедневно быть на созвонах, отчитываться о статусе работы над своими задачами. И в целом это может продлиться от пары недель, даже там до месяца-двух вот этот ваш период раскачки, когда вы только вливаетесь в команду на проект. А так потом, когда вы уже в целом разберётесь в проекте и войдёте в рабочий режим, а-э, вам нужно будет каждый день только созваниваться с командой. И помимо этого иногда, а если какие-то задачи этого будут требовать, быть на связи в течение дня, допустим, там, с тестировщиками и с аналитиками при работе над какой-то конкретной задачей. У меня, честно говоря, бывают дни, когда те 10 секунд моей речи на дейли, которые я говорю - это единственные слова, которые вообще я на работе за весь день произношу.
Итак, представим, что вам дали задачку. А, как правило, это просто тикет в джире, который записан на ваше имя как исполнителя. Вы его открываете, смотрите, что-то написано в комментарии. Как правило, это ссылка на документацию. Если документация на проекте хорошая, а я считаю, что она должна быть не совсем даже подробная, как иногда этого требует, но какая-то минимальная, чтобы было объяснено, за что отвечают определённые места в коде, там методы, как чего работать, то есть это текстом желательно всё должно быть прописано. Обычно этим занимаются как раз аналитики. То есть аналитики сначала расписывают текстом, как это всё будет выглядеть. Потом разработчик превращает эти требования в код. А, и задача аналитиков также в будущем поддерживать актуальность этой документации. То есть, если какие-то доработки вносятся в код, то и в текстовом описании этого метода нужно тоже вносить эти правки. И в идеале в хорошем проекте документация всегда держится в актуальном виде. И вот как раз, когда вам дают тикет на разработку, а желательно, чтобы была ссылка именно на документацию, где написано, что там происходит.
Ваша задача будет после этого открыть среду разработки, открыть нужное приложение, в котором будут правки вноситься или несколько приложений, да, это может быть задача сквозная, которая затрагивает несколько микросервисов или библиотек. И нужно просто по описанию того, что в документации написано, найти в коде или несколько мест, где вам нужно сделать какие-то изменения. Вы создаёте в гите новую ветку. А вот дальше вы можете потратить разное количество сил и времени в зависимости от того, а задача какого уровня сложности вам попадётся. Я таких уровней для себя выделил пять и сейчас про них расскажу.
Первое, самое простое - это элементарная замена. То есть это переименовать какую-то переменную, заменить тип этой переменной, если это не особо зааффектит дальше там весь процесс выполнения программы. Это возможно добавить какое-то поле внутри джейсона, который приходит в ваше приложение и который нужно просто сохранить. То есть это минимальные изменения по логике, где от вас требуется просто, назовём это исправить опечатку. К примеру, бывают такие задачи, где просто там перепутана буква или там какое-нибудь число нужно поменять на другое, потому что оно в справочных там значениях просто его изменили аналитики. То есть в таких задачах самая сложная, на самом деле, часть и самая трудозатратная в том, что если кодовая база вам не знакома, то нужно по документации сориентироваться и найти это место в коде, чтобы там эту правку сделать. И возможно также подправить тесты, которые будут задеты вашим каким-то новым изменениям, потому что на весь код, как правило, в приложениях стараются писать тесты, обеспечивать высокую степень покрытия, там от 60, может быть, до 80 даже процентов. И если вы вносите изменения в код, который уже был покрыт тестами в этом приложении, то вам нужно просто внести эту правку и в тест тоже для того, чтобы там все тесты работали и всё собиралось.
Для таких задач также характерно то, что если вам достался хороший аналитик, который дольше вас на проекте, он может даже лучше знать примерно как работает приложение и даже подробно напишет, в каком месте что нужно поменять. И ваша задача просто быть его руками по сути и сделать правку, как бы взяв эту ответственность на свои плечи. Хотя иногда вы думаете, что зачем я здесь нужен, если это можно элементарно сделать даже ему самому. Ну и за вами остаётся ответственность за доработки и исправления в случае каких-то возникших дефектов. Даже с такой элементарной заменой всё равно, может быть, что-то заафектится и придётся что-то переделывать. А вообще, как правило, задачи такие очень простые. могут занять буквально там 5 минут непосредственно на замену одной или двух строк, а потом ещё там пару часов вы можете заниматься исправлением или даже написанием заново тестов, какими-то там проблемами с раскаткой и сборкой и так далее.
Следующий тип задач по сложности я выделил как несложная фича, но над которой надо всё-таки немножко подумать. То есть даже если вам аналитик очень хорошо напишет документацию и правильно даст ссылку на нужное место, а возможно, что всё равно вам придётся потратить чуть больше времени на то, чтобы вникнуть, что именно в методе происходит, потому что логика довольно часто бывает очень сложная. и просто найти место в коде, которое соответствует тому изменению, которое нужно сделать. Этого бывает недостаточно, потому что для изменения нужно понять, как целиком работает метод или связка из нескольких методов. И тогда нужно именно повчитываться в текст, возможно, как-то прогнать какие-то тесты в дебагере внутри приложения, чтобы понять, какое изменение нужно сделать. Ну, то есть сюда можно отнести какие-то даже простейшие новые развилки, пускай даже через if-else, которые вы добавляете, какой-то небольшой факторинг, а какое-то создание даже новых классов, интерфейсов для обработки. Это всё здесь может быть. То есть оно требует от вас просто того, чтобы чуть больше вникнуть именно в смысл работы метода. Но именно такие задачи как раз помогают вникнуть, а что у вас на проекте происходит в приложении, в продукте. И со временем у вас будет возникать всё меньше таких проблем, когда вы вообще не понимаете, что здесь написано, и уже так более углубившись в логику работы вашего приложения, можете более уверенно вносить какие-то правки, не тратя много сил на понимание именно документации.
На таких задачах также, как правило, возникает желание сделать какой-то, может быть, рефакторинг, то есть оптимизировать код, сделать его для потомков более там масштабируемее, аккуратнее и чище. Но это будет зависеть от того, сколько времени даётся на эту задачу, насколько она в приоритете и насколько вы быстро можете сообразить, как тут можно, по-другому что-то написать.
И здесь мы как раз переходим к следующему уровню задач, когда вам нужно не внести какую-то правку в существующий код, а написать новый, но вы это делаете на основе того, что в проекте уже было сделано до вас. То есть есть какая-то база кода или аналогичные методы, которые вам, по сути, иногда бывает достаточно просто скопировать и переделать под себя. А, либо уже готовы какие-то даже целые библиотеки, которые нужно просто к себе подключить и там присвоить нужные параметры. Такое обычно происходит, когда задачей занимался какой-то опытный разработчик изначально, и он по ходу написания новой э логики, он уже сразу же понимал, как сделать этот код более масштабируемым на будущее. То есть он закладывал во время написания в код то, что он может в будущем переиспользоваться. Поэтому он сразу его писал так, чтобы его было удобно переиспользовать будущим поколением. И м, как правило, это может быть либо какие-то просто абстрактные классы готовые, которые вам нужно расширить, или даже целые библиотеки, которые можно просто подключить, как я уже сказал, присвоить нужные параметры, там, может быть, что-то немножко поменять, модифицировать. и у вас всё уже сразу заработает. Тут я могу посоветовать книгу Чистый код, всем известную, потому что там действительно многие эти вещи описываются, и это помогает в работе.
Следующий уровень сложности - это когда вам нужно написать новый функционал, но аналогов на проекте ещё нет. То есть нужно писать что-то с нуля. Либо же сюда можно отнести задачи, которые требуют от вас в изучении каких-то прямо принципиально новых технологий, с которыми вы раньше не сталкивались. Ну или, скажем, классический пример, когда вам нужно, для оптимизации переписать нереактивный код на реактивный стек. И вот вы тоже с этим ещё не работали. И нужно вот как-то придумать, как старую логику перенести на новые рельсы. Но с ростом вашего опыта, с большим количеством таких прорешенных задач, как и в любом другом деле, вам становится со временем проще, потому что напрягшись сильно один раз, вы вновь вернувшись к этой теме, уже будете ощущать себя увереннее и сможете уже начать не с нуля, а с того места, скажем, на котором остановились, более уже углублённо вникая в технологию.
Сюда же я могу отнести вопросы, связанные с проработкой каких-то архитектурных решений, внедрение каких-то новых технических, фич, ну или, допустим, когда вам нужно сделать какую-то большую миграцию, скажем, старого кода из там распил монолита на микросервисы, да, классический. И когда в целом вы понимаете, как в приложении этот код работает, и у вас есть понимание, как это можно всё правильно декомпозировать, распилить. Здесь ключевой смысл в том, этого уровня сложности для меня, что вы как бы код пишите сами всё равно с нуля, и за вами остаётся право эпровизации и творчества. То есть какой подход выбрать, потому что вы, например, можете не строить какой-то космолёт со сложными технологиями, а можете сделать всё проще, а, может быть, даже в ущерб производительности, но просто потому, что вы знаете этот подход, он более стабилен, ну, и техническое задание не требует какой-то супер эффективности выполнения метода по времени там или памяти. А, и здесь вы как раз вольны выбрать то, что вам удобнее. И поэтому эти задачи хоть и сложные, но в целом всегда с ними можно справиться без проблем, потому что множество решений уже описаны на том же Стек Overflow или там есть примеры кода и прочее, и прочее.
И, наконец, самое сложное лично для меня - это когда нужно делать рефакторинг и копаться в старом чужом коде, возможно написанном много лет назад на каких-то уже не очень актуальных технологиях. Если этот код ещё распределён, его логика распределена между несколькими сервисами, если там нету тестов, если это всё интеграционно не протестировать, то есть не там нет возможности запустить и как-то пошагово посмотреть, что именно в в этом методе выполняется. И вот когда в такой метод нужно вносить какие-то глобальные изменения, когда даже возникает на каком-то этапе вопрос: "А может быть легче это всё вообще заново переписать?" Но вы понимаете, что времени у вас особо нету. И вот здесь как-то приходится делать либо костыли, либо прямо очень усердно работать какое-то время. Задачи такие могут, как правило, не совсем соответствовать документации, потому что, прошло много времени, там, может быть, что-то на внешней стороне, какие-то уже сервисы изменились, а внутри всё осталось прежним, но под новые реалии других взаимодействий с другими сервисами это всё не переписывалось. В общем, документация может быть просто устаревшая, и вы не сможете нормально найти по документации, что происходит в коде. Приходится во всём этом копаться, очень долго сидеть и потом, неделями, возможно, даже с ребятами из тестирования, из аналики сидеть и эту задачу раскапывать. Здесь как раз в этих задачах пригодится доставать ручку с листочком, всё это расписывать от руки логику работы. И вот это как раз задачи такого уровня, которые могут вам даже сниться в как в бреду, потому что вы слишком долго над ними думаете и потом постоянно они у вас в голове крутятся.
За всё время моей работы у меня таких задач было, наверное, процентов 20, может быть 25. На каких-то проектах просто их было больше, потому что кодовая база была старая, на каких-то в основном был новый код. Но такие задачи есть, к ним надо быть готовым. И как раз они проверяют вас как специалиста на то, насколько вы можете преодолевать фрустрацию, вот это вот чувство того, что вы упираетесь в тупик, вам нужно искать решение. Но, казалось бы, перепробовано уже всё. Также это зависит всё от того, насколько в целом компетентные разработчики в своё время писали этот код, насколько от вас требует сейчас быстро сделать какие-то изменения. И, кстати, все вот эти вопросы вы, когда перед тем, как придёте на проект, можете спокойно спрашивать как раз в тот момент, когда вас спрашивают в конце, есть ли какие-то вопросы. Вот можете всё это задать, чтобы примерно понимать, что вас ждёт, потому что кому-то нужен work-life balance, чтобы не сильно напрягаться, в целом плыть по течению без каких-то трудностей. Я знаю ребят также, кому специально хочется, чтобы были пожёстче задания. И таким образом они прокачиваются быстрее, как специалисты. Это действительно работает. Тут просто тоже надо знать меру в этом вопросе. Но это способ такой рабочий, чтобы быстро дорасти до хорошего квалифицированного спеца. Это вот браться вот за такие очень сложные задачи, которые требуют очень большой эмоциональной и умственной отдачи.
Здесь в заключении также хочу сказать, что за всё время работы, какая бы сложная задача передо мной не стояла, она всегда была решена. Возможно, я ещё не очень много просто сталкивался с какими-то проблемами, но в целом всегда через день или неделю решение приходит. Либо там через какие-то внешние источники, либо перечитывание ещё раз документации по технологии, либо просто общение с коллегами. Но в целом всегда ответ можно найти.
Итак, вы сделали задачу, дальше её предстоит протестировать. Есть два основных варианта сценария, как это может происходить на моей практике и практике моих знакомых.
Первый вариант: у вас есть возможность локально запустить приложение в среде разработки в вашей IDE с дебаггером, расставив брейкпоинты по коду, прямо построчно посмотреть, что происходит в вашем методе. То есть таким образом вы уже даже на этапе разработки можете сами себя проверять. не только делая это через юнит-тесты, а непосредственно запуская ваше приложение, там дёргая какой-то endpoint или вызывая какой-то триггер, который должен запустить метод. Вы можете посмотреть, что именно происходит по ходу выполнения, посмотреть на все состояния объектов во время этого. При таком варианте база данных, как правило, запускается локально в контейнере или на тестовом стенде у вас есть база данных, которой вы можете подключиться из той же среды разработки и вот на реальных данных фактически даже получать ответы от тех методов, которые вам хотелось бы проверить. Это очень удобно, потому что даёт возможность вам продебажить задачу самому, найти какие-то даже элементарные ошибки, прежде чем отдавать задачу в тестирование, чтобы не напрягать тестировщика лишний раз и предоставить ему уже, готовый, с вашей точки зрения, по крайней мере, код.
Второй вариант - это когда у вас настолько сложное и большое приложение, и такое встречается довольно часто, оно настолько сильно обросло интеграциями внешними, что запустить локально возможности его, к сожалению, нету. И никаких модулей для этого запуска тоже не сделали. То есть при таком варианте у вас полностью пропадает возможность запускать режим дебаггера в вашей IDE. Вы просто можете забыть про этот функционал. И вашим дебаггером, по сути, будет ваш тестировщик, который будет запускать метод на стенде. Нужно вам, в свою очередь раскидать будет логи, допустим, по всему коду по ходу выполнения, чтобы просто в логи, в консоль выводилось, что в вашем методе происходит. Вы это всё, значит, загружаете, тестировщик запускает, в влогах появляются какие-то ошибки, он вам их сообщает, вы говорите: "Понял" и идёте переделывать ваш метод. Поэтому при таком варианте, конечно же, может быть очень много ошибок, и процесс выполнения даже элементарных задач сильно растягивается, потому что то, что вы могли бы в дебагере там проверить, просто перезапустив приложение в среде разработки и быстренько найдя какой-нибудь там элементарный, не знаю, pointer, здесь вам приходится заниматься вот этой всей CI/CD раскаткой, запуском приложения на стенде и так далее. просто для того, чтобы увидеть какую-то элементарную ошибку.
Под сборкой, если что, я подразумеваю сборку вашего приложения с помощью Maven или Gradle. А раскатка - это то, что готовый образ мы как раз деплоим на какой-либо стенд, ну, в нашем примере тестовый, с помощью пайплайнов, которые девопсы прописывают в, допустим, там, в Jenkins или в TeamCity. При таком формате работы вы очень плотно работаете с тестировщиком, потому что, он вам может помогать, даже просто вот раскатывать образ на стенд и запускать метод, потому что тестировщик иногда лучше знает, что там именно нужно запустить. У меня есть опыт работы и с первым, и со вторым вариантом. Конечно же, более приемлемый первый, когда вы можете локально запустить приложение, но так бывает не всегда, и к этому надо быть готовым.
в защиту такого варианта могу сказать, что он для меня сродни поговорки: "Семь раз отмерь, один раз отрежь" или сродни той же плёночной фотографии, когда ты должен как бы более внимательно и аккуратно написать код, потому что понимаешь, что лишняя твоя невнимательность, какая-то элементарная ошибка растянет добавит новую итерацию и растянет это всё там на полчаса, может быть, даже также и в том, и в другом варианте хорошей практикой будет сразу же писать Тесты по ходу выполнения работы. Это и юнит-тесты, которые какие-то элементарные куски кода проверяют, и интеграционный. Там даже можно постараться всё грамотно замокать, чтобы имитировать как бы возвращаемые объекты, не подключаясь к реальным источникам. Вам в тестах обычно не нужно рассматривать все возможные корнеркейсы, так называемые. Это всё-таки работа тестировщика. вы для себя просто должны, ну, как минимум, проверить то, насколько ваш код, избегает тексту же нулпоинтеров, насколько там выполняется какая-нибуд, не знаю, защита от дурака так называемая. Ну, и в целом, что код не вызовет, допустим, сейчас или в дальнейшем какие-то просадки по производительности, если там будет, не знаю, много запросов или много каких-то объектов. То есть за этим тоже желательно следить, потому что тестировщик этого не увидит, а это может потом всплыть в какой-нибудь продакш среде, когда много пользователей придут в ваше приложение, и это будет отдельный дефект, который нужно будет править и разбирать, возможно, уже не вам.
Далее, когда вы протестировали функционал, когда тестировщик дал вам зелёный свет, а вам нужно вашу доработку влить из фичи ветки в develop ветку. Может, у кого-то называется по-другому, но смысл везде один и тот же. Под конец двухнедельного спринта, когда все остальные разработчики также подольют свои правки, в какой-то момент от Develop ветки отделяется релизная ветка и делается релиз. Релизы бывают с разной частотой, но, как правило, это один релиз за один спринт или один релиз за два спринта. Бывают продукты, которые нужно очень срочно катить, сделать MVP, чтобы побыстрее, побыстрее, и тогда релизится можно чаще. Но таких проектов скорее меньшинство.
Итак, чтобы влить ваши изменения в develop ветку, вам нужно спушать вашу фичу ветку в удалённый репозиторий. Это может быть Bitbucket, Gitlab, GitHub. Они все примерно одинаковые по функционалу. И хорошим тоном в компании является, когда прежде чем влить изменения, на них должен взглянуть какой-то другой, более опытный разработчик или, скажем, просто ваш коллега. Ну, просто, чтобы это была какая-то независимая оценка со стороны. Много где хватает одного, так называемого, approval задачи. Где-то нужно два, где-то нужен approval именно от профильного специалиста. Допустим, если вы, делаете изменения в каком-то SQL-скрипте, то нужен именно approval от человека, который очень хорошо разбирается в SQL, чтобы он подтвердил, что этот скрипт не вызовет проблем по производительности. Значит, вы создаёте этот pull request, туда приходит человек, который вас оценивает, и, может быть, напишет в комментариях, какие-то нужно внести вам правки. Может завязаться дискуссия, если вы хотите отстоять своё решение. Может быть, вы просто покорно согласитесь с мудростью более опытного коллеги. Но если вы вносите правки, то вы затем просто пушите один раз или несколько, в зависимости от того, как всё пройдёт. И после этого коллега даёт добро, вы вливаете изменения в develop ветку. И по сути на этом работа над задачей с вашей стороны закончена.
Потом только единственное, что во время какого-нибудь регрессионного тестирования, там может возникнуть новый дефект, который тестировщик не заметил во время того, как первый раз тестировал задачу. Тогда на вас будет заведён баг, как правило, по этой проблеме. И нужно будет также, как и в рамках фичи, только сделать изменение, чтобы этот баг исправить. Это может быть какое-то очень важное изменение, которое не будет ждать до следующего релиза, и нужно влить его вот прямо сейчас, пока от этого в продакш среде не пострадали пользователи. А так в целом э смысл всё равно остаётся точно такой же, как и при работе над фичей. То есть вы создаёте ветку, делаете какие-то изменения, тестируете их опять же и вливаете и отдаёте задачу дальше в продакшн.
Также здесь стоит сказать, что на этапе вливания вашей фичи или merge он называется, может возникнуть такая проблема, что вы с другим разработчиком работали примерно в схожих частях кода и где-то пересеклись. И тогда кто-то из вас первый зальёт свои изменения. А при попытке второго подлить то, что меняет, то, что поменял уже первый те же участки, возникнет merge конфликт, который нужно будет разрешить вот уже второму человеку. А такие конфликты бывают нечасто, если задачи правильно распределены и каждый занимается своей областью и особо не пересекаются. Но бывает, что-то нужно очень срочно сделать. И поэтому несколько человек бросают на примерно одни участки кода. И тогда конфликты бывают очень огромные. Бывает просто вот таких очень много, назовём их инфраструктурных проблем, да, которые связаны с проблемами нарушения Flow, с проблемами там с того, что-то там не дорелизилось, что-то не подлилось, что-то куда-то не вмёржилось и так далее. И вот вот эти проблемы тоже часто достаются на откуп разработчикам.
Самое главное, что вам нужно понять и с чем нужно будет свыкнуться - это то, что как бы это цинично не звучало, вам, как разработчику платят за то, что вы допускаете ошибки, и их же сами исправляете. То есть вы в своей работе будете постоянно сталкиваться с тем, что у вас что-то не получается. Для кого-то это не очень приемлемо, особенно для тех людей, у кого в целом всё по жизни получается легко, без усилий. Для них такая работа будет немного встрякой, потому что поначалу очень много чего не получается. Очень много, когда надо сидеть в тупике, не понимая, что вообще делать с этой проблемой. А идти к более опытным коллегам как-то не очень хочется, потому что интуитивно понимаешь, что проблема, скорее всего, детская и связано просто с твоим незнанием каких-то элементарных вещей. И вот здесь нужно себя просто приучить к тому, что огромный страшный красный стекрейс в консоли, сообщающий вам об ошибке - это не ваш враг, а ваш друг, который любезно сообщает, в каком месте именно что-то пошло не так. Вы можете найти это место, поправить проблему, запустить заново. Может быть, другая ошибка какая-то выскочит. Но вот вся работа это в целом обычно борьба вот с этими ошибками, которые вы сами же и делаете. Но опять же повторюсь, хорошо, что э наша специфика работы не в том, что мы получаем деньги за какой-то заказ, а потом бесплатно делаем правки, а нам, по сути, за эти правки и платят в рамках нашего рабочего времени.
Поначалу ситуации, когда у вас что-то не получается и всё горит красным, будут вас печалить, скорее всего. Но со временем их станет меньше, и вы сами тоже начнёте относиться к ним проще. Вы просто поймёте, что это, непосредственная часть вашей работы, и не будете уже так вздыхать каждый раз, когда что-то идёт не так или нервничать. вы будете просто относиться к этому как к эпостной части своей работы. Самое главное здесь не считать себя тупым, э потому что тупят абсолютно все. Даже очень опытные синьоры бывают неделями сидят над какой-то проблемой, не могут найти решения. Ну либо есть другая тактика, это наоборот признать свою тупость. Тут уж какой кто выберет подход. Но, к счастью, наш стек довольно консервативен, и надо помнить о том, что подавляющее большинство задач уже лет 10 как решены на Stack Overflow, то есть люди задолго до нас уже столкнулись со всеми типовыми проблемами, которые могут возникнуть. И вы это решение можете найти в чате GPT в том же, допустим, там 70%, мне кажется, тоже типовых проблем, а у юных разработчиков совсем уж под 100%. Я думаю, все вопросы будут закрываться.
Что тогда остаётся из трудностей? Только вот эти вот моменты, когда ты заходишь в очень сильный тупик, не знаешь, как из него выйти, и кажется, что ты реально перепробовал всё, потом ты можешь просто элементарно поспать. с утра проснуться и вот тебя осенило, кажется. Но здесь работает так, что просто так тебя не осенит. Но для этого нужно всё равно какое-то время эту задачу внутри себя попереваривать, обмозговать, то есть напрячься, чтобы там нейроны все соединились, связи появились, и тогда решение приходит. Кажется, что само, но на самом деле это результат как раз работы нашего мозга. Поговаривают даже, что в какой-то момент, когда разработчик уже за свою жизнь прорешал все возможные подобные простые задачи, ему становится скучно, и он, что называется, выгорает.
В целом это всё. Надеюсь, было полезно и интересно. Если какие-то вопросы, пишите, буду рад ответить. Может, потом ещё какое-нибудь видео запишу более подробное про какие-то конкретные аспекты. Всем пока. Yeah.