Пожар, чистые зубы и приоритеты
Написал вчера пост о том, что мелкими действиями плохой проект не спасти и натолкнулся на удивительный отпор 
Признаю, моя ошибка была в том, что я не указал изначально все-все детали. Но с другой стороны, тогда у меня вышел бы не пост, а роман.
А в этом посте, хочу привести один пример.
Человек пошел в ванну чистить зубы, вдруг слышит пожарную серену и видит, что в ванну врываются клубы дыма… Ну, он подумал-подумал и решил, что чистить зубы это полезно для здоровья и решил продолжить это делать. Вот такая, странная трагическая история.
Внимание вопрос. Стоило ему пытаться спасаться? Я думаю - ответ “да”. Полезно ли чистить зубы? Ответ тоже “да”. Какого же фига нужно спасаться от пожара, а не чистить зубы?
То, что я хотел сказать (и в прошлом посту и в этому), что в мире есть миллион полезных вещей. В программирование этих полезных вещей не меньше.
Сделать ВСЕ полезные вещи нереально. Следовательно нужно расставлять их по приоритетам. Зачастую приоритеты зависят от сложившейся ситуации.
Если человек не умеет выбирать между чисткой зубов и спасание от пожара, долго он не протянет.
Из моего лично опыта, если человек делает даже приоритет N2, вместо приоритета N1 - это уже обычно на длительном отрезке времени ведет к проблемам. Если человек делает приоритет N10 , вместо приоритета N1 - то это полный пипец (даже на коротком участке времени)
Резонный ответ из зала. Но, все равно, лучше делать N10, чем N20 или чем вообще ничего не делать.
Моя саркастическая фраза: Да, конечно, в момент пожара лучше чистить зубы (N10), чем читать газету(N20). Это гораздо эстетичнее и красивее.
Опять ответ из зала: Так, что же вообще ничего не делать? Я скажу так, что если кто-то не решаете приоритет N1 или N2, то толк от человека фактически равен ничего не деланию. А если этим еще и расходуются деньги фирмы на деланье приоритета N10, то лучше вообще чтобы такой человек ничего не делал (был уволен).
>>Написал вчера пост о том, что мелкими действиями плохой проект не спасти и натолкнулся на >>удивительный отпор
Вот вы умеете
перевра..истолковать факты; видимо, не зря в бизнес собрались =).. ну да полноте, не обижайтесь на “старого еврея”Суть поста была в том, какую важную роль играют “мелочи” типа codeStyle и проектирования, и так далее, и как пренебрежение этими мелочами окунуло всех по голову в фекалии; а затем все равно пришлось ими заниматься. Вот
> Вот вы умеете перевра.. истолковать факты; видимо, не зря в бизнес собрались =).
Считаю это комплиментом :))
>Суть поста была в том, какую важную роль играют “мелочи” типа codeStyle и проектирования, >и так далее, и как пренебрежение этими мелочами окунуло всех по голову в фекалии; а затем >все равно пришлось ими заниматься. Вот
Не суть поста была таки в приоритезаци..
Если не чистить зубы, то вероятнее всего таки они повыпадают (скажем через лет 7-10). Но, если например не пить воды, то умрешь через три дня.
Это не говорит о том, что зубы можно не чистить, но воду пить обязательно.
По моему мнению приоритетность примерно такова
а) Решения бизнес задач (требуемая фунциональность)
б) Правильная архитектура
в) Общее качество кода (отсутствие мертвого кода и дублирования). Частично это относится к пункту б)
г) Красивый стиль (именование переменных), отступы
То есть, если выбирать между б) и г) - я голосую за б), если можно получить и то и другое - я голосую за получение и того и другого.
>>Считаю это комплиментом :))
Это правильно =)
>>По моему мнению приоритетность примерно такова
>>а) Решения бизнес задач (требуемая фунциональность)
>>б) Правильная архитектура
У меня немного другое видение этих вещей. Ближе всего к нему определение, данное Сергеем Розовиком в этомпосте:
Процитирую
>>Архитектура (программного обеспечения) – это совокупность согласованных >>технических решений направленная на удовлетворение требований, предъявляемых к >>программному обеспечению.
Таким образом любая архитектура и есть суть выражение решения бизнес-задач. Однако правильная архитектура - та, которая в долгосрочной перспективе минимизирует затраты на реализацию, развитие и сопровождение реализованных процессов. Оценка первпектив минимизации -опять же отдельный вопрос, который должна решать команда, а не PM в одиночестве.
Поясню про долгосрочность плана: изменение имен переменных бессмысленно, если сдавать проект завтра, но имеет смысл, если его планируется еще продолжительное время развивать.
Так что лично для меня а и б почти одно и тоже; соответственно, приписать разные приоритеты одному и тому же я не в в силах
Вдогонку:)
обратите внимание на слово “минимизирует”. Вот пример code style - это то самое малозатратное, что мы можем сделать, но которое значительно облегчает сопровождение кода.
Честно-говоря, примеры не очень
Понятное дело, что из двух зол выбирают меньшее. А из двух крутых вещей выбирают лучшее, но в рамках ограничения - “лучшее - враг хорошего”.
Ясное дело, что рефакторинг может показаться дорогим (особенно, если существующее решение не формирует неприемлимо-низкий потолок для роста бизнеса).
Просто есть необходимость сделать максимум, если не для существующего решения - то хоть для следующего (следующей итерации). И правила к оформлению кода/комментариев тому подспорье.
Более того, даже если один-два человека из 5-8 будут об этом думать (а лучше, если они будут достаточно профессиональны для этого), то это уже гарантия возможности рефакторинга. А то ведь бывают случаи когда он невоможен.
Вопрос приоретизации - не так прост. Та вещь, которую Вы считаете мало-важной может оказаться важной с точки зрения инвестора.
Я еще не видел ни одного проекта который загубило направильное именование переменных. Я видел множество проектов, которых загубила плохая архитектура, дублирование кода и мертвый код.
По этому поводу фактически стопроценто для меня улучшения архитектуры, убирание дублирования кода и убирания мертвого кода стоят выше, чем корректное название переменных.
Может примеры не очень. Но опять же возвратясь к ним, если в общежитие живут 5-8 человек, и из них два остались чистить зубы в момент пожара… пусть земля им будет пухом.
>Та вещь, которую Вы считаете мало-важной может оказаться важной с точки зрения >инвестора.
Так я и не пытаюсь сейчас рассудить приоритеты для инвестора.
Я говорю, о технических приоритетах и что делать в пределах ограниченных финансов.
Как по мне, лучше все начать потихоньку править архитектуру, а ни наскоком сделать правильное именование переменных.
> Я еще не видел ни одного проекта который загубило направильное именование
> переменных. Я видел множество проектов, которых загубила плохая архитектура,
> дублирование кода и мертвый код.
а я не видел ни одного девелопера, который бы делал ХОРОШУЮ архитектуру и при этом НЕПРАВИЛЬНО именовал переменные.
а вот среди тех, кто неправильно именует переменные найти того, кто может сделать хорошую архитектуру сложно. не то чтобы их совсем нет, но крайне мало.
тут всё как в древнем анекдоте - сегодня ты ковыряешься в носу, а завтра родину продашь!
что касается приоритетов, то исходя из написанного их нельзя расставить. проект предполагалось сдать через месяц и все силы были кинуты на это? вы правы отказав.
проект предполагалось делать ещё год? вы были не правы…
>а я не видел ни одного девелопера, который бы делал ХОРОШУЮ архитектуру и при >этом НЕПРАВИЛЬНО именовал переменные.
Придется мне выслать фотку.
Архитектуру вполне прилично делаю, а переменные именную может быть не как попало, но назвать хорошо как-то тоже рука не поднимается.
>что касается приоритетов, то исходя из написанного их нельзя расставить. проект >предполагалось сдать через месяц и все силы были кинуты на это? вы правы отказав.
>проект предполагалось делать ещё год? вы были не правы…
Если проект предполагалось делать еще год, нужно было начинать рефакторить архитектуру. Учитывая, что специально времени под это не выделялось, надо было начинать делать это понемножку, модуль за модулем (за год управились бы), а менеджмент и незаметил бы.
Как я и говорил, если тратить время, то только на приоритет N1.
> Придется мне выслать фотку.
>
> Архитектуру вполне прилично делаю, а переменные именную может быть не как
> попало, но назвать хорошо как-то тоже рука не поднимается.
опять же не видел ни одного девелопера, который бы думал, что плохо делает архитектуру
:)
Полно таких. Начни с меня :). Ты же не знаешь, что они думают. Другое дело, что всегда можно найти оправдание: “исторически сложилось”, “мало времени”, “начальство казлы”, “заказчик дурак”, “космический лучи”, etc
“космический лучи”
+1, респект Таганрогу
Если тоже надумаешь с пивом приезжать, то я в Праге
Да понял я. idc, если не ошибаюсь.
А я пока в Softech’е
Похоже, в заголовке опечатка: не “Пожар, чисты зубы и приоритеты”, а “Пожар, чисты_Е_ зубы и приоритеты”.
Спасибо. Поправил.
Допустим, есть человек, который передвигается по комнатам спустив штаны так, что они болтаются на щиколотках. Тут происходит вышеупомянутый пожар. Должен ли человек потратить чуть времени, чтобы натянуть штаны перед тем, как спасаться? Соглашения об использовании _в будущем_ более читабельных имен переменных — как-раз такое действие. Занимают мало времени, но позволяют в будущем бежать быстрее.
О…. отлично.
Во сколько раз тормозят опущенные штаны передвижение. Я бы сказал в 4-5 раз.
Поэтому мы
а) Подымаем штаны
б) Бежим спасаться
Скажем, если бы это были не опущенные штаны, а растегнутая рубаха, вероятнее всего мы ее бы не застегивали. Скорость передвижения может быть увеличилась бы на пару процентов.
Прошу вас оценить насколько ускорит правильное именование переменных разработку (по сравнению средне-паршивым именованием)?
И на сколько улучшит разработку рефакторинг, ключевого модуля (написанного средне-паршиво)?
Аналогии - зло. Неправильное употребление аналогий искажает истину.
А вообще чувствуется, что наболело: ну не хочу я этим заниматься, не буду!
>Аналогии - зло.
Уж извините, приведу еще одну аналогию
Аналогия - это как пистолет. Это все лишь вещь/понятие.
А дальше уже дело человека как применить эту аналогию во зло или в пользу.
Ну, представьте себе, что из всех постов выкинуть аналогии, сарказм, шутки и т.п. (с помощью всего этого можно искажать истику). Что же мы получим? Сухой учебник, от которого будет “скрипеть на зубах”.
И приятно почувствовать, что понимаешь как именно эти аналогии эту истину искажают.
Только аналогия никак не пистолет
Может быть это модель? Мы знаем что такое модель, какое отношение она имеет к истине и как сокращает путь.
Как по мне, аналогии часто выступают в роли пистолета.
Пока не вынешь его из кобуры, никто не понимает о чем же точно идет речь
Естественно аналогии не могут доказать правоту, но обычно с помощью них удается подчеркнуть наиболее важные пункты.
Что меня правда напрягает, что когда проводишь аналогию, именно для подчеркивания наиболее важных пунктов, то люди вместо самой идеи начинают копаться в аналогии и в ней выискивать дыры (вместо того, чтобы относится к ней, как просто к упрощенной моделе).
> Что меня правда напрягает, … люди начинают копаться в аналогии и
> в ней выискивать дыры
это потому что аналогия дырявая. если метафора неверная, то её начинают мочить. если верная, то ни у кого вопросов не возникает.
проблема этого примера в том, что выбор пожара в качестве метафоры состояния проекта не соответствует метафоре именования переменных (чистка зубов), т.к. именование переменных таки направлено на улучшение состояния проекта, а чистка зубов не оказывает никакого влияния на горящий дом.
тут уже сказали, что правильнее было бы взять за метафору что-то типа обливания стен водой.
но тогда бы не получилось донести мысль, ведь так?
вот и получается, что выбрав неверную метафору можно “подчеркнуть наиболее важные пункты”, но напрягает, когда говорят, что модель неверна…
что-то у меня на душе тошно утром сегодня.
так что - черт с ним. да, аналогия не верна
да, можно исправлять название переменных и наплевать на архитектуру.
так между прочим 80% программистов и поступают. и ничего себе живут…
угу. замечательный полемический приём - называется “бросание в крайности”.
никто не говорит, что архитектура не важна, говорят, что важна правильность модели
у меня дейсвительно фиговое настроение, так что это не полемический прием, а выражение состояние души.
Модель - это всего лишь отражение чего то.
Прямой вопрос - представим, что проект делается на ВАШИ деньги и он в фиговом состоянии (знаю, вы бы до плохого состояние его бы не довели, но вот гипотетически представим, что оно в плохом состоянии).
Что бы вы хотели видеть/сделать:
а) Большой рефакторинг. Код замораживается на 3-4 месяца и чистится, в этот момент вряд ли с вашими ресурсами можно было бы позволить любую дополнительную разработку.
б) По проекту исправляются названия переменных (первый приоритет) и после этого либо делается итеративный рефакторинг архитектуры либо нет (по вашему усмотрению).
в) В проекте начинают итеративно проводить рефакторинг архитектуры. Когда она закончена (Вероятнее всего через месяцев 9), исправляют название переменных.
Какой ваш выбор?
Если вы предложите четвертый вариант, готов его выслушать.
что-то поплющилось. попробую повторить…
> и он в фиговом состоянии
расплывчасто. но предположим, что это означает состояние, когда изменения в проекте увеличивают эффорт по внесению последующих изменений в разы. при этому кроме говёной архитектуры нет единого стиля кодирования и так случилось, что это всё моя проблема, а не законтрактованного исполнителя.
> Какой ваш выбор?
всё как обычно зависит от моих целей. есть варианты:
1. кровь из носу нужна некая функциональность на вчера, а дальше хоть трава не расти
естественно я буду требовать чтобы это было сделано и плевать как - пусть хоть залатают заплатку на патче.
2. необходимо постоянно нарасчивать функциональность приложения. простаивать нет возможности.
вводяться стандарты кодирования, вводится местный рефакторинг (то есть исправляется только то, в чём проводятся изменения, чтобы облегчить внесение этих изменений). это вроде как замедляет внесение функциональности, но обеспечивает бОльшую плавучесть проекту в долгосрочной перспективе.
3. пока всё более-менее живёт, но грядут большие изменения.
смотрим и считаем, что будет легче - всё починить (глобальный рефакторинг) или всё переписать с учётом горьких ошибок прошлого.
—————
вот собственно. только я не очень понимаю к чему это всё?
парень из вашего прошлого поста предложил не переменные переименовывать, а “давайте хоть все начнем придерживаться единого стиля написания”
это вообще-то не проекту имеет отношение, а к культуре разработки. это is a must. иначе проект пишет не команда разработчиков, а толпа ковбоев.
В общем. С таким определением я согласен.
Единственная, особенность проект достаточно длинный был и нужно было выпускать просто очередную версию.
То есть, уменьшить фунциональность была нельзя.
А проблемы были с стабильностью, то есть куча фич, все подглючивающие.
Ну и каждое исправление выливается в борьбу титатонов, чтобы не добавилось больше проблем, чем было исправлено.
ппц. ну его в баню короче
В почте оба прочитались
и то хлеб…
пожарная метафора конечно интересна и красива, но скорее всего она не подходит для оринетации и принятия решений в ИТ команде.
Когда горит огонь, то это прекрасно все видят и понимают.
Когда идет дым внутри проекта, то это далеко не так очевидно.
Кроме того, пламени может и вовсе нет, оно существует только в распаленном воображении неопытного руководителя. Наверное поэтому приоритеты расставляет лидер. А в случае полной неудачи именно лидера и следует уволить.
Продолжая аналогию, стиль кодирования в вашем примере следовало бы представить не просто чисткой зубов, а чем-то, что не мешает но и не особо помогает при пожаре. Например, выбегая из горящего дома, наш герой продолжает чистить зубы :). Пока он не знает, выживет он или нет. Понятно, что чистка зубов имеет смысл только в первом случае.
Принимая во внимание ваше добавление к предыдущему посту (Я написал P.S. к статье. Да он предлагал изменить текущий код.), можно дальше продолжить аналогию: герой возвращается в горящий дом и обливает одну из стен водой. При условии, что пожарные подоспели и потушили дом - это может оказаться полезным.
Даже, в втором, случае, если он уверен, что спасется, мне кажется чистка зубов при идущем пожаре - дело не самое умное
Следите, пожалуйста, за окончаниями. Просто через предложение ошибка. :о)))
Постараюсь
“То, что я хотел сказать (и в прошлом посту и в этому), что в мире есть миллион полезных вещей. В программирование этих полезных вещей не меньше.”
Надо писать “В программированиИ” в данной ситуации. Падежи, окончания и т.д.
Гелактеко опасносте, родной
?
Прошу прощения. Опечатка. “Гелактеко” следует читать как “Галактеко”.
Согласен с Андреем, аналогии - зло. Куда хочу, туда кручу.
В моем понимании это так.
1. Если сотрудник парится насчет стандартизации, унификации и т.д. - это или профессионал который уже ходил по граблям, или специалист который планирует работать в компании долго.
2. Если не парится, значит перекати поле. Сегодня тут быстро залатать, а все равно увольняться, а что будет мне пофиг и так далее.
Так вот в первом случае, не важно как проект горит, как показывает практика в ИТ компании проекты горят постоянно, нужно к этому привыкнуть и медленно но верно плыть к берегу хоть и сносит течением.
Вот с этим не согласен. Далеко не все проекты “горят”.
Да, горение очень часто происходит в мозгу менеджера, который хочет выслужиться перед вышестоящим менеджером.
Хотя с другой стороны, подновляющее большинство проектов вылетают за deadlin’ы.
Уже отписал Андрею.
Аналогии - это всего лишь вещь/понятие.
Дальше, все зависит как повернуть это - во благо или во зло.
Забыт случай номер три.
3. Сотрудник еще не профессионал и по граблям не прошел. Ему интересно, что-то улучшать, но как и в каком направление это делать, он еще не уверен.
Позвольте мне высказать одно замечание. Если вы (как и я) читаете блог Виктора, значит именование переменных для вас не столь принципиально. Вам не мешает читать небрежный стиль Виктора (пропуск слов, орфография, падежи, знаки препинания и т. д.). Значит, его “код” (текст, который мы читаем) работает, функционал на требуемом уровне и развивается (мы все читаем, обсуждения живут, темы волнующие). Виктор пишет небрежно, но не настолько, чтобы получилась слишком ломаная архитектура, что другой человек не смог бы “поддерживать функционал”, то есть вам не приходится перечитывать абзац до “просветления” и продираться через косноязычие, - удаётся сразу понять и ответить.
Важнее “архитектура”, а не “орфография” или даже пропуск слов и букв в словах (в никатарых приделхк анешно
Так?
Эх… Жаль анонимно
Я сам хотел похожее написать.
И так ясно, что было бы здорово если я (да и большинство других новоиспеченных блоггеров) писали правильнее - было бы здорово. Но, тем не менее, эти неправильности (хорошо сравненные с неправильным именование переменных) не мешают читателю понимать смысл.
Тут вы оба не правы
Орфография и пунктуация - вещи более мелокого порядка, нежели именование переменных.
Вот часть этого поста, написанная человеком, который называет переменную “count1″ вместо “numberOfincomingRequests”:
Вчера статья вот там все шапки в меня
Был не прав. Много писать нет.
Даду пример.
Чистить зубы во время пожара.
Глупо это?
Хорошо, а вот такой пример, из реальной жизни.
Автомобиль. Продукция АвтоВаза. Выполняет свою функцию? Да. Переносит тело водителя и пассажиров из точки А в точку Б.
Но почему на иномарке ездить приятно, комфортно и т.д., основная функция то выполняется и ладами и другими машинами. Дело ведь все в мелочах. Поэтому именование переменных, отступы единые стандарты это те мелочи которые делают работу комфортней. Но и без этого можно из точки А в точку Б переместиться.
Замечу, что вы говорите о работающей продукции автоваза.
Возьмем другой пример, у вас есть старый жигуль, с посаженным аккумулятором, разбитой коробкой передач, текущими тормозами и половиной не рабающих цилиндров.
У вас есть две возможности
-
а) начать капитально ремонтировать ее (заменяя по частям или чиня вышеописанные поломки)
б) Оставить все эти поломки но, сменить кресла на более удобные, поставить кондиционер и всячески повысить комфорт другими методами.
Что вы выбираете.
Я уверен, что вы выберете б).
Собственно идея это статьи была в том, что важно соблюдать приоритеты.
Если в проекте ТОЛЬКО проблемы с именованием переменных - да надо чинить их.
Если в проекте проблема с архитектурой и именованием переменных, нужно чинить сначала архитектуру, а потом чинить именование переменных.
Виктор, оставте анналогии
Так мы никуда не придем.
Согласен. Отбрасываю аналогии и говорю прямо.
Если в моем проекте есть программист, который ставит в любой момент времени название переменных выше архитектуры, я предпочитаю удалить программистов с проекта.
В такой постановке ППКС.
ага. а ещё если есть програмист, который носит на работу топор и в перерывах убивает менеджеров, то его тоже надо удалить из проекта.
каких ещё кубических коней можно придумать?
это я к тому, что не бывает таких програмистов
зачем про них вспоминать?
тем более, что если в проекте херится идея “давайте хоть все начнем придерживаться единого стиля написания”, то с очень большой вероятностью ему не поможет хорошая архитектура.
Я видел таких программистов. Большаях их часть, конечно же, расставляла приоритеты неосознано. Но были и такие, которые делали это вполне осознано. Один из случаев: программист в качестве мантры выбрал “если мы начнем писать хороший, читаемый код, то даже на кривой архитектуре можно выехать”.
Кроме того, идея то не херилась :). Проблема была в том, что человек призывал переписать существующий код. И тут срабатывает куча рефлексов. От “зачем мне лишний раз ковырять что-то, что работает?” до “40% кода - мертвый код. Нам нужно похоронить его и забыть, а не переодевать трупы в новую одежду, чтобы выглядели как живые”.
К разговору о сферических и прочих конях: вот вы верите в то, что есть программисты, которые считают, что правильное называение переменных - зло?
> Я видел таких программистов.
и сколько токих програмистов есть? один процент? полпроцента? о чём мы говорим вообще?
а идея херилась, если верить автору, то “вот эту идею уже похерил я”. может он что-то не так сказал нам?
Мы говорим о том, что если такие есть, с ними надо расставаться. Чем раньше, тем лучше. Для всех. Или я что-то упустил?
ну да. как и тех, с топорами…
Вы продолжаете давить :)? С топорами разберутся кому следует
Мы говорим о приоритезации. :))
тогда в статье надо было написать “а вот тут уже я сказал человеку: обязательно введём общий стиль написания - дай только с архитектурой разобраться”.
хотя имхо внесение новых изменений “кому как нравится” чревато ещё большими проблемами. лучше установить общие правила, чтобы все играли в одну игру.
нет, Б не выберу
ибо вы опять таки, как в случае аналогий “пожар” - “чистка зубов” выбрали разные примеры с разным весом.
Мы ведь не знаем, машина (то бишь проект над которым работали Вы) она ехала, едет или просто простаивала во дворе. Действительно слишком мало входной информации.
P.S. у меня опыт только продукто-ориентированной разработки ПО, поэтому мне отдельно взятый горящий проект внедрения продукта, не так важен как продукт в целом. Поэтому отсюда и такая позиция. Но в целом, все нужно взвешивать, я согласен что может быть есть ситуации, когда мертвому припарки не помогают и нефиг припаривать
Рискну предположить, что в данном мконкретном случае рефакторинг и переименование переменных привели бы к одному и тому же результату, т.е. ни к чему.
Слишком много вопросов.
Как такая ситуация вообще могла возникнуть при наличии большого количества толковых разработчиков? Значит они не очень толковые, либо ведущий разработчик не справляется со своей ролью либо еще чего.
Рефакторинг ради рефакторинга не имеет смысла. Если речь идет о добавлении в проект новых фич, которые невозможны без серьезной переделки - это одно дело. Если просто хочется иметь человеческую архитектуру, это похвальное желание, но оно не может быть самоцелью.
В зависимости от планов развития, выходом могло быть написание какой-то новой функциональности с нуля. Существующий код можно использовать в качестве кирпичиков. Опять же, речь идет о новом функционале, ради которого стоит затеваться.
Как-то так.
Да, естественно рефакторинг ради самого себя не имеет смысл.
Проблема, которая подтолкнула к тому, что надо было улучшать код, была общая нестабильность системы. А-ля
а) Большое количество крешей в различных местах
б) Большое количество ошибок, которые сложно было исправлять из-за плохой архитектуры и общей загажености кода (одно исправляется, другое ломается)
Фактически, проект стал пробуксовывать на месте. То есть поддержка проекта в непадающем состоянии занимала колоссальные процент времени.
Я бы сказал, разработчики были средние и менеджмент тоже был очень средний, сумма этих средностей помноженная на достаточно долгий срок ведения проекта дал свои результаты.
Понятно, тогда еще все хуже
По идее рефакторинг - это переделка работающего кода. А в такой кризисной ситуации нужно начинать с переписывания одного-двух жизненно важны