Для развития не обязательно, чтобы рядом был кто-то, кто может помочь в любом вопросе. Некоторым образом это даже плохо, когда есть кто-то, кто может исправить за тебя все твои косяки и помочь тебе самому найти информацию.
В ситуации, где ты один разработчик, очень важно не застрясть в "легасях". Для этого нужно соблюдать принцип 80 на 20. 80% - общий фокус на углубление знаний в конкретных технологиях, которые применяешь. 20% - поиск новых лучших практик и технологий, экспериментирование. Ряд хороших книг может с лихвой заменить старшего наставника. А рабочая обстановка - позволит взрастить мотивацию и самодостаточность.
Важно научиться не только заниматься фичами - выстроить такие процессы можно абсолютно везде. Хорошие компании понимают, что разработчик занимается фичами не 100% времени, в плохих компаниях нужно переоценивать задачи, занижать свой performance, чтобы оставалось время на решение проблем проекта и экспериментирование с подходами.
Если в компании даже нет agile можно взять простенькую доску trello и накидывать на нее задачи, ставить себе временные рамки, это позволит эффективнее тратить свое личное время.
Заголовок гласит про рост до Senior, а все пункты тянут от силы на чуть выше middle-1. Из Senior'ских советов разве что написать свою библиотеку, да и то очень преждевременно.
Ожидал увидеть что-нибудь из: - развивайте системное мышление, углубитесь в design-review, придумывайте архитектурные схемы, учитесь их представлять и детализировать; - собеседуйте людей, рефлексируйте и закрывайте обнаруженные пробелы в знаниях; - при изучении новых или даже уже известных вам технологий, старайтесь чаще "нырять в кротовью нору" - то есть копать до их внутреннего устройства, чем глубже - тем лучше (в идеале до процессорного уровня); - взваливайте на себя ответственность - чем больше, тем лучше - лидировать смешанную команду, организовывать митапы, проводить лекции, обсуждайте в том числе вопросы реализации backend-приложений; - читайте больше технической литературы, углубляйте знания паттернов проектирования; - эксперементируйте, придумывайте новые подходы, помогающий решать каждодневные задачи и просто писать качественный код; - объедините все свои достижения в свой собственный Framework / CMS; - контрибьютьте в OpenSource, не просто исправление опечаток, а доработки, исправления популярных библиотек, попутно впитывая архитектурные приемы используемые профессиональными разработчиками;
В какой-то момент вы перерастете "продуктовую разработку", вам захочется чего-то более прикладного, создавать технологии, а не применять их. И это у вас начнет получаться. Это и будет индикатор того, что вы стали senior'ом.
И хотелось бы отдельно отметить, что senior-разработчик != teamlead. Мое мнение - это понимание нужно прививать еще с джуниорского уровня. По пути к senior'у действительно крайне полезно (где-то на этапе middle 1.5) некоторое время побывать в шкуре тех. лида - чтобы расширить границы своего системного и стратегического мышлений и получить опыт проектной организации. Но это надо делать четко понимая, что это не вертикальный рост, а горизонтальный.
Про то, что хуки это исключительно стратегия не соглашусь, при помощи хуков можно инкапсулировать практически любые сервисы и инструменты. Использование хуков в качестве стратегии - частный случай.
Поинт про невозможность замены хуков - достаточно интересен, ведь такая проблема в общем виде есть, однако если углубиться в механизмы при помощи которых подобная замена реализуема в классовых компонентах - это либо наследование, либо мутация. Все современные фреймворки ушли в декларативный подход, он доказал себя максимально эффективным в плане управления сложностью и в этом подходе нет места ни мутациям, ни наследованию.
Не буду спорить, что представители секты последователей наследования и мутаций все еще среди нас - спорить с ними по этому поводу я не буду)
Откройте уже для себя любую из десятков библиотек с автоматическим отслеживанием зависимостей.
Давайте не будем подменять понятия и от "ручного указания зависимостей" как недостаток функциональных компонентов перепрыгивать сразу к библиотекам стейт менеджеров. Стейт менеджеры уходят от изначальной проблемы и используются в любых компонентах, а статья и комментарии фокусируются на преимуществах и недостатках функциональных и классовых компонентов. Пример с gdsfp был как раз в качестве возможного способа управления зависимостями при получении новых состояний.
Только того, что находится в state, а не вообще всех полей объекта.
Возможно у вас другое определение слову "перерендеривается". В реакте перерендеринг - это процесс построения виртуального дерева на основе результата рендера компонента. Ни в классовых, ни в функциональных, нет ничего похожего на перерендеринг только того, что находится в state. Если под словом рендеринг вы подразумеваете "исполнение" тела функционального компонента, на другую чащу весов выставляя то, что классовый компонент не пересоздается, то я, вероятно, вас огорчу - это разные подходы к жизненному циклу, причем в случае функциональных компонентов тело все равно выполняется быстрее, а при корректно указанных зависимостях дополнительных побочных эффектов быть не должно. Что, кстати, в случае работы с несколькими состояниями в классовых компонентах - через тот же gdsfp становится настоящим адом, ведь он будет вызываться даже при изменении стейта.
Объекты, лежащие в полях классового компонента, к реакту не прибиты.
Тут стоит указать пример использования и желательно не отходить от темы различий между классовыми и функциональными компонентами. Объекты можно хранить и в функциональных компонентах, можно даже использовать вложенные сервисы, заворачивая их подписки и отписки в классовые методы, но от этого мы не делаем сами методы класса переиспользуемыми, мы добавляем еще одну абстракцию, чтобы не прибивать гвоздями часть функционала. В классовых компонентах без наследования, миксинов или ХОК-ов нельзя вынести набор методов жизненого цикла для переиспользования. Конечно, всегда можно вынести весь "умный" компонент и переиспользовать его, но это не отличается от функциональных компонентов.
С другой стороны хуки позволяют выносить блоки жизненного цикла в отдельные сущности, без использования десятка промежуточных инструментов, это дополнительная гибкость, она несет в себе как пользу, так и вред - вот это уже более интересная тема для обсуждения.
Жесткое ограничение на вызовы: минус, согласен тут спорно, абстракция ради достижения цели, чаще всего интуитивная.
Ручное указание зависимостей: плюс, а вы пользовались когда-нибудь gdsfp в классовых компонентах с несколькими стейтами? Ручное указание зависимостей - гигантский скачок вперед для реакта после этого кошмара.
Рендер всего компонента на изменение стейта - выдуманный недостаток. А тут-то что не так? Классовые тоже перерендериваются при изменении стейта.
Намертво прибиты к реакту - тоже выдуманный пункт, классовые методы тоже прибиты к реакту, точнее даже к конкретному компоненту. Единственным способом переиспользования классовых методов жизненного цикла - является как раз написание HOC’ов. А вот хуки можно переиспользовать в других компонентах и даже хуках. В целом если встает проблема «прибитых к реакту хуков», то вероятно нет разграничения функциональности между утиллитами и хуками. Хуки должны реализовывать только части жизненного цикла компонентов.
Пляски с бубном для доступа к их состоянию вне рендеринга компонента - очень надеюсь, что в данном пункте не подразумевается доступ к методам классового компонента посредством ref’ов, тоже плохой паттерн, повышающий связность и размазывающий логику.
Если уж надо назвать реальные минусы хуков - то это в первую очередь «казуальность». Хуки дают так много свободы, что комьюнити начала использовать хуки для решения проблемы здесь и сейчас, теряется грань между интерфейсами, размывается разграничение ответственностей - это все влечет за собой деградацию кодовой базы в руках слабых IT-специалистов.
Если чуть обобщить, то реакт никогда не славился следованием принципу «pit of success”, при котором самое логичное действие непременно приведет к успеху, а хуки в этом плане еще один шаг в противоположном направлении.
Наследование в реакте - вершина антипаттернов, да и в целом это антипаттерн всего ООП при проектировании подобных сущностей.
Базовый принцип к которому аппелирует реакт - favor composition over inheritance. В остальном желание «Удобно расположить разные части кода по разным методам» - чаще всего тоже выстреливает в ногу. Когда в методах жизненного цикла появляется несколько цепочек не связанной напрямую функциональностей.
Забавный факт, но при переходе от классовых компонентов к функциональным, все проходят одну и ту же боль - нужно перестраивать мышление, с хуками возможно писать очень чистые и понятные компоненты, но для этого необходимо научиться выделять кастомные хуки. При этом возврат к классовым после полноценного перехода к хукам становится дорогой к громоздкому и грязному коду.
Все перечисленное тоже спрашиваю, кроме одновременно разрабатываемых проектов. Особенно круто работает - какие последние достижения за год-два-n.
Но это больше вопросы по софтовому собесу, а вот чем отличается веб-воркер от сервис-воркера звучит хардкорно, особенно учитывая, что мало кто применял и те, и другие))
Соглашусь, что во многом хорошие базовые софты укрепляют специалистов, вот только любого довольно слабого специалиста можно забросить в менеджмент, покрутится лидом год и будет прекрасно говорить, мыслить проектно. Но если задача найти не менеджера, а технического специалиста - важнее насколько он погрузился в техническую часть, в 9 случаях из 10 у таких людей и софты на уровне, что совершенно не работает в обратную сторону
А на каком основании вы легально увольняете с испытательного срока?)
Реальность такова, что рынок наводнен middle-разработчиками, которые видят свое продвижение исключительно в лидов и руководителей, по общению с большинством из них - они достигли потолка, узнали все, что можно знать. Что происходит, когда их погружают в инфраструктурные, архитектурные или R&D проекты? Они сыпятся. Если же не погружать и не выводить из зоны комфорта - то в лучшем случае они ограничены теми инструментами, которыми пользуются ежедневно.
На собеседованиях я не задаю вопросы в лоб - «а что там внутри webpack’а». Обычно начинаю с простого, работал ли с ним, на каком уровне, отличаешь ли назначение loader’ов. Ответ говорит о многом, если повторить аналогичную процедуру с различными областями - то становится понятен общий уровень стратегического и системного мышления.
А как еще отличить senior от middle, с хорошо подвязанным языком?
Супер, спасибо, еще код для исследований - обязательно посмотрю! :) У меня цель как раз избавиться от фрейворка в этой концепции, пока все решения слишком зависят от контекста решения. А еще сюда же надо будет докидывать поддержку WMF. Из того ресерча, что я по нему делал - там отдельный род задач - собрать все eager-chunk'и, объединяющиеся с async boundary. Если супер коротко - то WMF позволяет использовать синхронные импорты, если они используются внутри за асинхронными.
Для развития не обязательно, чтобы рядом был кто-то, кто может помочь в любом вопросе. Некоторым образом это даже плохо, когда есть кто-то, кто может исправить за тебя все твои косяки и помочь тебе самому найти информацию.
В ситуации, где ты один разработчик, очень важно не застрясть в "легасях". Для этого нужно соблюдать принцип 80 на 20. 80% - общий фокус на углубление знаний в конкретных технологиях, которые применяешь. 20% - поиск новых лучших практик и технологий, экспериментирование. Ряд хороших книг может с лихвой заменить старшего наставника. А рабочая обстановка - позволит взрастить мотивацию и самодостаточность.
Важно научиться не только заниматься фичами - выстроить такие процессы можно абсолютно везде. Хорошие компании понимают, что разработчик занимается фичами не 100% времени, в плохих компаниях нужно переоценивать задачи, занижать свой performance, чтобы оставалось время на решение проблем проекта и экспериментирование с подходами.
Если в компании даже нет agile можно взять простенькую доску trello и накидывать на нее задачи, ставить себе временные рамки, это позволит эффективнее тратить свое личное время.
Заголовок гласит про рост до Senior, а все пункты тянут от силы на чуть выше middle-1. Из Senior'ских советов разве что написать свою библиотеку, да и то очень преждевременно.
Ожидал увидеть что-нибудь из:
- развивайте системное мышление, углубитесь в design-review, придумывайте архитектурные схемы, учитесь их представлять и детализировать;
- собеседуйте людей, рефлексируйте и закрывайте обнаруженные пробелы в знаниях;
- при изучении новых или даже уже известных вам технологий, старайтесь чаще "нырять в кротовью нору" - то есть копать до их внутреннего устройства, чем глубже - тем лучше (в идеале до процессорного уровня);
- взваливайте на себя ответственность - чем больше, тем лучше - лидировать смешанную команду, организовывать митапы, проводить лекции, обсуждайте в том числе вопросы реализации backend-приложений;
- читайте больше технической литературы, углубляйте знания паттернов проектирования;
- эксперементируйте, придумывайте новые подходы, помогающий решать каждодневные задачи и просто писать качественный код;
- объедините все свои достижения в свой собственный Framework / CMS;
- контрибьютьте в OpenSource, не просто исправление опечаток, а доработки, исправления популярных библиотек, попутно впитывая архитектурные приемы используемые профессиональными разработчиками;
В какой-то момент вы перерастете "продуктовую разработку", вам захочется чего-то более прикладного, создавать технологии, а не применять их. И это у вас начнет получаться. Это и будет индикатор того, что вы стали senior'ом.
И хотелось бы отдельно отметить, что senior-разработчик != teamlead. Мое мнение - это понимание нужно прививать еще с джуниорского уровня. По пути к senior'у действительно крайне полезно (где-то на этапе middle 1.5) некоторое время побывать в шкуре тех. лида - чтобы расширить границы своего системного и стратегического мышлений и получить опыт проектной организации. Но это надо делать четко понимая, что это не вертикальный рост, а горизонтальный.
Несколько лет это еще хорошо, часто код становится легаси уже на этапе влития в репозиторий
Про то, что хуки это исключительно стратегия не соглашусь, при помощи хуков можно инкапсулировать практически любые сервисы и инструменты. Использование хуков в качестве стратегии - частный случай.
Поинт про невозможность замены хуков - достаточно интересен, ведь такая проблема в общем виде есть, однако если углубиться в механизмы при помощи которых подобная замена реализуема в классовых компонентах - это либо наследование, либо мутация. Все современные фреймворки ушли в декларативный подход, он доказал себя максимально эффективным в плане управления сложностью и в этом подходе нет места ни мутациям, ни наследованию.
Не буду спорить, что представители секты последователей наследования и мутаций все еще среди нас - спорить с ними по этому поводу я не буду)
Давайте не будем подменять понятия и от "ручного указания зависимостей" как недостаток функциональных компонентов перепрыгивать сразу к библиотекам стейт менеджеров. Стейт менеджеры уходят от изначальной проблемы и используются в любых компонентах, а статья и комментарии фокусируются на преимуществах и недостатках функциональных и классовых компонентов. Пример с gdsfp был как раз в качестве возможного способа управления зависимостями при получении новых состояний.
Возможно у вас другое определение слову "перерендеривается". В реакте перерендеринг - это процесс построения виртуального дерева на основе результата рендера компонента. Ни в классовых, ни в функциональных, нет ничего похожего на перерендеринг только того, что находится в state. Если под словом рендеринг вы подразумеваете "исполнение" тела функционального компонента, на другую чащу весов выставляя то, что классовый компонент не пересоздается, то я, вероятно, вас огорчу - это разные подходы к жизненному циклу, причем в случае функциональных компонентов тело все равно выполняется быстрее, а при корректно указанных зависимостях дополнительных побочных эффектов быть не должно. Что, кстати, в случае работы с несколькими состояниями в классовых компонентах - через тот же gdsfp становится настоящим адом, ведь он будет вызываться даже при изменении стейта.
Тут стоит указать пример использования и желательно не отходить от темы различий между классовыми и функциональными компонентами. Объекты можно хранить и в функциональных компонентах, можно даже использовать вложенные сервисы, заворачивая их подписки и отписки в классовые методы, но от этого мы не делаем сами методы класса переиспользуемыми, мы добавляем еще одну абстракцию, чтобы не прибивать гвоздями часть функционала. В классовых компонентах без наследования, миксинов или ХОК-ов нельзя вынести набор методов жизненого цикла для переиспользования. Конечно, всегда можно вынести весь "умный" компонент и переиспользовать его, но это не отличается от функциональных компонентов.
С другой стороны хуки позволяют выносить блоки жизненного цикла в отдельные сущности, без использования десятка промежуточных инструментов, это дополнительная гибкость, она несет в себе как пользу, так и вред - вот это уже более интересная тема для обсуждения.
Жесткое ограничение на вызовы: минус, согласен тут спорно, абстракция ради достижения цели, чаще всего интуитивная.
Ручное указание зависимостей: плюс, а вы пользовались когда-нибудь gdsfp в классовых компонентах с несколькими стейтами? Ручное указание зависимостей - гигантский скачок вперед для реакта после этого кошмара.
Рендер всего компонента на изменение стейта - выдуманный недостаток. А тут-то что не так? Классовые тоже перерендериваются при изменении стейта.
Намертво прибиты к реакту - тоже выдуманный пункт, классовые методы тоже прибиты к реакту, точнее даже к конкретному компоненту. Единственным способом переиспользования классовых методов жизненного цикла - является как раз написание HOC’ов. А вот хуки можно переиспользовать в других компонентах и даже хуках. В целом если встает проблема «прибитых к реакту хуков», то вероятно нет разграничения функциональности между утиллитами и хуками. Хуки должны реализовывать только части жизненного цикла компонентов.
Пляски с бубном для доступа к их состоянию вне рендеринга компонента - очень надеюсь, что в данном пункте не подразумевается доступ к методам классового компонента посредством ref’ов, тоже плохой паттерн, повышающий связность и размазывающий логику.
Если уж надо назвать реальные минусы хуков - то это в первую очередь «казуальность». Хуки дают так много свободы, что комьюнити начала использовать хуки для решения проблемы здесь и сейчас, теряется грань между интерфейсами, размывается разграничение ответственностей - это все влечет за собой деградацию кодовой базы в руках слабых IT-специалистов.
Если чуть обобщить, то реакт никогда не славился следованием принципу «pit of success”, при котором самое логичное действие непременно приведет к успеху, а хуки в этом плане еще один шаг в противоположном направлении.
Наследование в реакте - вершина антипаттернов, да и в целом это антипаттерн всего ООП при проектировании подобных сущностей.
Базовый принцип к которому аппелирует реакт - favor composition over inheritance. В остальном желание «Удобно расположить разные части кода по разным методам» - чаще всего тоже выстреливает в ногу. Когда в методах жизненного цикла появляется несколько цепочек не связанной напрямую функциональностей.
Забавный факт, но при переходе от классовых компонентов к функциональным, все проходят одну и ту же боль - нужно перестраивать мышление, с хуками возможно писать очень чистые и понятные компоненты, но для этого необходимо научиться выделять кастомные хуки. При этом возврат к классовым после полноценного перехода к хукам становится дорогой к громоздкому и грязному коду.
Мы уже пошли по кругу - говорим об одних вещах на разных примерах))
Уверен мы оба согласимся, что вне зависимости от подхода к собеседованию, самым важным в собеседовании - включать мозг и действовать продуманно.
Кроме этого, не стоит забывать, что оба участника собеседования оценивают друг друга.
Все перечисленное тоже спрашиваю, кроме одновременно разрабатываемых проектов. Особенно круто работает - какие последние достижения за год-два-n.
Но это больше вопросы по софтовому собесу, а вот чем отличается веб-воркер от сервис-воркера звучит хардкорно, особенно учитывая, что мало кто применял и те, и другие))
Соглашусь, что во многом хорошие базовые софты укрепляют специалистов, вот только любого довольно слабого специалиста можно забросить в менеджмент, покрутится лидом год и будет прекрасно говорить, мыслить проектно. Но если задача найти не менеджера, а технического специалиста - важнее насколько он погрузился в техническую часть, в 9 случаях из 10 у таких людей и софты на уровне, что совершенно не работает в обратную сторону
А на каком основании вы легально увольняете с испытательного срока?)
Реальность такова, что рынок наводнен middle-разработчиками, которые видят свое продвижение исключительно в лидов и руководителей, по общению с большинством из них - они достигли потолка, узнали все, что можно знать. Что происходит, когда их погружают в инфраструктурные, архитектурные или R&D проекты? Они сыпятся. Если же не погружать и не выводить из зоны комфорта - то в лучшем случае они ограничены теми инструментами, которыми пользуются ежедневно.
На собеседованиях я не задаю вопросы в лоб - «а что там внутри webpack’а». Обычно начинаю с простого, работал ли с ним, на каком уровне, отличаешь ли назначение loader’ов. Ответ говорит о многом, если повторить аналогичную процедуру с различными областями - то становится понятен общий уровень стратегического и системного мышления.
А как еще отличить senior от middle, с хорошо подвязанным языком?
Супер, спасибо, еще код для исследований - обязательно посмотрю! :) У меня цель как раз избавиться от фрейворка в этой концепции, пока все решения слишком зависят от контекста решения. А еще сюда же надо будет докидывать поддержку WMF. Из того ресерча, что я по нему делал - там отдельный род задач - собрать все eager-chunk'и, объединяющиеся с async boundary. Если супер коротко - то WMF позволяет использовать синхронные импорты, если они используются внутри за асинхронными.
Нет, в комментариях к коду одной из исследуемых библиотек, если не ошибаюсь, то в react-flight