То, чего нельзя делать ни в коем случае (программисту)

На этот раз я перевел статью о программировании. Автор в свое время работал на высоких постах в Microsoft, в частности он разрабатывал обьектную модель Visual Basic для Excel. Работал в Viacom и Juno. Организовал свою собственную фирму-разработчика Fog Creek и вот уже 10 лет успешно ее развивает. Основная идея его фирмы - наилучшие условия работы для лучших разработчиков, она была создана когда он отчаялся найти идеальное место работы, где ему бы все нравилось.

Данная статья написана 9 лет назад и всее ее предсказания прошли проверку временем. Именно после версии 4.0 и началось обвальное падение популярности браузера Netscape Navigator, только ускорившееся после выхода версии 6.0. А ведь он был одним из первых и самым попуялрным браузером в свое время, IE появился гораздо позже и начинал с нуля на уже захваченном другими рынке. Через несколько лет команда разработчиков Netscape была расформированная и компания умерла. Правда на основании открытых исходных кодов вырос Firefox, но он начал набирать популярность намного позже и во многом благодаря следованию описанным в статье принципам.

Джоэл Сполски, четверг, 6 апреля 2000.

Скоро выпустят общедоступную бета-версию браузера Netscape 6.0. Версии 5.0 не было. Последнее серьезное обновление до 4.0 было три года назад. Три года - очень долгий срок в интернете. И все это время Netscape бессильно наблюдала за стремительным сокращением рыночной доли своего браузера.

Но не слишком ли самонадеянно критиковать их за длительную задержку, на которую они пошли сознательно?

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

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

Они не первые совершили такую ошибку. Borland сделала то же самое, купив Argo и попытавшись превратить ее в dBase для Windows, обреченный с самого начала проект занял столько времени, что после выпуска не выдержал конкуренции с Microsoft Access. Они повторились, переписав с нуля Quattro Pro с поразительно убогими возможностями. Такую же ошибку чуть не совершила Microsoft, попытавшись переписать Word для Windows с нуля, в компании стараются не вспоминать об обреченном с рождения и вскоре закрытом проекте Puramid. К счастью для Microsoft ее разработчики продолжали работать со старым кодом и всегда могли предоставить клиентам хоть что-то, так что финансовя катастрофа не переросла в стратегическую.

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

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

Писать код проще чем читать.

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

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

Почему он ужасен?

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

Перед выпуском новой версии электронных таблиц от Borland для Windows пресса постоянно цитировала хвастливые высказывания основателя Borland Филиппа Кана (Philippe Kahn) преимущества Quattro Pro над Excel из-за того, что он переписан с нуля. Исходный код полностью новый! Как будто он может проржаветь.

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

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

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

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

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

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

И при этом вы тратите огромное количество денег на написание уже написанного кода.

А есть ли альтернатива? Вроде бы никто не спорит с низкой оценкой качества старого кода Netscape. Знаете, может он и был плох, но отлично работал на огромном количестве компьютеров.

Когда программисты называют код ужасным (как обычно), скорее всего это вызвано одной из трех причин:

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

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

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

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

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

Things You Should Never Do, Part I - Joel on Software


Комментарии

То, чего нельзя делать ни в коем случае (программисту) — Комментарии (4)

Добавить комментарий