Это именно-именно о том о чем я говорил.
Аскорбинка для больного гангреной

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

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

Проблема с именованием – куча существующего расплывчатого, сильно связанного (кода), неопределенность функциональности и отсвественности его составляющих не дает возможности развивать проект.

Удалось получить время только на очень ограниченый рефаторинг… По сути поправил верхний уровень, происходящее на пересечении и глубже – мрак. Времени было выделено действительно очень мало – уже в процессе реализации фич приходилось возвращатся к рефакторингу. Результат – деадлайн провален, унаследованный код (и код сопряжения) принес кучю багов при сдаче.

Думаю это из серии «аскорбинка для больного гангреной» – помогло, но слабо

Уже около года время от времени встречаю использование слова «пользовать», и, можно сказать накипело Простите.

[/off]

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

Пользовать инструменты – это хорошо (если они помогают).

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

Комплексные числа не сравниваются. Нельзя сравнивать пересмотр архитектуры (коллективная деятельность), рефакторинг (максимум – парная деятельность) и стиль написания кода (индивидуальная деятельность). Это не понятия одного порядка, их ЗАПРЕЩЕНО приоритезировать. Приоритеты определяют исключительно для работ одного порядка. Мы же не сравниваем время на завтрак и время по получение высшего образования, правильно?

Я согласен о том, что не всегда можно сравнивать вещи сильно отличающиеся в длительности.

Однако описанная мной ситуация отличается от разделения на
- пересмотр архитектуры
- рефакторинг
- стиль написания

Основная идея была цель – увеличить стабильность системы и уменьшить время на поддержку системы. Время на это было ограничено. Стоял вопрос, как это сделать.

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

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

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

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

1. Комплексные числа не сравниваются. Нельзя сравнивать пересмотр архитектуры (коллективная деятельность), рефакторинг (максимум – парная деятельность) и стиль написания кода (индивидуальная деятельность). Это не понятия одного порядка, их ЗАПРЕЩЕНО приоритезировать. Приоритеты определяют исключительно для работ одного порядка. Мы же не сравниваем время на завтрак и время по получение высшего образования, правильно?

2. Risk management, Scope management, Project planning. Это три инструмента, решающих вопрос приоритетов работ. Для каждого случая свой. Используйте вековой опыт, коллеги, не гнушайтесь

3. Аналогии – зло. Допустимое зло А разработка ПО – это на 99% работа с аналогиями. Постоянный языковой перевод между тремя мирами – вещественным, воображаемым и электронным.

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