О, в этом плане интересен ваш опыт как в раз в НИОКР проектах.
У меня сложилось плотное впечатление что приличная часть процессов и особенно эстимейты — артефакт наличия человека с шапкой «проджект». И в НИОКР они, ммм, не окупаются. Мы в итоге живем в формате когда вместо «назвал срок и по-пацански уложился» просто «по-пацански где надо сделал хорошо и остальное побыстрее»
У этого есть свои трейдоффы и интересно, как оно работало у вас где есть вера в ТЗ и процессы.
Трейдоффы например
Тут Лид / продакт должны очень понятно сказать, где вероятно поменяется и сделать надо дешево, а гле фундамент для следующих 30 фич.
Вместо ТЗ — контекст + доспоросить если нужно, что не всем IC удобно / нравится
Мы последний год в компании активно занимались тем, чтобы большей части «Какие нежные. А лид что не человек?» вернуть обратно лычку разработчика, у которого в job description эти задачки решать и написано.
Честно — сработало очень приятно. «Интересные задачи» делаются сильно быстрее когда у человека на них все ментальные ресурсы, а не «остаток после встреч», команды намного меньше плачут о посредственных процессах, и что никто им с карьерным ростом не помогает. Продакты не страдают от людей с которыми хрен договоришься или с которыми «вы не вместе проблему решаете, ты просто им манипулируешь чтобы разработка сделала как попросишь»
Потому что лид, блин, человек, просто в идеале немного отличающийся по системе ценностей от разработчика и сводится она например к «мне важно какой в итоге результат и чтобы всем все нравилось», а не «смотри какую приколюху я написал / спроектировал» или «я теперь особенный разработчик у кормушки с раздачей тасок, буду самое вкусное выбирать»
(Людей отдали оставшимся лидам, но тут вероятно у нас был прекос что у многих лидов было 4-6 подчиненных и две такие команды одному взять не перегруз)
С позиции нанимающего менеджера (правда в Европе) увидев такое резюме и имея достаточный поток других кандатов я б вас тоже на интервью не позвал. После того как вы прошли ATS единственный важный блок для фронта — Experience. И тут явно миддл выдает за сеньера.
Пример 1 38% продуктивности которая честно не изменятся, а если это capacity в в жестком скраме, то сеньер б указал.
И «я отрефакторил 20 компонентов» в сеньерском резюме выглядело бы как «съехали с либы X на либу Y где надо чтобы достичь Z (редизайн, другая инфра, T2M)»
А в чем мотивация иметь отдельные first class citizen get и spy?
Это создает ситуацию, когда очень легко сделать get, не подписаться и потерять реактивность. И из-за относительной похожести визуально и того, что в большинстве других либ реактивности чтение = подписка, на код ревью такое тоже легко пропустить.
Я думал про такую штуку лет 7 назад но понял что не осилю запилить good enough выравнивание.
Так вот если у вас оно есть и параллельная книга цифровая, можно показывать текст на языке, на котором человек бы хотел читать, а при клике делать фоллбек предложения в его родной язык. Дополнительные клики переводят абзац, страницу.
Это будет mobile friendly по сравнению с параллельной книгой + взгляд не цепляется за текст на родном языке.
А еще клик это сингал и можно запоминать все места где человек захотел перевод и потом использовать их для повторения.
Однозначно лучше просто заюзать onClick в том случае. И даже если б вы вещали что-то на dom (например потому что оборачиваете leaflet или аналогичную библиотеку) больше смысла взять useLayout effect. И использовать ref, а не id.
Но у автора вообще есть ряд очень странных советов:
1) деструктурировать прописы и использовать prop types. Деструктуризация — вкусовщина, мы ее делаем но это ни на что не влияет. PropTypes — слабый runtime аналог typescript.
2) выносить тернарник в геттер функцию или 2 компонента которые принимают условия. Геттер на уровне реакта всегда будет перевычисляться, компонент — нет. А решить эту проблему можно намного чище сунув каждую ветку тернарника в отдельный компонент и мб заранее им пропсы заготовив если вам реально не удобно читать 2 строки.
Примерно так: последний раз я читал про этот синтаксис 2 года назад или никогда. Понимаю ли я сейчас код написанный другим разработчиком. И когда мне надо прочитать код бакенов на go, я понимаю. А какая иконка и откуда поставится в icon \like я не понимаю. И чем отличается title @ \Like и title \Like. Вопросики, escape и / и <= я не понимаю зачем нужны, но могу сдать вид что их нет.
О, в этом плане интересен ваш опыт как в раз в НИОКР проектах.
У меня сложилось плотное впечатление что приличная часть процессов и особенно эстимейты — артефакт наличия человека с шапкой «проджект». И в НИОКР они, ммм, не окупаются. Мы в итоге живем в формате когда вместо «назвал срок и по-пацански уложился» просто «по-пацански где надо сделал хорошо и остальное побыстрее»
У этого есть свои трейдоффы и интересно, как оно работало у вас где есть вера в ТЗ и процессы.
Трейдоффы например
Тут Лид / продакт должны очень понятно сказать, где вероятно поменяется и сделать надо дешево, а гле фундамент для следующих 30 фич.
Вместо ТЗ — контекст + доспоросить если нужно, что не всем IC удобно / нравится
Мы последний год в компании активно занимались тем, чтобы большей части «Какие нежные. А лид что не человек?» вернуть обратно лычку разработчика, у которого в job description эти задачки решать и написано.
Честно — сработало очень приятно. «Интересные задачи» делаются сильно быстрее когда у человека на них все ментальные ресурсы, а не «остаток после встреч», команды намного меньше плачут о посредственных процессах, и что никто им с карьерным ростом не помогает. Продакты не страдают от людей с которыми хрен договоришься или с которыми «вы не вместе проблему решаете, ты просто им манипулируешь чтобы разработка сделала как попросишь»
Потому что лид, блин, человек, просто в идеале немного отличающийся по системе ценностей от разработчика и сводится она например к «мне важно какой в итоге результат и чтобы всем все нравилось», а не «смотри какую приколюху я написал / спроектировал» или «я теперь особенный разработчик у кормушки с раздачей тасок, буду самое вкусное выбирать»
(Людей отдали оставшимся лидам, но тут вероятно у нас был прекос что у многих лидов было 4-6 подчиненных и две такие команды одному взять не перегруз)
Так рано делать выводы, ещё даже 10 лет не прошло
С позиции нанимающего менеджера (правда в Европе) увидев такое резюме и имея достаточный поток других кандатов я б вас тоже на интервью не позвал. После того как вы прошли ATS единственный важный блок для фронта — Experience. И тут явно миддл выдает за сеньера.
Пример 1 38% продуктивности которая честно не изменятся, а если это capacity в в жестком скраме, то сеньер б указал.
И «я отрефакторил 20 компонентов» в сеньерском резюме выглядело бы как «съехали с либы X на либу Y где надо чтобы достичь Z (редизайн, другая инфра, T2M)»
А в чем мотивация иметь отдельные first class citizen get и spy?
Это создает ситуацию, когда очень легко сделать get, не подписаться и потерять реактивность. И из-за относительной похожести визуально и того, что в большинстве других либ реактивности чтение = подписка, на код ревью такое тоже легко пропустить.
Я думал про такую штуку лет 7 назад но понял что не осилю запилить good enough выравнивание.
Так вот если у вас оно есть и параллельная книга цифровая, можно показывать текст на языке, на котором человек бы хотел читать, а при клике делать фоллбек предложения в его родной язык. Дополнительные клики переводят абзац, страницу.
Это будет mobile friendly по сравнению с параллельной книгой + взгляд не цепляется за текст на родном языке.
А еще клик это сингал и можно запоминать все места где человек захотел перевод и потом использовать их для повторения.
Однозначно лучше просто заюзать onClick в том случае. И даже если б вы вещали что-то на dom (например потому что оборачиваете leaflet или аналогичную библиотеку) больше смысла взять useLayout effect. И использовать ref, а не id.
Но у автора вообще есть ряд очень странных советов:
1) деструктурировать прописы и использовать prop types. Деструктуризация — вкусовщина, мы ее делаем но это ни на что не влияет. PropTypes — слабый runtime аналог typescript.
2) выносить тернарник в геттер функцию или 2 компонента которые принимают условия. Геттер на уровне реакта всегда будет перевычисляться, компонент — нет. А решить эту проблему можно намного чище сунув каждую ветку тернарника в отдельный компонент и мб заранее им пропсы заготовив если вам реально не удобно читать 2 строки.
Примерно так: последний раз я читал про этот синтаксис 2 года назад или никогда. Понимаю ли я сейчас код написанный другим разработчиком. И когда мне надо прочитать код бакенов на go, я понимаю. А какая иконка и откуда поставится в icon \like я не понимаю. И чем отличается title @ \Like и title \Like. Вопросики, escape и / и <= я не понимаю зачем нужны, но могу сдать вид что их нет.