Хочу запилить глобальный рефакторинг

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

вспомнилось.

// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 16


)

по теме: бить на кусочки, тут же допиливать тесты.

лол, откуда инфа про 40к? Это девелоперу столько платят? Пусть тогда ТС идёт в суппорт: там хоть тыщ 60 платят.

Я конечно всё понимаю, утро, понедельник. Но чтобы заголовок пропустить…

По САБЖу: лучше убедить начальство, что рефакторинг необходим. Привести обоснования. Например то, сколько времени у тебя занимает имплементация такой-то фичи и сколько процентов из этого занимает разбирательство в этой вермишели. При этом надо заранее оценить сроки на рефакторинг и их озвучить.

оу. facepalm.pl

По САБЖу: лучше убедить начальство, что рефакторинг необходим. Привести обоснования. Например то, сколько времени у тебя занимает имплементация такой-то фичи и сколько процентов из этого занимает разбирательство в этой вермишели.

так и хочу попытаться сделать

К вопросу о деньгах, это в ДС 40к - мало, у нас это существенно выше среднего. А у меня 30к сейчас, при том что я работаю полтора года, да еще и на учебу бегаю временами

В принципе мой непосредственный начальник не против рефакторинга, но о потраченном времени он должен репортить наверх, более высокому начальству, и поэтому предлагает завести под это дело отдельную активность, а не распихивать по кусочкам в текущие (как я и делал до этого - пилим фичу, тут поправил, там переписал, не сломалось, вот и хорошо). Но в таком случае придется либо делать все скопом в одной активности, либо пытаться разбить на несколько более мелких независимых активностей.
Разбивать пофайлово - не вариант, во многих файлах есть дублирующиеся функции и кросс-ссылки друг на друга, от которых вобщем-то можно было бы избавиться. А как лучше сделать? К примеру, начать с того, что вынести дублирующиеся функции в либы, а потом начать по одной переписывать функции системы?

michael feathers, «working effectively with legacy code»

Спасибо. Слышал про нее, посмотрю

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

Из личного опыта. У нас в проекте много гуя (тестов, естественно, нет) и развивается очень активно, поэтому, когда нужно порефакторить (а оно там ой как нужно), то занимаюсь я этим в рамках текущей активности, причем все знают, что вот эта часть скоро будет лучше, а потом всем показываю, как именно она стала лучше. Если вижу небольшой костылик - иду узнавать у автора, зачем он это сделал. Потом провожу исследования, как все исправить, чтоб его убрать и, если есть достаточно времени, исправляю. В общем, мелкими шажками пытаюсь привести хоть какую-то часть кода в чувства...

Да я вот точно таким же занимаюсь, и пришёл к выводу, что если начальство об этом не знает, придётся работать вне рабочего времени. Короче, первым делом говори с начальником (аргументация соответственно необходима). Если начальник против - я бы ничего не делал, а оставил как есть.

Я был, лень было логиниться с телефона.

Рефакторинг без тестов - медленное самоубийство. Я уже пару раз в продакшне накосячил (замечено было не сразу), теперь сначала тесты, и только потом - рефакторинг. И хрен с ним, что до первого теста иногда проходит 3 дня.

ps Для аргументации в сторону начальства еще можно взять статистику (о стоимости багов на различных этапах разработки и тестирования) из, кажется, «Code complete».

Да, тут я с вами согласен. Но когда логика и UI - это один сплошной клубок? Как обкладывать развесистый UI тестами? Я пока ничего вменяемого не встретил, к сожалению...

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

Для начала рекомендую уже упомянутого Физерса. Если у тебя с++ и интересует мой опыт - можно по мылу.

Чужой опыт - это всегда интересно. Мне пока не приходилось легаси код обкладывать тестами, но думаю Физерс тут как раз и поможет, если есть, что добавить, подсказать, чтоб на те же грабли мне не наступать - пиши гугло-почту kultihell.

Если есть опыт в тестировании UI - тоже буду рад. Видел, как это на андроиде делается, пробовал даже. Но как только более менее сложный тест, сразу появляются проблемы с вызовами не из тех потоков, дедлоки и страшный, непрозрачный код. Для Qt видел QTestLib но пока не пробовал.

Пишу на С++, для тестов - GoogleTest

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

PS Работать по воскресеньям. Да он псих =:-/

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

marvin_yorke

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

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

marvin_yorke

Но нервов потратил бы еще больше.

Тренируйся относиться проще, тебя никто не гонит. Если у твоего начальника нет ничего кроме работы это его проблемы. Например у меня есть семья и когда меня ген. дир. позвал на совещание я попросил его перенести на среду т.к. сем обст. и все было ок. Хотя основная серая масса планктона повиновалась. Или ты думаешь что на твое место уже ждут ещё большего трудоголика? Расстаться с человеком для работодателя сложнее чем кажется и дело далеко не в законах.

хахах, «total_hours_wasted_here = 16» :) забавно

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

Тесты пишутся до: все скрипты компилятся, тест зависимостей (CPAN и соседние проекты), список функций для каждого модуля, защитное программирование - гуарды на входе (и выходе - и такое бывает) каждой функции.

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

Еще важное. Выдели логическое ядро (напиши с нуля если надо - важный опыт TDD) хорошо покрытое тестами. Вместе с низкоуровневым тулкитом (тоже исчерпывающее тестирование) поможет экономить силы на длинных дистанциях.

Весь остальной код будет считаться клиентским (плагины, быдлокод и т.д.) и тестироваться будет соответствующим образом - по остаточному принципу.

Ну и конечно «Теория и практика физического эксперимента», где под слоем окаменевшего матана, хранится самое важное из тайных знаний.

спасибо, толково. Вопрос - под гуардами что подразумевается?

40к

Комиссара на тебя нет.

После очередного проведенного на работе воскресенья

Жесть.

Да, разбей на функциональные модули и переписывай их по отдельности. Вместе с тестами.

А уже потом рефакторинг (изменение внешних интерфейсов этих модулей).

проверка данных, на входе функции и выходе, наверное

Я покажу на примере.

use Test::More;
use Test::Exception;

# конструктор new() принимает именованные параметры:
# параметр dbh - обязателен
throws_ok { $MODULE->new(); }
    qr{^key\s'dbh'\svalidation\serror:\sparameter\smust\sbe\srequired}xms,
    'конструктор new() принимает обязательный именованный параметр "dbh"';

А в теле класса, в конструкторе, стоит гуард, в декларативном стиле описывающий что пришло и падающий при любом несовпадении требуемого с действительным:

use JIP::CheckParams qw( check_named_params );

sub new {
    my ( $self, %param ) = @_;

    # именованный параметр (всегда стараюсь такие использовать) "dbh" - датабейсхэндл
    # обязателен, всегда defined, инстанс класса DBI::db
    # все это проверяется в юнит-тестах
    check_named_params(
        rules_ref  => {
            dbh => { required => 1, defined => 1, isa => 'DBI::db' },
        },
        params_ref => %param,
    );

    # далее код инстанцирующий класс
}

Слегка ошибся когда правил копипасту. Передается ссылка на хэш:

check_named_params(
    rules_ref  => {
        dbh => { required => 1, defined => 1, isa => 'DBI::db' },
    },
    params_ref => \%param,
);

ого, спасибо, давно не помню таких внятных и развернутых ответов на ЛОРе