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

C>>Ты считаешь, что разбираешься в вопросах неврологии лучше врачей-специалистов?
_AB>Нет, я считаю, что лучше тебя разбираюсь в вопросах интервью и связанных с ними законов, в том числе и касающихся инвалидов.

Это не тот вопрос, который я задал, так что не уклоняйся. Ты утверждаешь, что разбираешься в вопросах неврологии лучше врачей-специалистов? Отвечай прямо, без увиливаний — да или нет.

_AB>Впрочем, я доказал это в прошлый раз прямыми цитатами, на которые тебе не удалось ничем существенным возразить, насколько я помню.

Память тебя подводит.

_AB>А еще я знаю, что "врачи-специалисты" бывает за деньги выдают инвалидность всяким проходимцам. Я уж молчу о "враче-специалисте", который в прошлом месяце поставил моему брату двоюродному диагноз тонзиллит, при том, что ему гланды удалили два месяца назад.

А еще бывают люди, которые ничего конкретно о ситуации не знают, но считают себя вправе разбрасываться очень серьезными обвинениями. Не буду указывать пальцем.
Я например не говорю что ты педофил и растлитель детей, хотя такие люди несомненно есть и нисколько не исключено, что ты один из них. Хотя было бы очень интересно посмотреть, как ты доказываешь, что ты не верблюд.

_AB>В отличие от тебя — да.

Докажи. Оба утверждения. А то пока я от тебя ничего кроме балабольства не видел.

_AB>Да нет. Точно в цель.

Мастер хрустального шара, сразу видно.

_AB>Научить писать на С++ — не возьмусь. Банально потому, что С++ — не моя область совершенно.

Выбирай любую другую аналогичную по сложности.

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

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

А кто сказал, что он должен это делать?

Здравствуйте, no_ise, Вы писали:
_>Может быть в этом причина? Т.е. юрист кроме всего прочего знал какой-то, предположим, известный гуманитариям способ избавления окружающих от страданий?
Нет, просто технические навыки в управлении проектами второстепенны. Никаких специальных секретов юристам не преподают — прекрасные руководители могут получиться из физиков, химиков, или геологов.

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

S>Это не означает, что я просто буду разрешать разработчикам списывать произвольные объёмы работ на слово "рефакторинг", потому что "я обязан понимать ценность рефакторинга самостоятельно".

Коллега, тебе надо всё же определиться — либо надеть трусы, либо снять крестик.

То есть, либо менеджер не разбирается в технической стороне вопроса, и в таком случае он делегирует технические обязанности кому-то более знающему и в микроменеджмент не лезет. Он передает девменеджеру/архитектору/тимлиду/главному-по-бараку/кому-там-еще пожелания заказчика, и в ответ получает примерный расклад по задачам, которые нужно выполнить. Если есть разные варианты реализации — значит, по нескольким вариантам. Которые он распределяет в соответствии со сроками или откладывает на потом, если сроки жмут, а задача не особо важная. Если менеджер не понимает, важна ли задача — он спрашивает про это у того, кто знает. А что написано в описании задачи — кодинг фичи Х, рефакторинг фичи У или сепулькация сепулек — его не волнует, потому что это не входит в его задачу.

Либо же он считает себя самым умным по всем вопросам и лезет решать технические вопросы сам, но в таком случае, если выбор оказался плохим — виноват только он сам. И его блеяние о том, что кто-то ему что-то недостаточно хорошо объяснил — всего лишь оправдание своей некомпетентности.

Ну и наконец, ты подменил предмет спора. Я писал не о таких случаях, когда кто-то с кем-то не договорился о том, какой рефакторинг надо делать. А о таких, когда рефакторинг не делается вообще в принципе.

S>Увы — только менеджер в курсе, обрадуются ли клиенты возможности переехать с винды на линукс или нет.

То есть твой менеджер всё же знает, чем отличается линукс от винды и чем чреват тот или иной выбор. Он не требует, чтобы ему за 5 минут все в деталях объяснили, а когда он не может понять — не устраивает истерику, что ему недостаточно хорошо объяснили.
Правильно?

S>Нет. Мой менеджер заявляет, что у всех технических вопросах есть бизнес-последствия, и именно они определяют принимаемые решения. А то, секси ли там какая-то новая технология, и нравится ли унаследованный код разработчику или нет, на решения влиять не должно. И менеджер уже достаточно стар и опытен, чтобы знать, что как раз кажущиеся очевидными вещи чаще всего и оказываются неправильными.

Такими вопросами должны заниматься кодеры от сеньора и выше, менеджера такие вопросы волновать вообще не должны. Микроменеджмент.

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

S>Здравствуйте, no_ise, Вы писали:
_>>Может быть в этом причина? Т.е. юрист кроме всего прочего знал какой-то, предположим, известный гуманитариям способ избавления окружающих от страданий?
S>Нет, просто технические навыки в управлении проектами второстепенны. Никаких специальных секретов юристам не преподают — прекрасные руководители могут получиться из физиков, химиков, или геологов.

Возвращаясь к теме топика, а что делает хороший руководитель, если ему поступает жалоба, что кого-то бомбят некорректными вопросами?

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

C>То есть рефакторинг вообще никак не планируется менеджером и он про него ничего не знает, ты хочешь сказать?

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

в прошедшем релизе выявлено много проблем, предполагается, эту часть менеджер понимает, т.к. тут KPI или внятные подтверженные факты
— сильно выросло время ожидания, время на фичу, см KPI
— слишком много трудновоспроизводимых багов, см KPI
— слишком много реопенов, см KPI
— слишком много багов из за мерж конфликтов, см KPI
— слишком большое время на пулл-реквест, см KPI
— слишком много мелких багов связаных с A..Z, см баклог
Анализ показывает
— работа блокируется из за кривого дизайна — если один меняет А, другие ждут его изменений, аналогично с B, C ... Z
— мерж-конфликты — слишком много изменений в чужих местах
— логирование, диагностика, телеметрия, инструментирование не выполняет свою функцию
— кривой API для логирования, диагностики, телеметрии, инструментирования итд
— кривой дизайн API для операций дата-время, что дает трудновоспроизводимые баги
Решение:
— работу над новой версии начать с рефакторинга API A...Z, для чего надо поставить на паузе все смежные фичи
— рефакторинг делают два толстых и лысых сеньора
— остальные во время рефакторинга девелоперы переключаются на тесты или инвестигируют тикеты от суппорта
— после рефакторинга все девелоперы фиксают баклог по вещам связаным с логированием, диагностике, телеметрии, инструментированию и тд
— по окончанию багфикса делаем бакпорт в релиз-бранч 24.0.0 и выкатываем патч 24.0.1, тикеты от суппорта фиксаем в 24.0.2 если они будут релевантны к тому времени.
— бакпорт можно не делать, но тогда суппорту говорим "до свидания"

I>>Похоже, хамство это один из основных твоих аргументов

C>Не больше, чем твой и многих других здесь. Даже намного меньше, на самом деле.

Ога!
У тебя 4 нарушения в пересчете на 1000 сообщений, у меня — меньше двух.
У тебя 4 нарушения за 9 месяцев, у меня 3 в год в среднем, при этом за два последних года всего 3 нарушения

Вобщем, ты всеми силами рвёшься в лидеры. Давай, покажи уже всем!!!111

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

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

C>А кто сказал, что он должен это делать?

При неправильном подходе он может это делать и иногда таки делает. Одна из целей — проводить его так, что бы этих задержек не было.

Здравствуйте, Codealot, Вы писали:
C>Коллега, тебе надо всё же определиться — либо надеть трусы, либо снять крестик.

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

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

C>А что написано в описании задачи — кодинг фичи Х, рефакторинг фичи У или сепулькация сепулек — его не волнует, потому что это не входит в его задачу.
Примерно так. Его волнуют наблюдаемые результаты и зависимости.
Например, кодинг от рефакторинга принципиально отличаются тем, что после кодинга у пользователей появится некоторая функциональность, которой раньше не было, а в результате рефакторинга — нет, не появится.

C>Либо же он считает себя самым умным по всем вопросам и лезет решать технические вопросы сам, но в таком случае, если выбор оказался плохим — виноват только он сам. И его блеяние о том, что кто-то ему что-то недостаточно хорошо объяснил — всего лишь оправдание своей некомпетентности.
Менеджер не считает себя самым умным, но ответственность несёт именно он. Если проект будет провален потому, что кодеры занимались рефакторингом вместо того, чтобы приносить пользу, то менеджера трахнут. А кодеров просто переведут на другой проект — они же не делали ничего плохого; им утвердили задачу рефакторить, они и рефакторили.
Поэтому таки да, хороший менеджер всегда спрашивает у технических специалистов про последствия тех или иных решений. Но берёт ответственность за решения на себя.

C>Ну и наконец, ты подменил предмет спора. Я писал не о таких случаях, когда кто-то с кем-то не договорился о том, какой рефакторинг надо делать. А о таких, когда рефакторинг не делается вообще в принципе.
Ну, во-первых, из обсуждения непонятно, "вообще в принципе" или "просто в конкретных случаях не делается".
Во-вторых, любые "рефакторинг не делается никогда" состоят из отдельных "нет, вот этот рефакторинг мы делать не будем". У каждого из которых могут быть причины.
В-третьих, нет ничего плохого в том, что рефакторинг не делается вообще никогда в принципе. У рефакторинга самостоятельной ценности нету. Если из-за этого отказа рефакторить страдают какие-то наблюдаемые характеристики — то это одна история, а если нет — то совсем другая.
Да, я могу себе представить тупого менеджера, который сначала принимает решение выбрать из двух способов решения задачи более дешёвый и грязный, типа "завайте сейчас захачим, а порефакторим в следующем релизе", а в следующем релизе отказывается рефакторить, т.к. мало ли что там обсуждалось ранее. Ну, как бы даже этот менеджер рано или поздно упрётся в то, что дальнейшие "полезные" изменения стоят всё больше и больше, и будет вынужден одобрить рефакторинг.
А если нет — то, значит, и рефакторинг в данном проекте вовсе не так полезен, как кажется на первый взгляд.

C>То есть твой менеджер всё же знает, чем отличается линукс от винды и чем чреват тот или иной выбор.
В каком смысле "знает"? С тем же успехом можно обсуждать переход с бензина на газ или с 95 на дизель. С точки зрения управленческой науки — ровно то же самое. Заказчику нужно, чтоб работало на газу, мы поставляем движки на бензине.
Всё, что нужно знать — это что нельзя заправлять газом бензиновый движок, и стоимости переоборудования в ту или иную сторону.
"Чреватость" в данном случае — это выполнение либо невыполнение требований заказчика.

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

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

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

Здравствуйте, no_ise, Вы писали:
_>Возвращаясь к теме топика, а что делает хороший руководитель, если ему поступает жалоба, что кого-то бомбят некорректными вопросами?
Ваш вопрос непонятен. Что делает руководитель, если его подчинённый жалуется на то, что не может устроиться на другую работу, из-за того, что там задают некорректные вопросы?
Разбирается, чем занят этот сотрудник, ценен ли он, и нужно ли прилагать усилия к его удержанию, или, наоборот, спланировать замену. В общем, стандартный подход к ситуации "сотрудник хочет уйти".

Если "некорректные вопросы" происходят внутри компании — то разбирается в деталях: что за вопросы, от кого, почему. Вариантов может быть очень много. И только разобравшись, он принимает решение.

Вообще, по классике, у менеджера выбор действий невелик. Что бы ни происходило, менеджер может:

1. Нанять сотрудника
2. Уволить сотрудника
3. Поставить сотруднику задачу
4. Поощрить сотрудника

Это примерно как автомобиль: что бы ни происходило, водитель может работать только газом, тормозом, коробкой и рулём. А также подавать световые и звуковые сигналы.
Из этого складываются такие сложные вещи, как "уступить дорогу", "выполнить обгон" и прочие шедевры водительского мастерства.

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

S>Здравствуйте, no_ise, Вы писали:
_>>Возвращаясь к теме топика, а что делает хороший руководитель, если ему поступает жалоба, что кого-то бомбят некорректными вопросами?
S>Ваш вопрос непонятен. Что делает руководитель, если его подчинённый жалуется на то, что не может устроиться на другую работу, из-за того, что там задают некорректные вопросы?
S>Разбирается, чем занят этот сотрудник, ценен ли он, и нужно ли прилагать усилия к его удержанию, или, наоборот, спланировать замену. В общем, стандартный подход к ситуации "сотрудник хочет уйти".

S>Если "некорректные вопросы" происходят внутри компании — то разбирается в деталях: что за вопросы, от кого, почему. Вариантов может быть очень много. И только разобравшись, он принимает решение.

S>Вообще, по классике, у менеджера выбор действий невелик. Что бы ни происходило, менеджер может:

S>1. Нанять сотрудника
S>2. Уволить сотрудника
S>3. Поставить сотруднику задачу
S>4. Поощрить сотрудника

S>Это примерно как автомобиль: что бы ни происходило, водитель может работать только газом, тормозом, коробкой и рулём. А также подавать световые и звуковые сигналы.
S>Из этого складываются такие сложные вещи, как "уступить дорогу", "выполнить обгон" и прочие шедевры водительского мастерства.

Да, немножко общо формулирую. Мне вот что непонятно: тс уже давно не поддерживает тему, а тема активно развивается. Значит, как минимум, есть в постановке
вопроса что-то, что волнует многих.

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

S>Всё ещё остаётся непонятным, что считается "технической стороной вопроса".

Странный вопрос.

S>Вот здесь под тем, кто знает — кто подразумевается?

Менеджер сам решает, у кого он хочет спросить. Это его работа

S>Примерно так. Его волнуют наблюдаемые результаты и зависимости.
S>Например, кодинг от рефакторинга принципиально отличаются тем, что после кодинга у пользователей появится некоторая функциональность, которой раньше не было, а в результате рефакторинга — нет, не появится.

Любой человек, если он не полный идиот, знает, что у многих действий результат проявляется не сразу, а через какое-то время.

S>Менеджер не считает себя самым умным, но ответственность несёт именно он. Если проект будет провален потому, что кодеры занимались рефакторингом вместо того, чтобы приносить пользу, то менеджера трахнут. А кодеров просто переведут на другой проект — они же не делали ничего плохого; им утвердили задачу рефакторить, они и рефакторили.
S>Поэтому таки да, хороший менеджер всегда спрашивает у технических специалистов про последствия тех или иных решений. Но берёт ответственность за решения на себя.

Это хороший менеджер, который встречается почти так же редко, как белый слон. А типичный менеджер — обвинит во всем программистов, которые "недостаточно хорошо ему объяснили" (С) и заставит работать сверхурочно.

S>Ну, во-первых, из обсуждения непонятно, "вообще в принципе" или "просто в конкретных случаях не делается".

Непонятно только тому, кто его вообще не читал. Я с самого начала написал о случаях, когда рефакторинг не делается вообще.

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

И это — типичнейшая картина, глядя на обычный распространенный софт.

S>В каком смысле "знает"? С тем же успехом можно обсуждать переход с бензина на газ или с 95 на дизель. С точки зрения управленческой науки — ровно то же самое. Заказчику нужно, чтоб работало на газу, мы поставляем движки на бензине.
S>Всё, что нужно знать — это что нельзя заправлять газом бензиновый движок, и стоимости переоборудования в ту или иную сторону.
S>"Чреватость" в данном случае — это выполнение либо невыполнение требований заказчика.

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

S>Кодер, который разбирается во всех аспектах разработки, от юридических и эстетических до финансовых и литературных — штука хорошая, но в природе почти не встречается.
S>Проще нанять менеджера, который будет заниматься всеми вопросами взаимодействия, а кодер будет заниматься своим делом — писать код.

Гениально. Это именно то, что я недавно и писал.

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

I>При неправильном подходе он может это делать и иногда таки делает. Одна из целей — проводить его так, что бы этих задержек не было.

Значит, просто не делай его неправильно

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

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

То есть, программист просто делает любой не-глобальный рефакторинг по своему усмотрению, и никому ничего не обязан по этому поводу объяснять?

I>У тебя 4 нарушения в пересчете на 1000 сообщений, у меня — меньше двух.
I>У тебя 4 нарушения за 9 месяцев, у меня 3 в год в среднем, при этом за два последних года всего 3 нарушения

А модераторы, как известно, выше всяких подозрения в пристрастности? Есть тут один чувак, так он постоянно всем хамит и как-то незаметно, чтобы это приводило к последствиям.

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

C>То есть, программист просто делает любой не-глобальный рефакторинг по своему усмотрению, и никому ничего не обязан по этому поводу объяснять?

Предлагаешь писать заявление, собирать консилиум, созывать митинг ради переименования переменной? Голосование ?

Есть код ревью. Следовательно, команда без менеджера может разобраться, что надо, в что не надо для фикса.
Кроме того — есть тим лид. Есть сеньоры, есть архитекторы.
На кой ляд пиэму лезть внутрь и выяснять, что к чему?

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

А у тебя выходит так, что пиэм работает вместо этих лиц.

I>>У тебя 4 нарушения в пересчете на 1000 сообщений, у меня — меньше двух.
I>>У тебя 4 нарушения за 9 месяцев, у меня 3 в год в среднем, при этом за два последних года всего 3 нарушения

C>А модераторы, как известно, выше всяких подозрения в пристрастности?

Так ты уже решил бороться с системой? Или их косяки тебя оправдывают?

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

I>>При неправильном подходе он может это делать и иногда таки делает. Одна из целей — проводить его так, что бы этих задержек не было.

C>Значит, просто не делай его неправильно

Спасибо, капитан

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

I>На кой ляд пиэму лезть внутрь и выяснять, что к чему?

Ну откуда мне знать, на кой ляд они нередко лезут?

А ты не припоминаешь, кто недавно написал вот это?

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

I>Или их косяки тебя оправдывают?

В вопросе о числе нарушений — безусловно.

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

I>Спасибо, капитан

Всегда рад помочь тем, кто в этом нуждается

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


C>>То есть, либо менеджер не разбирается в технической стороне вопроса, и в таком случае он делегирует технические обязанности кому-то более знающему и в микроменеджмент не лезет.
S>Всё ещё остаётся непонятным, что считается "технической стороной вопроса".
Технический долг, например. Менеджер про него ничего не знает и не может оценить.

C>>А что написано в описании задачи — кодинг фичи Х, рефакторинг фичи У или сепулькация сепулек — его не волнует, потому что это не входит в его задачу.
S>Примерно так. Его волнуют наблюдаемые результаты и зависимости.
S>Например, кодинг от рефакторинга принципиально отличаются тем, что после кодинга у пользователей появится некоторая функциональность, которой раньше не было, а в результате рефакторинга — нет, не появится.
Не обязательно, может и получиться. Никто не мешает добавлять фичи переписывая код.

C>>Либо же он считает себя самым умным по всем вопросам и лезет решать технические вопросы сам, но в таком случае, если выбор оказался плохим — виноват только он сам. И его блеяние о том, что кто-то ему что-то недостаточно хорошо объяснил — всего лишь оправдание своей некомпетентности.
S>Менеджер не считает себя самым умным, но ответственность несёт именно он. Если проект будет провален потому, что кодеры занимались рефакторингом вместо того, чтобы приносить пользу, то менеджера трахнут. А кодеров просто переведут на другой проект — они же не делали ничего плохого; им утвердили задачу рефакторить, они и рефакторили.
S>Поэтому таки да, хороший менеджер всегда спрашивает у технических специалистов про последствия тех или иных решений. Но берёт ответственность за решения на себя.

S>А если нет — то, значит, и рефакторинг в данном проекте вовсе не так полезен, как кажется на первый взгляд.
Это реально катастрофа для проекта. Технический долг накапливается медленнно и рефакторинг, с точки зрение бизнеса, никогда не будет выглядеть полезным. В результате все превращается в болото говнокода.

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


I>>На кой ляд пиэму лезть внутрь и выяснять, что к чему?

C>Ну откуда мне знать, на кой ляд они нередко лезут?

Так делают
1 плохие пиэмы из бывших разработчиков
2 функциональные менеджеры

C>А ты не припоминаешь, кто недавно написал вот это?
C>

Разумеется. И я подробно расписал, кто за что отвечает.
Понять девелопера вовсе не значит лезть в код.
Девелопер обязан уметь изъясняться в единицах business value, а не словами из кода, иначе он просто джун.

I>>Или их косяки тебя оправдывают?

C>В вопросе о числе нарушений — безусловно.

Это доказывает, что ты решил кому то там уподобиться

Здравствуйте, Poopy Joe, Вы писали:
PJ>Технический долг, например. Менеджер про него ничего не знает и не может оценить.
Оценка тех.долга — задача инженера. Принятие решения о его возврате — задача менеджера.
Точно так же, как исполнительный директор не обязан разбираться в финансовом анализе — это финдир ему объясняет, какие последствия будут у решения "вернуть часть кредита досрочно".

PJ>Не обязательно, может и получиться. Никто не мешает добавлять фичи переписывая код.
Нет. По определению, рефакторинг не изменяет функциональность.
А вот с точки зрения управления технической задолженностью, списывать затраты на рефакторинг лучше вместе с затратами на фичи.

PJ>Это реально катастрофа для проекта. Технический долг накапливается медленнно и рефакторинг, с точки зрение бизнеса, никогда не будет выглядеть полезным. В результате все превращается в болото говнокода.
Ну, во-первых, не факт, что это плохо. Если продукт продаётся, и прибыль покрывает затраты, то хрен с ним с говнокодом. Это неожиданный результат для инженера, но с т.з. стратегического планирования всё может быть Ок.
Например, мы можем идти к acquisition deal — то есть нам надо раздуть продажи, и минимизировать все затраты на обслуживание кода. После того, как мы получим свой миллиард кэшем, говнокод станет проблемой нового владельца и его команды.

Если инженер подозревает, что его-то как раз возьмут и дальше работать над этим кодом в новую компанию, то это — его проблема; ему лучше научиться делать рефакторинг так, чтобы его на этом не поймали

Во-вторых, есть традиционные ошибки менеджмента, которые возникают при вот таком вот "краткосрочном планировании". Я их называю "мат в два хода": когда принимаются два решения, каждое из которых выглядит вполне приемлемым, но результат получается недостаточно хорошим.
Типа: вот, есть у нас, допустим, баг. Который затрагивает какого-то важного клиента, и стоит им денег прямо каждый день. Нормальный фикс его требует значительных затрат — нужна согласованная работа нескольких команд, всё такое.
Делаются оценки, фикс ставится в следующий релиз. У него, естественно, приоритет "критикал", т.к. штука очень важная.
Возникает естественный вопрос: а нельзя ли как-то помочь клиенту сейчас, а не через полгода? Инженеры говорят: "ну, есть кривоватый workaround — давайте мы на коленке сварганим патч для конкретного клиента. Он будет откачен при следующем же минорном апгрейде, и в нём будут захардкожены параметры конкретного клиента, чтобы не тратить время на изменения в модуле конфигурации, документацию, локализацию, и т.п. Зато партнёр сможет работать уже с понедельника".
Отлично — мы принимаем решение выкатить этот патч; партнёр морщится, но ставит, т.к. проблема реально важная; другого варианта нет; и ему пообещали, что через полгода-то выйдет версия с нормальным решением.

Через квартал, когда просматривается бэклог на следующий релиз, приоритет фиксу снижают до "нормал", т.к. "ну есть же w/a, и бага затрагивает только одного клиента".
В итоге, фикс, естественно, в скоуп релиза так и не попадает — у нас тем временем продолжают валиться баги с приоритетами "мажор", для которых срочные w/a не делаются за ненадобностью, и их выдвигать нельзя.
Партнёру говорят "ну, так бывает — мы пересмотрели наши приоритеты, и были вынуждены отложить решение вашей проблемы на потом".

То есть уже в этот момент у нас парадоксальный результат: в новом релизе починены менее важные баги ровно потому, что самый жир был заклеен заплатками.

Ещё через полгода баг вообще может быть закрыт как won't fix — потому что "есть w/a, жалоб в течение года не поступало".

Есть два способа выйти из этого порочного круга:
1. Самый простой — говорим "нет, мы не будем делать workaround".
Дождёмся эскалации от партнёра, и тогда глава департамента подпишет любые затраты, включая выпуск мейнтенанс-версии всего продукта вне графика.
И нам не придётся тратить месяц, уговаривая его выделить нам неделю ресурсов.

2. Более сложный: убедить руководство, что так делать нельзя — к примеру, убрать правило про снижение приоритета багам с workaround-ами.

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