@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 чтобы работало максимально быстро).

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

Благодарность тем кто дочитал до конца, и делится своим опытом.
  • Вопрос задан
  • 2386 просмотров
Решения вопроса 1
  • @lega
    В большинстве случаев это экономический не целесообразно, и профессионал должен это учитывать.

    В вашем случае лучше попытаться плавно интегрировать опыт в текущий проект, разграничивая старый и новый код, (компоненты, микросервисы, "черные ящики" и т.п.), так же по чуть чуть можно будет подменять компоненты старого кода, на новые.
    В итоге через какое-то время новый код будет превалировать, и может даже можно будет завернуть старый код в отдельный ящик чтобы не вонял на весь проект.
    Ответ написан
Пригласить эксперта
Ответы на вопрос 21
  • saboteur_kiev
    @saboteur_kiev
    build engineer
    Задача сайта - выполнять свою бизнес задачу, а не демонстрировать красивый код в исходниках.

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

    Если ни то, ни другое, то с какой стати платить больше?
    Ответ написан
  • aleserkan
    @aleserkan
    Web Developer
    Поставьте себя на место начальства. У вас есть проект который приносит прибыль. Вы нанимаете человека, чтобы поддерживать и развивать этот проект. Новый работник начинает вам рассказывать что код хреновый, нужно писать все с нуля. А где хотя бы гарантии что через несколько месяцев вашей работы он не получит от вас точно такой же говнокод но на другом фреймворке? Потом вы увольняетесь, на ваше место приходит новый эксперт, и круг замкнулся.

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


    Тут точно нужны Angular 2, серверный рендеринг на Node.js, Django и PostgreSQL? Сколько будет стоить поддержка такого сайта, если вы уйдёте? Допустим, Джанга уже используется. Но django-программист скорее будет знать обычный jquery, а не эти ваши хипстерские фронтендные фреймворки. В результате придётся или нанимать одного дорогого фуллстека (и его ещё надо будет найти), или отдельного фронтендера. Готов ли владелец к таким рискам?
    Ответ написан
  • lomnev
    @lomnev
    PHP, Ruby developer. Корпоративные веб-приложения.
    1a. Согласуйте и перепишите по согласованию с руководством один модуль системы в виде микросервиса.
    или
    1b. Отрефакторьте по согласованию с руководством один модуль системы.
    ====
    2. Протестируйте и оцените.
    3. Отчитайтесь о результатах и пользе нового модуля для бизнеса.
    4. Повторяйте пока не останется старых модулей.
    Ответ написан
  • sim3x
    @sim3x
    Как задавать вопросы http://goo.gl/spqRI2
    Никак

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

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

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

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

    react - clojure
    https://www.youtube.com/watch?v=WssdWSbAPKE
    Ответ написан
  • Zifix
    @Zifix
    Qt/QML Developer & UX/UI Designer
    Аргументировать надо тем, что стоимость поддержки возрастает кратно, вероятность накосячить тоже, причем не по вашей вине.

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

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

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

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

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

    "Иван Петрович, мне нравится коллектив, мне нравится идея проекта, но очень много претензий к коду. Браться всё переписывать - убыточно с точки зрения бизнеса, однако рано или поздно случится апокалипсис. Давайте найдем способ привести это всё маленькими шагами в человеческий вид. Если продолжим поддерживать текущую реализацию - получим текучку кадров, ибо с этим работать очень тяжело и убыточно".
    Ответ написан
  • dmitry_pavlov
    @dmitry_pavlov
    Remote ASP.NET (MVC) / C# Developer (Contractor)
    Никак. Постигайте кунгфу рефакторинга legacy кода - многопроходного бережного улучшения архитектуры приложения, без перебоев в работе приложения и в параллели с разработкой новой функциональности. Покрывайте логику тестами, изолируйте / локализуйте проблемы, ослабляйте связность кода между модулями, наводите порядок внутри модуля. Повторяйте снова и снова.

    P.S. Не тот программист хорош, кто старый мир разрушит и по-своему накосячит (а это обязательно произойдет), а тот, кто может огрехи найти, осмыслить и исправить без ущерба для бизнеса, который этот софт обслуживает. При этом, не забывая о разработке новых фич. (С) Я 2017
    Ответ написан
  • @Dmtm
    Android
    Поддерживать то что есть и так как есть. Попутно слегка рефакторить (типа переменные правильно назвать, лишний код вычистить - не больше). Быть готовым к увольнению и уже сейчас начинать искать новую работу.
    Ответ написан
  • NightmareZ
    @NightmareZ
    Разработчик
    Не читал ваш опус. Не читал комментарии, но отвечу. Никак. За десять лет моей трудовой деятельности мне ни разу не удалось доказать начальству, что проект зашёл в тупик и его проще переписать, чем исправить. Чаще всего сильное моё рвение в этом направлении приводило к моему увольнению, за то, что шибко умный, и через какое-то время таки проект начинали писать заново уже новой командой, уже без старых разработчиков, и меня, шибко умного, туда никто не звал. Потому мой совет - либо не рыпайся, либо вали из этого проекта или из этой конторы.
    Ответ написан
  • @Skit25
    на всё воля Бога
    Кто ты такой, чтобы аргументировать?
    Для начальства, это главное. Нужно показать свою квалификацию, тогда начальство будет прислушиваться. Я шел к этому три месяца. Причем я не делал это специально. Просто раскапывал быдлокод, задерживался. Иной раз, когда начальник проходил мимо, я показывал ему, что вообще творится и сжато объяснял, как должно быть и почему как есть плохо.

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

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

    Да. Мое руководство, вообще к программированию отношения не имеет, у него отношение такое: был Петя, кидал в печку тонну угля в день, взяли Васю, он может две закидывать. Т.е. понимание нет вообще, тем не менее, Бог наделил людей разумом, нужно учится договариваться.
    Ответ написан
  • Sanasol
    @Sanasol
    нельзя просто так взять и загуглить ошибку
    Для вас это делать все хорошо и правильно.
    Для начальников и так работает, а надо перестать вдруг всё "новое делать" и писать с нуля и потратить (ваша з.п. * N месяцев) = кучу бабла

    Никакие аналогии не прокатят, только если этоне затронет текущую работу и вашу занятость, читай как будешь писать параллельно апдейты для текущего сайта и не забивать на него и при этом пилить новую версию.
    Ответ написан
  • basili4
    @basili4
    Программист
    Шансов нет. И даже пробовать не надо.

    Ну и еще момент. Мы разработчики порой забываем, что это Мы для бизнеса, а не бизнес для нас.
    Ответ написан
  • @vnaz
    Я планирую делать связку Angular2 + Node.js (для server-side-rendering) + PostgreSQL

    Если сейчас работает без этого, то вы не упростить хотите, а наворотить модных хреновин. Думаю, если бы руководство знало эти ваши планы, любые ваши аргументы можно было бы засунуть под хвост.
    Ответ написан
  • un1t
    @un1t
    Программист Python/Django
    мой непосредственный руководитель главный дизайнер

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

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


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

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

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

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

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

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

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

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

    Может показаться, что предложенный подход(рефакторинг) - полный бред и безумие, но это не так.
    Удачи вам.
    Ответ написан
  • Sergei_Erjemin
    @Sergei_Erjemin
    Улыбайся, будь самураем...
    Возьми и сделай. Если считаешь, что сделать хорошо и понятно проще и быстрее не надо разбираться в чужом коде. Модуль за модулем, блок за блоком все переписываешь и сидишь довольный.
    Ответ написан
  • @springimport
    Прямо скажем - ситуация не айс и переписывать вряд ли дадут. А даже если так то кто благодарить будет? Никто.

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

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы
Вакансии с Моего Круга Все вакансии
Заказы с Фрилансим Все заказы