ДонНТУ   Портал магистров
Назад

Вещи, которые Вы никогда не должны делать

Автор: Джоэл Спольски

Перевод: Алексей Кисель

Источник (англ.): Источник оригинальной статьи

Netscape 6.0, наконец, собираются запустить  первое публичное бета-тестирование. 5-й версия этого браузера до открытого тестирования так не дошла. Последний крупный релиз, а это была версия 4.0, состоялся почти три года назад. Три года - это целая вечность  в мире Интернета. За это время Netscape сидел беспомощно, и их доля на рынке упала.

Это заставляет меня критиковать их из-за долгого  ожидания релиза. Они ведь не сделали это нарочно, правда? Правда.  И при этому они сделали это, сделав один худшую стратегическую ошибку, которую может допустить компания, которая занимается разработкой любое программное обеспечение.

Они решили переписать код с нуля.

Netscape не была первой компанией,  которая  сделала эту ошибку. Borland совершили ту же ошибку, когда они купили Араго и попытался внедрить ее в DBase для Windows.  Это был обреченный проект, который так и не закончили в момент, когда Microsoft Access уже завоевал рынок.  Позже они сделали это еще раз,  переписывая Quattro Pro с нуля, и удивив в конечном итоге пользователей мизирным функционалом. Microsoft почти совершили ту же ошибку, пытаясь переписать Word для ОС Windows с нуля в обреченный проект под названием Пирамида который был закрыт и забыт. К счастью для Microsoft, они никогда не переставали работать со старой версией продукта, так что они могли попутно что-то продавать, что делало провальные проекты просто финансовыми издержками, но не стратегическими катастрофами.

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

В этом и причина, что программисты всегда хотят выбросить код и начать все сначала. Причина в том, что они думают, что старый код беспорядочен. А вот интересное наблюдение: они, вероятно, ошибаются. Причина того, что они думают, что старый код плох из-за основного фундаментального закона программирования: "Читать код труднее, чем писать".

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

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

Почему это беспорядок?

"Хорошо", говорит программист: "посмотрите на эту функцию. Это две страницы! И я не знаю что делает половина из этих вызовов API"

До продажи новых таблиц Borland для ОС Windows  Филипп Кан, яркий основатель Borland, много хвастается в прессе о том, как Quattro Pro будет гораздо лучше, чем Microsoft Excel, потому что он был написан с нуля.  Новые исходный код! Как будто исходный код ржавеет.

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

Вернемся  в функции, которая занимает две страницы. Да, я знаю, это всего лишь простая функция для отображения окна, но она обросла непонятным кодом, и никто не знает почему. Я вам скажу почему: это исправление ошибок. Один из них исправляет ошибку, которая была, когда программу пытались установить на компьютере без  Internet Explorer. Еще одно исправление предназначено для условий с  недостаточным количеством памяти. Еще одно исправление для  ошибки, которая произошла, когда приложение находится на дискете, и пользователь выдергает ее в середине процесса. Этот вызов LoadLibrary уродлив, но это позволяет работать на старых версиях Windows 95.

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

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

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

Вы тратите огромные суммы для написания кода, который уже существует.

Есть ли альтернатива? Говорят, что старая база кода Netscape была очень плохо. Код действительно мог быть плохим, но, вы знаете, что? Он работал чертовски хорошо в очень многих реальных компьютерных систем мира.

Когда программисты говорят, что их код ужасен(они всегда так говорят), есть три вещи, которые не так.

Во-первых, имеют место архитектурные проблемы. Код не был организован правильно. Сетевой код показывает свои диалоговые окна из середины, хотя  это должно были обрабатываться в коде пользовательского интерфейса. Эти проблемы могут быть решены единожды,  после тщательного перемещение кода, рефакторинга, и и изменение интерфейса. Это мог бы сделать один программист, поработавший тщательно, и исправив все сразу изменения, так что никто не нарушил. Даже довольно крупные архитектурные изменения можно сделать, не выбрасывая код. На проекте Juno мы потратили несколько месяцев изменяя архитектуру по следующему принципу: просто перемещая код в нужные места, очищая ненужное, создавая базовые классы, где это имело  смысл, а также делая резкие границы между модулями. Но мы сделали это осторожно, с нашей существующей базы кода, и это не привело к новым ошибкам или выбрасыванию рабочего кода.

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

В-третьих, этот код может оказаться чертовски уродливым.  В одном из проектов,  на котором я работал,  на самом деле было тип данных который можно назвать FuckedString. Еще один проект начался с использования конвенции, начинать названия переменных-членов с подчеркиванием, но позже переключился на использование более стандартных "m_". Таким образом, половина функций началось с "_", а половина с "m_". Это выглядело уродливо. Честно говоря, это проблему можно решить в течение пяти минут с помощью макроса в Emacs, а не начинать с нуля.

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

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