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

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

C>Если он не знает, что делает — результат работы получается вполне опеределенным. Кроме тех случаев, когда работу за него делает кто-то другой, а он просто протирает кресло.

Ты зачем то повторяешь тривиальные вещи. Как это относится к аргументам "некрасивый код" со стороны девелопера?

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

I>Как это относится к аргументам "некрасивый код" со стороны девелопера?

Похоже, ты уже забыл, что этот "аргумент" ты сам высосал из пальца.

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

I>>Как это относится к аргументам "некрасивый код" со стороны девелопера?

C>Похоже, ты уже забыл, что этот "аргумент" ты сам высосал из пальца.

Читаем вместе, твой аргумент:
"И навсегда забыть про рефакторинг, потому что он "не увеличивает business value" @ Codealot

А вот мой:
"Рефакторинг увеличивает business value. " @ Ikemefula

Вобщем, твой рабочий день представляется мне таким образом:
Менеджер: — Нахрена нам рефакториг, какой тут business value ?
Codealot: — Код говноой, ну, некрасивый, надо переписать, ну хотя бы отрефакторить!
Менеджер: — Я не вижу в этом business value, отказать!
Codealot(в туалете): — Да ты ваще горе-менеджер! Ты должен понимать людей! Ты должен уточняющие вопросы задавать! Ты должен сам понимать откуда здесь business value! Ты идиот некомпетентный! Да я уеду из этой страны!
Codealot(дома): — Эй, на рсдн, подскажите, как мне обойтипройти обес в Штатах?

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

ry>И это абсолютно правильный и адекватный подход.
Не всегда. Бывают случаи что старый код проще выкинуть и написать заново. У меня был не единичный опыт когда люди фиксили заплатками проблемы 3-4 года которые в итоге вылезали вновь вместо того, чтобы просто поменять архитектуру и избавится от проблемы в корне, переписав код по нормальному.

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

I>Менеджер: — Нахрена нам рефакториг, какой тут business value ?

То есть, твой гипотетический ПМ не знает, что такое рефакторинг и зачем он нужен. Будешь оспаривать?

I>Codealot: — Код говноой, ну, некрасивый, надо переписать, ну хотя бы отрефакторить!

А это ты уже из пальца высосал, я такого не писал.

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

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

I>>Менеджер: — Нахрена нам рефакториг, какой тут business value ?

C>То есть, твой гипотетический ПМ не знает, что такое рефакторинг и зачем он нужен. Будешь оспаривать?
Есть далеко ненулевое множество так называемых программистов, которые под рефакторингом понимают "переделать всё просто потому что оно не в моём вкусе".

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

I>>Менеджер: — Нахрена нам рефакториг, какой тут business value ?

C>То есть, твой гипотетический ПМ не знает, что такое рефакторинг и зачем он нужен. Будешь оспаривать?

Я уже отвечал на такой вопрос. Менеджер, например, занят организацией, в частности, планированием вещей, которые имеют business value. Задача девелопера — описать проблему в единицах business value. Рефакторинг — инструмент, которым решается проблема. Применение инструмента нужно обосновать. То есть — указать на проблему у которой всегда есть business value. Соответственно менеджеру нужно понимать, какой из business value больше, приоритетнее и тд. В инструментах ему нет никакого смысла разбираться.

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

I>>Codealot: — Код говноой, ну, некрасивый, надо переписать, ну хотя бы отрефакторить!

C>А это ты уже из пальца высосал, я такого не писал.

Ты написал, что у рефакторинга нет business value. Из этого следует, что под рефакторингом ты понимаешь ненужную вкусовщину, то есть — некрасивый код.

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

C>>А это ты уже из пальца высосал, я такого не писал.

I>Ты написал, что у рефакторинга нет business value. Из этого следует, что под рефакторингом ты понимаешь ненужную вкусовщину, то есть — некрасивый код.
Он ко мне 'в личку' пришёл и именно так описал рефакторинг

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

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

C>>>А это ты уже из пальца высосал, я такого не писал.

I>>Ты написал, что у рефакторинга нет business value. Из этого следует, что под рефакторингом ты понимаешь ненужную вкусовщину, то есть — некрасивый код.
D>Он ко мне 'в личку' пришёл и именно так описал рефакторинг

Эпидемия какая то. Люди понимают рефакторинг, как улучшайзер, просто заимствовали модное слово

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

C>>Как-то так

H>А разгребание говнокода — это не рефакторинг? Я-то думал, что из говнокода сделать понятную систему с грамотной архитектурой это рефакторинг и есть.

Это крайне полезная вещь, но с рефакторингом у неё ничего общего. Рефакторинг это один из инструментов которые позволяют решать конкретные проблемы.

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

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

Если качество никого не интересует, а работу можно делать хоть годами, хоть десятилетиями, то можно и так. Зачем стараться ?

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

H>>Я-то думал, что из говнокода сделать понятную систему с грамотной архитектурой это рефакторинг и есть.

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

И кто же у тебя эти "они", которые "не дадут" качественно работу сделать?

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

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

I>Если качество никого не интересует, а работу можно делать хоть годами, хоть десятилетиями, то можно и так. Зачем стараться ?
Что значит, никого не интересует. Зачем утрировать. Одному красоту подавай незнамо за чей счёт, тебе чего подать?

С заказчиком согласовываются три главные параметра: бюджет, сроки и качество.
Если проект в текущем виде удовлетворяет им, то нефиг расходовать ресурсы. Если же качество решения стало влиять как на сроки, так и прямо и/или косвенно на бюджет, то менеджмент обязан выделить ресурсы на устранение проблем. Будет ли это рефакторинг кода и/или архитектуры, привлечение к проекту более опытных разработчиков или смена менеджмента проекта — решение этих вопросов, очевидно, находится на разных уровнях управления.

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

ry>С заказчиком согласовываются три главные параметра: бюджет, сроки и качество.

Именно!

ry>Если проект в текущем виде удовлетворяет им, то нефиг расходовать ресурсы.

А как ты эту гарантию получить собрался? Вот твоя методология:

"добавлению новых фич костыльно-подпорочным методом и замазыванию дыр при помощи говна и палок. "

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

Где гарантия, что замазывая дыру экскрементами ты не добавишь десять скрытых дыр?

Или что фича из костылей, как убедиться, что она выдержит какой нибудь нечастый но трудный кейс?

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

И где причину искать? Девелоперы плохо работают, или код упоротый. Как понять?

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

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

ry>>С заказчиком согласовываются три главные параметра: бюджет, сроки и качество.

I>Именно!

ry>>Если проект в текущем виде удовлетворяет им, то нефиг расходовать ресурсы.

I>А как ты эту гарантию получить собрался? Вот твоя методология:

I>"добавлению новых фич костыльно-подпорочным методом и замазыванию дыр при помощи говна и палок. "

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

I>Где гарантия, что замазывая дыру экскрементами ты не добавишь десять скрытых дыр?

I>Или что фича из костылей, как убедиться, что она выдержит какой нибудь нечастый но трудный кейс?

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

I>И где причину искать? Девелоперы плохо работают, или код упоротый. Как понять?

Называется "Управление проектами". Там есть ответы на эти вопросы.

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

D>Есть далеко ненулевое множество так называемых программистов, которые под рефакторингом понимают "переделать всё просто потому что оно не в моём вкусе".

Это не отменяет того факта, что данный гипотетический (или не гипотетический) ПМ не знает, что такое рефакторинг и зачем он нужен.

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

D>Он ко мне 'в личку' пришёл и именно так описал рефакторинг

Щито? Ни в какую личку я тебе не приходил.

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

I>Я уже отвечал на такой вопрос. Менеджер, например, занят организацией, в частности, планированием вещей, которые имеют business value.

Откуда такое странное определение?

I> В инструментах ему нет никакого смысла разбираться.

Не барское это дело — понимать задачи, с которыми ты работаешь.

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

I>И кто же у тебя эти "они", которые "не дадут" качественно работу сделать?

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

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

I>>Я уже отвечал на такой вопрос. Менеджер, например, занят организацией, в частности, планированием вещей, которые имеют business value.

C>Откуда такое странное определение?

Работа у менеджера такая.

I>> В инструментах ему нет никакого смысла разбираться.

C>Не барское это дело — понимать задачи, с которыми ты работаешь.

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