Ядро FreeBSD - не вполне удачный пример =)

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

Вам понравится искать и исправлять ошибки в такой системе? Когда для исправления некоторых багов нужно аккуратно прошерстить половину кода и исправить все места, где баг повторяется; когда некоторая часть кода автоматически генерируется CASE-средствами (со своими багами); и так далее; когда некоторые баги принципиально нельзя исправить, потому что это потребует архитектурной переделки, на которую нет ни времени, ни сил...

То, что Вы описали пишется через "О". Это -- ужОс!. Я бы посоветовал всё выбросить и создать снова по уму... А то получается, как Вы и говорите "дерьмо, лопата". Или даже прямо руками? :).
Искренне сочувствую. Правда.

Только это не программирование. Речь в докладе идёт о том, чтобы описанных Вами ситуаций не было вообще.

{+}

Подтверждаю. Это самый настоящий ужОс. Причем стоящий бешеных бабок, использование которых проверить почти невозможно - широкое поле для откатов.
С нуля никто переделывать не даст - уже затраченные деньги никто потерять не хочет.
Вот тут (http://www.nestor.minsk.by/sr/2004/01/40106.html) хорошо написано.

Я у себя в дневнике давал вот такую ссылку (http://www.relevancellc.com/blogs/?p=36#comment-545) на ту же тему =)

Я бы переделал. Дешевле будет, уверяю:)

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

1) У менеджмента нет оснований верить оценкам сроков/стоимости, которые дают программисты. На практике эти оценки всегда неверны, и всегда в одну и ту же сторону - но неизвестно, во сколько раз =)

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

3) Представьте, что Вы торопитесь занять новую рыночную нишу. Аналогичные аргументы.

4) Представьте, что сроки и стоимость оговорены контрактом.

5) Представьте, что нужно как можно скорее произвести впечатление на заказчика в условиях тендера.

6) После выпуска очередной версии задачи техподдержки перекладываются на программистов с более низкой зарплатой (maintenance mode), а более высокооплачиваемые (developers) переходят на следующий проект. Прямой резон не тратить зря время дорогостоящих разработчиков.

7) Переработка даже одной небольшой подсистемы может задержать развитие всего проекта, если с этой подсистемой многое взаимодействует.

И так далее.

Я всё это знаю из американской литературы по программированию 70х годов:). "Капитализм -- говно"(с)Лозунг анархистов.

{+}

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

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

Собственно, в Вашей фразе -- вся суть знаменитой книги Брукса. Конечно, нужна координация. Это самое главное. Просто в старых инженерных областях всё это отработано веками. Прежде всего в строительстве (задумайтесь, например, о постройке киевской Святой Софии в X веке), кораблестроении, а потом уже в авиации, радиотехнике, ракетостроении...

Почему-то только "программисты" упорствуют в своём стремлении плодить и разгребать дерьмо:).

{+}

"Почему-то"... Когда мы построим сотню операционных систем уровня сложности, сравнимого с Windows или Linux, мы будем хорошо понимать, как построить сто первую.


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

Вынесет всё - и широкую, ясную
Грудью дорогу проложит себе.
Жаль только - жить в эту пору прекрасную
Уж не придется - ни мне, ни тебе.

А я бы ещё пожил:) Жаль, что пора прекрасная очень далека ещё.

Невозможно выбросить - нет ресурсов для "создания снова по уму". Вы ведь не теоретик, а инженер, не можете этого не понимать.

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

Я всё понимаю. Ресурсы, конечно, есть, но их не выделяют. Хотят мучаться. На здоровье. Именно потому, что я инженер, я бы переделал. Мне приходилось переделывать казавшееся неподъёмным. Манагер, конечно, ни за что не согласится, ясно дело. Слава КПСС, у меня нет манагеров:).

По приёмам мы с Вами полностью солидарны. Глупо отрицать их необходимость.

{+}