Все права естественно принадлежат компании. Не стоит серьезно относится к таким проектам. Во главе угла должно стоять обучение. Стоит учитывать это на старте.
Держать баланс между поклонением best practices и работой спустя рукава. Где-то там, посередине, и есть разработчик, который без фанатизма пишет код на твёрдую четвёрку - достаточно быстро, чтобы не срывать релиз, и достаточно качественно, чтобы не формировать жирный техдолг.
А я и не говорю, что это нужно вводить в середине цикла разработки, когда все вредные привычки уже сформированы. Я тоже считаю, что это надо закладывать с самого начала и жестко обязывать команду соблюдать эту практику. А самоосознанность - это до первой горящей жопы перед релизом. Надо всё закреплять на уровне документации и бить по рукам за несоблюдение оговоренных правил.
А поддерживать потом как? Разработчику нужно одновременно работать минимум в трёх файлах в рамках одного компонента. Довольно сильно размывает фокус. Не подумайте, я не представляю противоположную точку зрения, я просто хочу для себя разобраться, как помочь проекту не скатиться в помойку.
У меня в голове только один вариант. На уровне команды и проекта определить минимальный порог, после которого мы будем дробить компонент. Например: простые компоненты <150-200 строк оставлять как есть, средние - до 300 или со сложной логикой дробить, страницы и контейнеры - всегда дробить (стили во всех случаях выносить отдельно).
Тем самым мы можем не распыляться на мелкую ерунду вроде кнопок или других маленьких компонентов и сосредоточиться на декомпозиции средних и больших модулей и страниц. Вроде то же самое, но экономим время на «мишуре» и фокусируемся на том, где дробление действительно решает.
Такое разбиение мне больше по душе, чем копание в месиве React-компонента. Но это сильно тормозит написание самого компонента (хотя и даёт преимущество в долгосрок). Бизнесу нужно быстро, а дробить кнопку на кучку файлов и повторять это раз за разом во всех последующих компонентах я считаю другой крайностью, как и писать всё в одном файле. «Месиво» против «Капусты» - наверное, нужен какой-то компромисс между этими подходами.
Здесь речь идет не о “культе достигаторства”, а о движении вперед к намеченной цели. Неважно, навязана ли она или осознанно выбрана, — если цель есть, то важно уметь к ней двигаться.
Нет ничего плохого в том, чтобы оставаться на своей текущей позиции, но только если это осознанный выбор. Другое дело, когда хочется двигаться вперед, но что-то мешает даже на шаг приблизиться к желаемому. Именно в таких случаях я предлагаю решение.
А темы вроде “культа достигаторства” или “навязанных целей и ценностей” — это уже совершенно другой разговор.
Изначально думал, что получится краткая выжимка минимальных требований к джуну. Но вышло и правда многовато для "вчерашнего студента". С другой стороны никто и не говорил, что будет легко.
Корень проблемы, как мне кажется, в недосказанности между всеми участниками процесса. Пока кто-то боится задать вопрос или уточнить детали, чтобы не показаться "некомпетентным", такие ситуации будут повторяться.
Многие проблемы решаются, если заранее договариваться о зонах ответственности и фиксировать ожидания: кто что делает и за что отвечает. Ну и метрики надо учитывать адекватно — смотреть не только на количество ошибок, но и на сложность задач и объем проделанной работы.
А еще очень важно нормально общаться в команде. Если есть честный диалог между менеджерами, постановщиками и разработчиками, таких ситуаций можно избежать.
Мне кажется очень странным откладывать жизнь на потом, когда тебе стукнул уже пятый десяток. Мой жизненный вектор гласит иначе. До 30 я обязан наработать себе базу и уже после 30 начинать кайфовать. Мне всего 27 и я уже перевыполнил этот план. Пока останавливаться не планирую, но и загонять себя тоже не хочу.
Все права естественно принадлежат компании. Не стоит серьезно относится к таким проектам. Во главе угла должно стоять обучение. Стоит учитывать это на старте.
Держать баланс между поклонением best practices и работой спустя рукава. Где-то там, посередине, и есть разработчик, который без фанатизма пишет код на твёрдую четвёрку - достаточно быстро, чтобы не срывать релиз, и достаточно качественно, чтобы не формировать жирный техдолг.
Увы... Основано на реальных событиях
А я и не говорю, что это нужно вводить в середине цикла разработки, когда все вредные привычки уже сформированы. Я тоже считаю, что это надо закладывать с самого начала и жестко обязывать команду соблюдать эту практику. А самоосознанность - это до первой горящей жопы перед релизом. Надо всё закреплять на уровне документации и бить по рукам за несоблюдение оговоренных правил.
А поддерживать потом как? Разработчику нужно одновременно работать минимум в трёх файлах в рамках одного компонента. Довольно сильно размывает фокус. Не подумайте, я не представляю противоположную точку зрения, я просто хочу для себя разобраться, как помочь проекту не скатиться в помойку.
У меня в голове только один вариант. На уровне команды и проекта определить минимальный порог, после которого мы будем дробить компонент. Например: простые компоненты <150-200 строк оставлять как есть, средние - до 300 или со сложной логикой дробить, страницы и контейнеры - всегда дробить (стили во всех случаях выносить отдельно).
Тем самым мы можем не распыляться на мелкую ерунду вроде кнопок или других маленьких компонентов и сосредоточиться на декомпозиции средних и больших модулей и страниц. Вроде то же самое, но экономим время на «мишуре» и фокусируемся на том, где дробление действительно решает.
Такое разбиение мне больше по душе, чем копание в месиве React-компонента. Но это сильно тормозит написание самого компонента (хотя и даёт преимущество в долгосрок). Бизнесу нужно быстро, а дробить кнопку на кучку файлов и повторять это раз за разом во всех последующих компонентах я считаю другой крайностью, как и писать всё в одном файле. «Месиво» против «Капусты» - наверное, нужен какой-то компромисс между этими подходами.
Конечно. Без выгорания не обойтись в нашей профессии)
На любом уровне могут возникать конфликты (масштабы разные). Тимлиды в команде не панацея от этого
Спасибо, мне очень приятно!
Здесь речь идет не о “культе достигаторства”, а о движении вперед к намеченной цели. Неважно, навязана ли она или осознанно выбрана, — если цель есть, то важно уметь к ней двигаться.
Нет ничего плохого в том, чтобы оставаться на своей текущей позиции, но только если это осознанный выбор. Другое дело, когда хочется двигаться вперед, но что-то мешает даже на шаг приблизиться к желаемому. Именно в таких случаях я предлагаю решение.
А темы вроде “культа достигаторства” или “навязанных целей и ценностей” — это уже совершенно другой разговор.
А стоит ли вообще поднимать настолько субъективную тему как "соответствие определенному грейду"?
Увы, но Вы не по адресу. Я тут про другое пишу)
А как наличие flex и grid помогут с отображением на разных браузерах? Это лишь способы позиционирования элементов
Слишком много работы ради канала с анонсами статей и мемами).
А даже если и да? Не вижу ничего зазорного).
А что для Вас "нормальные языки"?
Изначально думал, что получится краткая выжимка минимальных требований к джуну. Но вышло и правда многовато для "вчерашнего студента". С другой стороны никто и не говорил, что будет легко.
Корень проблемы, как мне кажется, в недосказанности между всеми участниками процесса. Пока кто-то боится задать вопрос или уточнить детали, чтобы не показаться "некомпетентным", такие ситуации будут повторяться.
Многие проблемы решаются, если заранее договариваться о зонах ответственности и фиксировать ожидания: кто что делает и за что отвечает. Ну и метрики надо учитывать адекватно — смотреть не только на количество ошибок, но и на сложность задач и объем проделанной работы.
А еще очень важно нормально общаться в команде. Если есть честный диалог между менеджерами, постановщиками и разработчиками, таких ситуаций можно избежать.
Хлопаю стоя, уважаемый!
Полностью согласен. Сейчас намного проще стартовать, даже при минимальных стартовых ресурсах.
Вот-вот. Я лично не видел ни одного пенсионера, который жил бы в кайф и, тем более, не жалел о по большей части впустую потраченной молодости.
Мне кажется очень странным откладывать жизнь на потом, когда тебе стукнул уже пятый десяток. Мой жизненный вектор гласит иначе. До 30 я обязан наработать себе базу и уже после 30 начинать кайфовать. Мне всего 27 и я уже перевыполнил этот план. Пока останавливаться не планирую, но и загонять себя тоже не хочу.