Как аргументировать начальству создание существующего проекта заново, с ноля?

Question

[kocherginji]

Здравствуйте уважаемые коллеги.

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

Я занимаюсь Front-End разработкой + Back-End по совместительству. В проекте из основных инструментов используется Django и jQuery. Сайт (ссылку не могу дать, чтобы не причинить репутационных рисков для компании) внешне выглядит очень хорошо, но стоило залезть в код - и я ужаснулся... До меня его писал дизайнер, писал так чтобы работало, но не заморачиваясь о поддержке и сопровождении, и ему это удалось. Сайт в целом небольшой - каталог с категориями и товарами, пара страниц, корзина.

Я же получил после него >16,000 строк кода на jQuery, >15,000 строк кода на CSS - и как скрипты так и стили находятся в одном файле (style.css, script.js), все что делается перед заливом на боевой сервер - только минификация пробелов. Ну и Django файлы и приложения с нескончаемым кол-во строк и непонятной логики, где около 50% (что кода, что файлов) написанного вообще уже не используется. Адаптивность задается с помощью javascript магии, никакого Boostrap'a и прочего...

В общем все жутко запутанно, связанно, но ни в коем случае не модульно и не связно. Документация полностью отсутствует, комментарии в коде тоже + в довесок куча было-кода.. Решая каждую тривиальную задачу мне приходится погружаться в изучение созданного велосипеда. Сложилось ощущение что с помощью дрели пытались забивать гвозди (это я про неумелое использование Django). В общем я работаю 3й день и у меня уже нет желания что-либо там ковырять. Так-же я чувствую себя плохо из-за того, что не могу гарантировать качество своей работы.

Начальство в целом понимает, что у них все не очень хорошо с сайтом. Но так получилось, что мой непосредственный руководитель главный дизайнер. Я не хочу быть многословным, и хочу демонстрировать на деле, что я профессионал. Но предлагая решения мне придется их аргументировать. Я планирую делать связку Angular2 + Node.js (для server-side-rendering) + PostgreSQL (возможно еще сделать API не на node а том же самом Django чтобы работало максимально быстро).

У меня имеется несколько вопросов к более опытным и тем кто уже "собаку съел" на этом:
- Как аргументировать и подтолкнуть к решительному шагу начальство которое практически созрело до того что нужно переходить на новый уровень?
- Подойдут ли ассоциации - например про дом без фундамента, где нужно настроить еще этаж перед наводнением. Или про старую дрель которая еле работает, и если ей сверлить бетон это будет жутко долго и неудобно, и не хватит времени чтобы дойти до магазина и купить новую?
- Любой Ваш опыт в подобных ситуациях?

Благодарность тем кто дочитал до конца, и делится своим опытом.

Comments

[beduin01]

На правах оффтопа: Посмотрите в сторону Vue

[Zhainar]

Есть один нюанс: начальству срать на код и его качество.

[neochar]

Я всегда думал, что если на jQuery больше 1000 строк кода - пора переходить на Angular, нет?)

Answer 1

[lega]

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

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

Comments

[kocherginji]

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

Действующий проект под рефакторинг, благо время не подгоняет. Потихоньку все там разберу.
А на новый проект дали зеленый свет в плане использования друго тех.стека.

У меня только к вам вопрос - мне вот тут многие написали, что Angular2, Boostrap это "хипстерство", но я вижу как такие инструменты активно внедряются и используются в перспективных проектах/компаниях. Как вы относитесь к этому?

[lega]

kocherginji: Если у вас есть отдельный дизайнер + верстальщик, то можете делать с нуля. Мне как разработчику нет на это время, bootstrap ускоряет разработку и выглядит не так уж и плохо.

Для большого проекта без разницы Angular 2 или что угодно другое новомодное - все устареет через 3-4 года и далеко не факт, что можно будет легко обновить (сюда же экономический вопрос).
Например 4 года назад самым новомодным был Angular 1.1, и простой миграции на 1.6, который уже родился устаревшим, нет.
Вообще каждые ~2 года взлетает новая технология для фронденда, так что ждите что-то в ~2018, после чего angular 2 (angular 4 и 5), react и vue.js будут старьем.
А проект нужно делать уже сейчас, поэтому лучше брать то что вы умеете хорошо "вертеть".

Конкретно Angular 2 не айс, конечно он лучше чем приложение на jquey/knockout/backbone, они много косяков "пофиксили" по сравнению c angular 1, но и привнесли много проблем, + какие-то простые вещи решаются через адские костыли, сами его не используют (т.е. фреймворк построен на теории, а не на практике), непонятно почему гугл их кормит.

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

[kocherginji]

lega: благодарю за развернутый ответ. Для меня очень важна эта информация.

[xtalen]

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

Answer 2

[Saboteur]

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

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

Если ни то, ни другое, то с какой стати платить больше?

Comments

[kocherginji]

Согласен с Вами. Когда вкратце зашел за это разговор, но этом я и строил свои аргументы. Грамотная архитектура + быстрее работает + проще расширять + проще переиспользовать + быстрее грузится + больше конверсия = больше кэша компании.

[kocherginji]

+ все таки текучка программистов которые не выдерживают это садо-маза, уже ощутимо чувствуется на верху.

[Saboteur]

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

[kocherginji]

Saboteur: благодарю Вас. Пожалуй придется посвятить выходные этому вопросу, чтобы все продумать и спланировать.

[zelsky]

Хорошо. Кратко и понятно:
либо 1е Я буду ковирять ваш код ~400часов
либо 2е С нуля переписать займет ~ 250 часов.
Все сугубо индивидуально но если проект реально большой тогда проще с 0 переписать.

[Saboteur]

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

[kocherginji]

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

[Нерон Лордов]

Saboteur:
>>Понятие Legacy
Как по-русски выразить это понятие?

[Максим Кудрявцев]

Nekto_Habr: дословно с английского "Наследство"

[Saboteur]

Nekto_Habr: Одним словом Legacy нельзя переводить, так как оно используется в качестве профессионального термина, а не собственного значения.
Legacy это все, что тянется из прошлого, и от чего не так легко избавиться.
Например размер байта - 8 бит, и от этого невозможно избавиться, потому что Legacy. И мы ограничены в том, как адресуется память - когда стало не хватать символов, пришлось добавить еще один целый байт, а не например 1-2 бита

[Saboteur]

Saboteur, Протупил, Legacy переводится как "технологический долг" =)

Answer 3

[sim3x]

Никак

Они или дойдут до етого сами и тогда наймут приличного СТО, который с большой вероятностью уволит всю команду

Или не дойдут и медленно умрут

Если менее критично, то тебе нужно искать книги по практике переговоров

Также стоит убрать дизайнера от руководства тех деталями

react - clojure
https://www.youtube.com/watch?v=WssdWSbAPKE

Comments

[kocherginji]

Очень нравится clojurescript есть даже опыт разработки проекта на нем. Благодарю за совет! Хочу использовать возможность и предложить им рабочий вариант, чтобы самому потом команду подбирать и продумывать тех.детали.

[sim3x]

kocherginji: лучше сделать упор на переговорах
Слушай, что говорят владельцы бизнеса, что им важно, на что они смотрят
Собери список
Расчитай сколько тебе нужно будет времени запилить в одно лицо весь функционал
Расчитай как нужно будет сделать переход без остановки процесса
Если можно за пару часов сделать демо - сделай
И вот уже с етим иди договариваться

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

[kocherginji]

sim3x: Вы правы насчет падения ((:

Answer 4

[Яков Е]

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

Грубо говоря на вот эту фичу я потратил Х, а если была бы нормальная система, потратил бы Х/5, и хотя Х величина не такая уж большая, за Y времени набегает сумма сравнимая с переписыванием. Но отдаем мы только проценты по техническому долгу, а тело все увеличивается и увеличивается, и за Y*2 мы потеряем вот столько.

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

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

Comments

[kocherginji]

Благодарю, буду использовать Вашу формулу как полезную модель. + очень интересно узнавать о техническом долге - ибо этот термин слышу впервые.

Answer 5

[Dmitry Pavlov]

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

P.S. Не тот программист хорош, кто старый мир разрушит и по-своему накосячит (а это обязательно произойдет), а тот, кто может огрехи найти, осмыслить и исправить без ущерба для бизнеса, который этот софт обслуживает. При этом, не забывая о разработке новых фич. (С) Я 2017

Comments

[Алексей Бурлака]

Один из проектов у меня на поддержке именно так и трансформируется. За три года я плавно добрался почти до всего. Ценник по-часовой, я считаю по-честному, но он слегка увеличен на эту реструктуризацию. Клиент не замечает, а проект улучшается с каждой итерацией.

[Dmitry Pavlov]

Алексей Бурлака: ну и правильно. Ничто так не учит, как выведение проекта из грязи в князи без лишних революций и шапкозакидательств. :)

Кстати, на мой взгляд, клиенту лучше доносить информацию об улучшениях. Просто можно использовать форму подачи соответствующую. Например, "в рамках работы над текущими задачами также были произведены улучшения в имеющемся коде, что дало улучшения по скорости / стабильности / масштабируемости / поддерживаемости и тп (см. -ilities https://en.wikipedia.org/wiki/Non-functional_requi... кода. Клиент обычно рад, что эти вещи по ходу обычной плановой работы - тоже под контролем и улучшаются.

[Василий Мажекин]

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

Answer 6

[Alexej Simakov]

Начальство боится потерять то, что уже есть и как-то работает. Если вы будете делать новое параллельно , во внеурочное время, думаю никто не будет против :) У меня такой опыт;
Нам передали проект с говнокодом, и архитектор и сен. дев. сказали что нужно переписать все с нуля, иначе это нам потом аукнется. Ответственный руководитель, добрый но трусливый, не дал ход изменениям. Через год руководитель ушел. И мы остались сидеть на говнокоде. А переписать все заняло бы наверно 2 недели упорной работы. Теперь просто некогда. Жаль что не решились. В принципе начальника можно было тогда уломать, но никто не был достаточно настойчив.

По моему опыте с обобщающими ассоциациями нужно быть осторожным. Это может интерпретироваться как болтология и нежелание работать. Мол возмущаться и жаловаться все горазды..

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

Answer 7

[Mikhail Osher]

Я бы в лично заявил руководителю что-нибудь такое.

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

Comments

[Adamos]

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

[Михаил Макаров]

Adamos: молодой и горячий, но ведь тебе за это не заплатят. Максимум - грамоту выпишут. Или пол зарплаты лишней выдатут на новый год (== не заплатят). Может быть лучше свои силы кинуть в то направление, которое через пять десять лет тебе позволит на хорошей машине жену и детей на море возить?

Answer 8

[Михаил Макаров]

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

Comments

[Михаил Макаров]

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

Answer 9

[Dmtm]

Поддерживать то что есть и так как есть. Попутно слегка рефакторить (типа переменные правильно назвать, лишний код вычистить - не больше). Быть готовым к увольнению и уже сейчас начинать искать новую работу.

Answer 10

[Анатолий]

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

Разгребая лапшу из кода, я нашел несколько серьезных уязвимостей. Скинул ссылки руководству, по которым можно войти под админом с произвольным паролем (именно скинул, чтобы они почувствовали этот кайф). И т.д и т.п.
В итоге руководство пригласило меня и задало вопрос: что делать?
Теперь, у меня появилось право, предложить выкинуть эти испражнения некого мозга.

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

Да. Мое руководство, вообще к программированию отношения не имеет, у него отношение такое: был Петя, кидал в печку тонну угля в день, взяли Васю, он может две закидывать. Т.е. понимание нет вообще, тем не менее, Бог наделил людей разумом, нужно учится договариваться.

Answer 11

[Александр Аксентьев]

Для вас это делать все хорошо и правильно.
Для начальников и так работает, а надо перестать вдруг всё "новое делать" и писать с нуля и потратить (ваша з.п. * N месяцев) = кучу бабла

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

Answer 12

[Василий Назаров]

Я планирую делать связку Angular2 + Node.js (для server-side-rendering) + PostgreSQL

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

Comments

[kocherginji]

Вы уже не первый кто употребляет слово "модных" или "хипстерских", но я лучше стану хипстером, чем буду ковырять 16к строк кода в script.js - его блин даже Atom на iMac(i7) грузит около минуты когда открываю.

[Сергей]

kocherginji: во-во и атом хипстерская ерунда, он сам по себе тормозной. Это редактор для верстаков, если вы программист, почему не используете адекватные инструменты типо web storm или pycharm? 16к можно вычистить и разбить на отдельные файлы. Вы мне напоминаете моего знакомого "программиста", который мог делать сайты только на своей самописной цмске, а остальное все называл отстоем. Вы пытаетесь сделать в первую очередь как вам удобно, но при этом сделать это тоже удобным для вас способом. Хотите улучшить сайт, работайте с тем что есть. Неиспользуемый js и css вычищается, есть куча плагинов. А вообще ваше отношение к работе, показывает, что вы не особо готовы работать и уходите от проблем. Наверное вашему работодателю будет только лучше, если вы уволитесь.

[kocherginji]

Lomnev Pro: согласен, код уже начал рефакторить. А на новый проект компания дала добро делать на другом стеке.

[kocherginji]

Lomnev Pro: а кода действительно много для такого проекта, там 50% минимум вообще не используется уже.. Но потихоньку разберу..

[Михаил Макаров]

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

[lega]

Михаил Макаров: > перетянуть логику в вёрстку

Вы не отличаете логику от вида представления.

[Михаил Макаров]

lega: да, вы правы. Я знаю, что такое логика, что такое вид, что такое представление. Что такое вид представления - я не знаю. И не хочу.

[lega]

Михаил Макаров: В ангуляре вас никто не заставляет тащить логику в верстку, каждый разработчик сам решает как ему использовать, ангуляр просто дает возможности. Так же возможно вы называете логикой то, что логикой не является (а является представлением для конкретных данных).

Answer 13

[un1t]

мой непосредственный руководитель главный дизайнер

беги чувак оттуда!)

Я планирую делать связку Angular2 + Node.js (для server-side-rendering) + PostgreSQL (возможно еще сделать API не на node а том же самом Django чтобы работало максимально быстро).

Нафига node.js там же нету полноценных фреймворков. В итоге у тебя все велосипедами обрастет. К тому же я тут сомневюась, что тебе для этого проекта нужна асинхронность.

Comments

[Dmitry Pavlov]

MEAN стэк вполне себе существует. Почему бы и нет?..

Answer 14

[Андрей Гриневич]

А как так получилось, что начальник программиста => дизайнер?
У меня диссонанс бы произошёл, хотя я верю что в вашем случае всё неплохо.
По части ответов очень понравился первый комментарий, но всё же отпишу отдельным.
Тесты, тесты, тесты. Каким бы страшным, непонятным и вообще неадекватным не был код, они помогут двигать проект вперёд.
Если вы видите что правка малейшего символа приводит к крашам/багам, указывайте на это, давая точную оценку сколько у вас уйдёт времени на приведение кода в порядок.
-Взять и сделать заново - непозволительная роскошь. Любой специалист может выкосить несколько блоков кода, переписать на более адекватный вариант и обернуть тестами.
-Если у вас ещё нет агрегатора ошибок/анализатора запросов, рекомендую прикрутить. Так будет проще искать узкие места и вероятно выпилив их - можно будет отказаться от нескольких серверов (правда мне такого не удавалось, ибо время человека дороже чем аренда сервера)
-В целом начинайте писать новые куски кода в адекватной манере, следите за гибкостью и надёжностью кода, используйте лучшие практики и аккуратно рефакторите те места, куда вам пришлось влезть при выполнении задачи. Пусть это будет иногда больно, иногда тошнотворно, но результат того стоит. Или нет. Решать вам :)

Answer 15

[Юрий Костин]

Умные люди уже написали всё, что хотел написать я, но вставлю свои пять копеек, уж извините.

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

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

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

Теперь о позитивном.

Переработка кода - отличный опыт. Я бы даже сказал, что он ценнее, чем разработка на Angular 100500 версии, которую вы хотите использовать больше для того, чтобы сказать "теперь я умею angular(подставь своё) 100500 версии".
Вам придётся быть ещё более внимательным чем обычно, так как обновлять код нужно осторожно, чтобы ничего не сломать. Ещё более вдумчивым, ещё более внимательными, ещё более *, так как читать/понимать/править чей-то код - великий труд. К слову, это может показаться бредом, но вы вполне можете изучить что-то новое для себя пока будете рефакторить.

И да - рефакторить нужно частями. И чем части эти будут меньше, тем лучше.
Поэтому рекомендую взять самый адовый на ваш взгляд модуль/кусок/файл с кодом и разбить на логические части его работу. Затем осознать, что нужно разбить ещё.. ещё.. и ещё... Словом, декомпозируйте до тех пор, пока не поймёте, что дальше декомпозировать некуда.
В итоге вы обнаружите огромный список задач. С этим списком уже можно работать. Для начала необходимо оценить его в человеко-часах. Дальше можно показать его руководителю, показать временные оценки, а самое главное - объяснить, на кой чёрт нужно тратить столько времени на эти задачи, вместо того, чтобы запилить новую фичу.
А тратить это время нужно по той простой причине, которую мы преследуем изначально - ради чистоты, понятности, поддерживаемости кода. И.. да - если рефакторите js, то делайте это через TDD, это должно облегчить вам задачу (хотя вначале будет казаться иначе).

Моя коллега с первой работы сейчас занимается одним интернет-магазином. Мне невероятно нравится читать её сообщения о том, что она выпиливает css код тысячами строк. Даже не представляю, насколько приятно ей смотреть на результат своей работы.

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

Answer 16

[Сергей Еремин]

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

Answer 17

[Mephistophele]

Никак.

Answer 18

[Михаил]

Прямо скажем - ситуация не айс и переписывать вряд ли дадут. А даже если так то кто благодарить будет? Никто.

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