История изменений

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

Есть печальный опыт работы в большой организации, продающей много лет востребованный продукт, но разработка встала. То есть, компания практически не может реализовывать новые пожелания заказчиков и даже исправлять баги, т.к. погоня за «скоростью разработки» в течение десятилетий привела кодовую базу к состоянию, когда:

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

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

Переписать всё - не вариант, нет денег и времени. Инкрементально улучшать - уходит прорва времени, результат незаметен, да и не всегда понятно, как можно постепенно улучшать Big Ball of Mud.

Поэтому ещё раз осознал, что на качество кода забивать всё же нельзя - рано или поздно аукнется.

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

Есть печальный опыт работы в большой организации, продающей много лет востребованный продукт, но разработка встала. То есть, компания практически не может реализовывать новые пожелания заказчиков и даже исправлять баги, т.к. погоня за «скоростью разработки» в течение десятилетий привела кодовую базу к состоянию, когда:

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

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

Переписать всё - не вариант, нет денег и времени. Инкрементально улучать - уходит прорва времени, результат незаметен, да и не всегда понятно, как можно постепенно улучшать Big Ball of Mud.

Поэтому ещё раз осознал, что на качество кода забивать всё же нельзя - рано или поздно аукнется.