Ну рефакторинг тоже бывает разным, можно понемногу переписывать все, а можно рубануть с плеча и влезать в ядро надо прям сильно сознательно и джунов туда лучше не пускать. А вот что-то малокритичное дать джуну с последующим надзором - милое дело.
С джунами соглашусь, но по мне такое желание все же бывает не только у них. Иногда людям действительно удается переписать что-то сложное без больших последствий, что создает прецедент (на всю команду причем) того, что оно и дальше так прокатит. И оно, кстати, может и дальше прокатит и всем действительно станет лучше.
Моя идея была попытаться донести, что такие решения должны приниматься только с человеком, который знает предметную область, а в идеале и сильно участвовал в написании этого кода, человеком глубоко изнутри, а не кем-то снаружи, каким бы звездным он ни был.
А если попытаться перефразировать, то переписывать сложный код - нужно, но только в том случае, если это сознательный вариант, а альтернатива - еще хуже. А вот правильно оценить альтернативу - это уже наука, причем у каждого своя.
Спасибо за провокационный комментарий. Статья - ровно об этом: математика - ок, но предпосылки к ней изначально были неверные, поэтому ее можно было не делать. Я нигде не писал, что это были МОИ проекты, или что я в них полноценно участвовал, более того, я на это никоим образом не претендую. Я имел ввиду только то, что и так было написано буквами - я повидал устройство изнутри множества команд.
Это дословно означает, что я знаю их состав, стек, инфру, подход к разработке и их проект на уровне продвинутого пользователя (где-то глубже, где-то поверхностнее). Когда ты большую часть рабочей жизни делаешь коробочный софт и встраиваемые сервисы для разработчиков, то частью работы становятся попытки разобраться кто, зачем, как и почему использует этот софт и как в итоге его потом затаскивать в контур заказчика.
Поэтому (как уже писали ниже) выдернуть две цифры и поделить одно на другое и сделать выводы - так себе история. Больших и очень сложных проектов с полноценным участием у меня было штук 10, а работку я менял всего 6 раз за все время, нигде не работая меньше года, поэтому ни о каких скаканиях речи быть не может.
Спасибо, лайк поставил, дополнение шикарное! Но я с ним соглашусь частично. Частично, потому что лояльность - по мне лишь одна из веток здравого смысла. Люди все очень разные, в том числе те самые принимающие решение директора: кто-то из них залетный карьерист, кто-то радеет за дело, поэтому каждый отреагирует на критику (почему именно - критику?) совершенно по разному.
И слово "критика" само по себе подразумевает начинающийся конфликт. К сожалению, многие решения кажутся неоптимальными именно с высоты своего полета, а на другом уровне выше есть много дополнительных вводных, которые могут перевернуть понимание о принятом решении. Если эти вводные не знать, в них разобраться попыток не делать, а диалог начать с открытия двери ногой (на созвоне в 100 человек, например) и фразы "тут все г%вно", то все точно пойдет по тому пути, что вы описали. Возможно, люди воспринимают предложения "насаждения добра" именно потому, что оно подается не так или есть вводные, которые не нужно знать другим сотрудникам. Мир и люди - сложные.
Но точно могу сказать, что не все директора - говнюки, не все - принимают неудачные решения, и не все из них остро реагируют на предложения, если подать их правильно. Поэтому если случай клинический (они есть, не спорю), то лояльность это выход. Но если ваш грейд позволяет общаться с принимающими решения людьми, то зачастую все не так плохо и на все можно повлиять, понять, обсудить и что-то предложить. Адекватные боссы на адекватный диалог реагируют нормально, в конце концов, это и есть то самое искусство управления людьми, никого не хочу в этом убеждать, но у меня всю жизнь было именно так.
Плюс абсолютная лояльность это все же не для всех, быть лояльным к неудачным решениям - это тоже особенный навык, который есть далеко не у всех. Поэтому если лояльность это оптимальное решение в данной ситуации, и она не вызывает отторжения, то да, это выход и надо делать работку и получать удовольствие от всего процесса.
Привет! Роман, отличный вопрос. Выделение простых (то есть, контрастных) классов ускорить получается. Из минусов SAM на примере обсуждения - ожидаемо плохая работа с классами "кожа" и "волосы".
Также мы уже полностью подняли Segment Anything на своей инфраструктуре и встроили его в АБК Элементари. Приглашаю к экспериментам, пример прикладываю.
Здравствуйте, спасибо за проявленный интерес! Мы временно приостановили свободную регистрацию заказчиков, но всегда готовы провести полноценное демо по запросу, будем рады ответить на все вопросы, если напишите нам на почту — elementary@activebc.ru
Ну рефакторинг тоже бывает разным, можно понемногу переписывать все, а можно рубануть с плеча и влезать в ядро надо прям сильно сознательно и джунов туда лучше не пускать. А вот что-то малокритичное дать джуну с последующим надзором - милое дело.
С джунами соглашусь, но по мне такое желание все же бывает не только у них. Иногда людям действительно удается переписать что-то сложное без больших последствий, что создает прецедент (на всю команду причем) того, что оно и дальше так прокатит. И оно, кстати, может и дальше прокатит и всем действительно станет лучше.
Моя идея была попытаться донести, что такие решения должны приниматься только с человеком, который знает предметную область, а в идеале и сильно участвовал в написании этого кода, человеком глубоко изнутри, а не кем-то снаружи, каким бы звездным он ни был.
А если попытаться перефразировать, то переписывать сложный код - нужно, но только в том случае, если это сознательный вариант, а альтернатива - еще хуже. А вот правильно оценить альтернативу - это уже наука, причем у каждого своя.
Спасибо за провокационный комментарий. Статья - ровно об этом: математика - ок, но предпосылки к ней изначально были неверные, поэтому ее можно было не делать. Я нигде не писал, что это были МОИ проекты, или что я в них полноценно участвовал, более того, я на это никоим образом не претендую. Я имел ввиду только то, что и так было написано буквами - я повидал устройство изнутри множества команд.
Это дословно означает, что я знаю их состав, стек, инфру, подход к разработке и их проект на уровне продвинутого пользователя (где-то глубже, где-то поверхностнее). Когда ты большую часть рабочей жизни делаешь коробочный софт и встраиваемые сервисы для разработчиков, то частью работы становятся попытки разобраться кто, зачем, как и почему использует этот софт и как в итоге его потом затаскивать в контур заказчика.
Поэтому (как уже писали ниже) выдернуть две цифры и поделить одно на другое и сделать выводы - так себе история. Больших и очень сложных проектов с полноценным участием у меня было штук 10, а работку я менял всего 6 раз за все время, нигде не работая меньше года, поэтому ни о каких скаканиях речи быть не может.
"Garbage in, garbage out" - во всей его красе.
Спасибо, лайк поставил, дополнение шикарное! Но я с ним соглашусь частично. Частично, потому что лояльность - по мне лишь одна из веток здравого смысла. Люди все очень разные, в том числе те самые принимающие решение директора: кто-то из них залетный карьерист, кто-то радеет за дело, поэтому каждый отреагирует на критику (почему именно - критику?) совершенно по разному.
И слово "критика" само по себе подразумевает начинающийся конфликт. К сожалению, многие решения кажутся неоптимальными именно с высоты своего полета, а на другом уровне выше есть много дополнительных вводных, которые могут перевернуть понимание о принятом решении. Если эти вводные не знать, в них разобраться попыток не делать, а диалог начать с открытия двери ногой (на созвоне в 100 человек, например) и фразы "тут все г%вно", то все точно пойдет по тому пути, что вы описали. Возможно, люди воспринимают предложения "насаждения добра" именно потому, что оно подается не так или есть вводные, которые не нужно знать другим сотрудникам. Мир и люди - сложные.
Но точно могу сказать, что не все директора - говнюки, не все - принимают неудачные решения, и не все из них остро реагируют на предложения, если подать их правильно. Поэтому если случай клинический (они есть, не спорю), то лояльность это выход. Но если ваш грейд позволяет общаться с принимающими решения людьми, то зачастую все не так плохо и на все можно повлиять, понять, обсудить и что-то предложить. Адекватные боссы на адекватный диалог реагируют нормально, в конце концов, это и есть то самое искусство управления людьми, никого не хочу в этом убеждать, но у меня всю жизнь было именно так.
Плюс абсолютная лояльность это все же не для всех, быть лояльным к неудачным решениям - это тоже особенный навык, который есть далеко не у всех. Поэтому если лояльность это оптимальное решение в данной ситуации, и она не вызывает отторжения, то да, это выход и надо делать работку и получать удовольствие от всего процесса.
Привет! Роман, отличный вопрос. Выделение простых (то есть, контрастных) классов ускорить получается. Из минусов SAM на примере обсуждения - ожидаемо плохая работа с классами "кожа" и "волосы".
Также мы уже полностью подняли Segment Anything на своей инфраструктуре и встроили его в АБК Элементари. Приглашаю к экспериментам, пример прикладываю.
Здравствуйте, спасибо за проявленный интерес! Мы временно приостановили свободную регистрацию заказчиков, но всегда готовы провести полноценное демо по запросу, будем рады ответить на все вопросы, если напишите нам на почту — elementary@activebc.ru