Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Переделка GUI это не рефакторинг.
C>>Почему это?
НС>По определению

А можно определение рефакторинга?

Здравствуйте, IT, Вы писали:

IT>Спасибо, кэп. Открыл глаза. Только это не коммуникация. Это обычный рабочий процесс.

"обычный рабочий процесс" строится и двигается посредством коммуникации.
Для справки: коммуникация — взаимодействие с другими сотрудниками, коллегами.

>Ты сам определил коммуникацию как "его задача донести до менеджмента, объяснить, отстоять свою позицию". Вот этой фигнёй разраб заниматься не должен.

Чуть ниже ты пишешь про разделение работы. Работу поделили — следовательно необходимо организовать взаимодействие. Или у вас не так?

I>>Как только появились препятствия, здесь снова коммуникация — уметь найти того, кто починит сетку, базу и тд.
I>>Без этого всего эффекта от твоего кодинга около нуля.

IT>Если ты всем этим занимаешься, то это однозначный индикатор наличия проблем в твоей команде.

У тебя, похоже, сетка-база-итд само чинится. В отличие от тебя, я телепатией не пользуюсь, а потому мне надо сообщить о проблеме. Коммуникация.

I>>А вот с коммуникацией, но без кодинга, очень даже внятно получается — находишь себе девелопера, ставишь ему задачи, находишь ему помощников, команду и тд и тд, глядишь, и проект взлетел.

IT>И как часто ты без кодинга, но с коммуникацией взлетал проекты?

Про делегирование слышал? Или у вас там проектный менеджер кодингом занимается?

IT>>>Да у меня почти все тикеты такие.
I>>Что делать предложишь, если рефакторинг потребовался? Вот ты хочешь его вкомитать, а ктото другой рефакторинг раньше тебя вкомитал и теперь структура другая совсем.

IT>Железной ленейкой по пальцам. Не лезь куда не надо. Ты вообще о разделении работы в команде слышал?

Именно! Теперь самую малость осталось Вот новый сотрудник наткнулся на паскудство в коде и продолжать задачу не может, тк решение вне его зоны ответственности(работа ведь поделена).
Как ему быть? Что конкретно ему надо делать?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>По определению
C>>Которому из, и какой из его трактовок?

НС>По общепринятой. Изменение UI это изменение видимого поведения, как сову на глобус не натягивай.

Нету такого определения UI интерпретируется двояко — как визуальное представление и связаное с этим поведение, так и слой. Изменять слой сохраняя все его поведенческие аспекты очень даже возможно.

Здравствуйте, DenisCh, Вы писали:

НС>>По определению
DC>А можно определение рефакторинга?

В этом топике уже приводили.

Здравствуйте, Ikemefula, Вы писали:

IT>>Спасибо, кэп. Открыл глаза. Только это не коммуникация. Это обычный рабочий процесс.
I>"обычный рабочий процесс" строится и двигается посредством коммуникации.

Да ладно. Не может быть. Спасибо, кэп, ещё раз.

I>Для справки: коммуникация — взаимодействие с другими сотрудниками, коллегами.

Ты это определил по-другому, а именно (повторяю ещё раз) — "его задача донести до менеджмента, объяснить, отстоять свою позицию".

Теперь ты пытаешься заменить это определение на очевидные вещи. Засунуть сюда ежедневное общение с коллегами, сетку-базу-итд. Не надо этого делать. Давай обсудим твоё понимание необходимости доносить все свои задачи до менеджента, объяснять и отстаивать свою позицию. Начинай.

Здравствуйте, IT, Вы писали:

I>>Для справки: коммуникация — взаимодействие с другими сотрудниками, коллегами.
IT>Ты это определил по-другому, а именно (повторяю ещё раз) — "его задача донести до менеджмента, объяснить, отстоять свою позицию".

Мы разбираем кейс, когда некто запрещает топик-стартеру делать рефакторинг: "И навсегда забыть про рефакторинг, потому что он "не увеличивает business value""
Соответсвенно, далее топик стартер утверждает, что менеджер должен сам всё понять, а если не понял — некомпетентный идиот.

Соответсвенно, процитированая тобой фраза это не определение коммуникации, а ожидания от разработчика в конкретном разговоре. Поскольку разговор состоялся, то девелоперу необходимо рассказать за себя, т.к. рефакторинг это именно его видение, а не естественное положение вещей про которое все менеджеры в курсе дел.

Забавно, что я задал тебе один и тот же вопрос трижды, но ты так и не смог ответить

Вот новый сотрудник наткнулся на паскудство в коде и продолжать задачу не может, тк. решение вне его зоны ответственности(работа ведь поделена).
Как ему быть? Что конкретно ему надо делать?

Ну что, ты уже нашел ответ?

IT>Теперь ты пытаешься заменить это определение на очевидные вещи. Засунуть сюда ежедневное общение с коллегами, сетку-базу-итд. Не надо этого делать. Давай обсудим твоё понимание

Свое понимание я уже расписал примерно тремя десятками сообщений, где подробно расписал как именно и по каким вопросам девелопер общается с менеджером.
При этом заметно, что ты как то старательно игнорируешь вопросы.
Попробуй начать с ответа на вопрос выше.

> необходимости доносить все свои задачи до менеджента, объяснять и отстаивать свою позицию. Начинай.

Где ты увидел у меня "доносить все свои задачи" ? На секундночку — ссылкой, а то у меня ощущение что мы имеем дело с твоими иллюзиями.

Здравствуйте, DenisCh, Вы писали:

C>>>Почему это?
НС>>По определению

DC>А можно определение рефакторинга?

Вот интересно, что мешает открыть Фаулера да прочесть?

Здравствуйте, Ikemefula, Вы писали:

I>Необходимость рефакторинга — это видение девелопера. Это он видит проблему и это его задача донести до менеджмента, объяснить, отстоять свою позицию. А задача менеджера — понять, какие краткосрочные и долгосрочные риски/издержки/бенефиты это несет.

Ну, вообще-то нет. То, что код периодически нуждается в рефакторинге, это общеизвестно. Это как сортиры в макдональдсе мыть, их надо мыть по расписанию, а не ждать, пока по полу потечет (а если неожиданно по полу потекло, то мыть дополнительно). Поэтому там и уборщиков нанимают заблаговременно и в нужном количестве, а не мобилизируют из имеющегося персонала в авральном порядке.

I>Если девелопер говорит про красивость кода, то менеджер ожидаемо ничего не поймет.

Есть мнение, что если код содержать в порядке, то уменьшишь затраты на поддержку и риски, связанные с потерей контроля над собственным кодом.

Здравствуйте, Codealot, Вы писали:

C>Никто и не требует от него знать тонкости работы с платформой, например. Однако, если ПМ не имеет вообще ни малейшего представления о процессе программирования и не в состоянии спросить "в чем конкретно заключается некрасивость" и понять ответ, то за каким хреном он вообще нужен в компании? Играть в сапер и протирать кресло жопой?

Работа ПМ заключается в том, чтобы выработать процесс производства, с учетом особенностей проекта и команды, и следить, чтобы он выполнялся.

Если ты объясняешь ПМ, что код сделался некрасивым, разумный ПМ задумается о том, что надо изменить в процессе, чтобы код не делался некрасивым. Или придет к выводу, что избежать этого нельзя, и заложит в расписание периодическое приведение кода в порядок.

В чем конкретно заключается некрасивость, ПМу знать не обязательно. Ему важно знать, кто может дать объективную оценку красивости, и кто может некрасивость исправить. Конечно, в маленьких командах ПМ может совмещать должность ПМа и старшего разработчика. Но может и не совмещать.

Здравствуйте, Pzz, Вы писали:

Pzz> Поэтому там и уборщиков нанимают заблаговременно и в нужном количестве, а не мобилизируют из имеющегося персонала в авральном порядке.

Я бы не был в этом так уверен

Здравствуйте, Pzz, Вы писали:

I>>Необходимость рефакторинга — это видение девелопера. Это он видит проблему и это его задача донести до менеджмента, объяснить, отстоять свою позицию. А задача менеджера — понять, какие краткосрочные и долгосрочные риски/издержки/бенефиты это несет.

Pzz>Ну, вообще-то нет. То, что код периодически нуждается в рефакторинге, это общеизвестно.

Как именно менеджер узнает, что затраты на конкретный рефакторинг окуптся в долгосрочной/краткосрочной перспективе?

Как ему узнать про риски? Самому в код залезть?

Ну вот релиз — а тут девелопер утверждает, что де код некрасивый, надо рефакторить, а там будет видно, можно ли релизить.

I>>Если девелопер говорит про красивость кода, то менеджер ожидаемо ничего не поймет.

Pzz>Есть мнение, что если код содержать в порядке, то уменьшишь затраты на поддержку и риски, связанные с потерей контроля над собственным кодом.

Менеджер должен родиться с таким знанием? Два девелопера договориться не могут — одному нормально, другому — говно. Каким чудом менеджер поймет, чье мнение ближе к истине?

Здравствуйте, Ikemefula, Вы писали:

Pzz>>Ну, вообще-то нет. То, что код периодически нуждается в рефакторинге, это общеизвестно.

I>Как именно менеджер узнает, что затраты на конкретный рефакторинг окуптся в долгосрочной/краткосрочной перспективе?

Как доктор узнает, что почки находятся в животе, а глаза — на голове? Обычно их этому учат...

I>Ну вот релиз — а тут девелопер утверждает, что де код некрасивый, надо рефакторить, а там будет видно, можно ли релизить.

Рефакторинг — такая же часть разработки, как и все прочие манипуляции с кодом.

Обычно когда готовится релиз, то релизная ветка замораживается, и туда идет только то, что должно попасть в релиз, а все прочие телодвижения делаются в девелоперской ветке. Да, иногда приходится перетаскивать некоторые изменения между ними (к примеру, если в девелоперской ветке пофиксили серьезную багу, которая есть и в релизной ветке, есть смысл фикс туда перенести, несмотря на заморозку, чтобы потом срочно отдельным релизом бакфикс не выпускать).

I>Менеджер должен родиться с таким знанием? Два девелопера договориться не могут — одному нормально, другому — говно. Каким чудом менеджер поймет, чье мнение ближе к истине?

Обычно эта проблема решается путем выработки корпоративных стандартов качества кода.

Здравствуйте, Pzz, Вы писали:

I>>Как именно менеджер узнает, что затраты на конкретный рефакторинг окуптся в долгосрочной/краткосрочной перспективе?

Pzz>Как доктор узнает, что почки находятся в животе, а глаза — на голове? Обычно их этому учат...

Доктор непосредственно работает с проблемой, смотрит именно в медицинские артефакты — анализы, снимки, анамнез и тд.
Похоже, ты намекаешь, что менеджер в код должен смотреть?
Менеджер нынче вообще в код не смотрит. Более того, он может не обладать техническим бекграундом и это не мешает выпускать успешные проекты.
Отсюда не ясно, как ему узнать про затраты, риски, бенефиты.

I>>Ну вот релиз — а тут девелопер утверждает, что де код некрасивый, надо рефакторить, а там будет видно, можно ли релизить.

Pzz>. Да, иногда приходится перетаскивать некоторые изменения между ними

Как менеджеру узнать про риски и бенефиты этого перетаскивания?

I>>Менеджер должен родиться с таким знанием? Два девелопера договориться не могут — одному нормально, другому — говно. Каким чудом менеджер поймет, чье мнение ближе к истине?

Pzz>Обычно эта проблема решается путем выработки корпоративных стандартов качества кода.

Общие слова, ни о чем. Никакой стандарт не может разрешить такие разногласия.

Здравствуйте, Ikemefula, Вы писали:


Pzz>>Есть мнение, что если код содержать в порядке, то уменьшишь затраты на поддержку и риски, связанные с потерей контроля над собственным кодом.

I>Менеджер должен родиться с таким знанием? Два девелопера договориться не могут — одному нормально, другому — говно. Каким чудом менеджер поймет, чье мнение ближе к истине?
у менеджеров работа такая, в условиях неполной определенности и потенциально неточных мнений специалистов принимать решения. здесь нет точного алгоритма как это делать.
примерно также как менеджер при приеме на работу делает выбор между кандидатами или когда разные эксперты по какому-то вопросу озвучивают разные мнения и менеджеру/руководителю надо
определиться чьё мнение более верно и тп.

Здравствуйте, MadHuman, Вы писали:

Pzz>>>Есть мнение, что если код содержать в порядке, то уменьшишь затраты на поддержку и риски, связанные с потерей контроля над собственным кодом.

I>>Менеджер должен родиться с таким знанием? Два девелопера договориться не могут — одному нормально, другому — говно. Каким чудом менеджер поймет, чье мнение ближе к истине?
MH>у менеджеров работа такая, в условиях неполной определенности и потенциально неточных мнений специалистов принимать решения. здесь нет точного алгоритма как это делать.

Это снова непойми что. Каким образом менеджер узнает о рисках, бенефитах, проблемах, затратах? У него особый орган или отдел в мозгу, антена для телепатии?