Пять миров
Joel on Software - Пять миров
Пять миров
Автор: Joel Spolsky
Переводчик: Максим Михальчук
Редактор: Евгений Дурцев, Мария Казачкова
понедельник, 6 мая 2002г
Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга..
Вы - разработчик программного обеспечения. Я тоже. Но у нас могут быть совсем неодинаковые цели и требования. На самом деле, существует несколько различных миров разработки ПО, и к разным мирам применимы разные правила.
Допустим, Вы читаете книжку по UML моделированию, а в ней нигде не говорится о её бессмысленности для программирования драйверов. Или же Вы читаете статью, утверждающую, что "20МБ среда [требующаяся для .NET] - это НЕ проблема", а она не содержит очевидного: если Вы пытаетесь написать код для пейджера с 32КБ ROM, то это ещё та проблема!
Я считаю, что в программировании есть пять миров, иногда пересекающихся друг с другом, а в основном нет. Это:
При чтении одной из последних книг по Экстремальному программированию, одной из замечательных книг Стива МакКонннелла, сайта "Джоэль о софте" или журнала "Разработка программного обеспечения Вы видите много утверждений, как же разрабатывать ПО, однако вряд ли Вы когда-либо замечали малейшее упоминание, о каком же всё-таки типе разработки они ведут речь, что довольно-таки плохо, ведь иногда в разных мирах необходимо разрабатывать по-разному.
Давайте кратко пройдёмся по этим категориям.
Ширпотреб - это ПО, которое должно "серьёзно" использоваться многими людьми. Оно может быть обёрнуто в целлофан и продаваться в сети компьютерных магазинов, или скачиваться по Интернет. Оно может быть коммерческим, шароварным, с открытым исходным кодом, под лицензией GNU или любым другим - главное в том, что такое ПО будет установлено и будет использоваться тысячами или миллионами людей.
Разработка ширпотреба сталкивается со своими проблемами из-за его особенных свойств:
Существует три наибольшие вариации ширпотреба. ПО с открытым исходным кодом часто разрабатывается в условиях, когда за разработку никому не платят, что кардинально меняет его динамику. Например, вещи, не считающиеся "прикольными", обычно не реализовываются командой добровольцев и, как красноречиво обращает наше внимание Метью Томас, это может повредить юзабилити. Разработка обычно географически рассредоточена, что выливается в абсолютно другое качество командного общения. В мире открытых исходников редко происходят личные встречи вокруг досок с прямоугольниками и стрелочками, поэтому те решения по дизайну, которые выигрывают от рисования, обычно плохо решаются в подобных проектах. Как результат, географически рассредоточенные команды намного лучше преуспели в клонировании существующего ПО, для которого не требуется или требуется принимать очень мало решений по дизайну.
Консультационное ПО - это вариант ширпотреба, который требует так много настроек и установок, что для его установки нужна целая армия консультантов по с непомерными ценами. Пакеты CRM и CMS обычно попадают в данную категорию. Может возникнуть ощущение, что эти пакеты на самом деле совсем ничего не делают, а лишь являются предлогом для прибытия армии консультантов по $300 в час. Хоть консультационное ПО и притворяется ширпотребом, высокая стоимость реализации означает, что оно больше похоже на внутреннее.
Коммерческое веб-ПО, такое как Salesforce.com или даже более тепличный вариант eBay всё равно должно быть простым в использовании и выполняться на множестве браузеров. Хотя у разработчиков есть роскошь (по крайней мере) некоторого контроля над средой "развёртывания" - компьютерами в информационном центре - им необходимо иметь дело с большим разнообразием веб-браузеров и большим количеством пользователей, поэтому я считаю данное ПО вариацией ширпотреба.
Внутреннее ПО должно лишь работать в одной ситуации на компьютерах одной компании, что делает его разработку намного проще. Вы можете сделать множество предположений о среде, в которой оно будет идти. Вы можете потребовать определённую версию Internet Explorer, Microsoft Office или Windows. Если нужен график, пусть за Вас его построит Excel; у всех в нашем отделе есть Excel (но только попробуйте такое с ширпотребом и вы уже устранили половину своих потенциальных покупателей).
Юзабилити здесь не так важно, ведь программным обеспечением необходимо будет пользоваться небольшому количеству людей, да и у них по существу нет никакого выбора, так что им придётся как-то уж с ним уживаться. Скорость разработки более важна. Так как вся стоимость разработки ложится всего лишь на одну компанию, количество обоснованно выделенных ресурсов на разработку значительно меньше. Microsoft может себе позволить потратить $500,000,000 на разработку операционной системы, которая обойдётся среднему пользователю примерно в $80. Но когда Detroit Edison разрабатывает платформу для торговли электроэнергией, размер инвестиции должен иметь смысл для одной компании. Для получения приемлемой окупаемости нельзя тратить столько же, сколько и на ширпотреб. Поэтому увы, но большинство внутреннего ПО просто вызывает отвращение.
Встроенное ПО имеет то уникальное свойство, что оно идёт вместе с куском железа, и в большинстве случаев не может быть обновлено. Это совсем другой мир, скажу я Вам. Требования к качеству намного выше, ведь другого шанса не будет. Возможно, придётся иметь дело с процессором намного более медленным, чем типичный процессор персоналки, поэтому код придётся долго оптимизировать. Быстрый код важнее красивого кода. Доступные устройства ввода-вывода могут быть очень ограничены.
Игры уникальны по двум причинам. Во-первых, экономика разработки игр ориентирована на хиты. Некоторые игры становятся хитами, но намного больше игр проваливаются, поэтому если Вы хотите делать деньги на разработке игр, это необходимо понять и иметь портфолио игр, так чтобы хит-блокбастер покрывал расходы провалов. Это больше похоже на кино, чем на программное обеспечение.
Ещё большей проблемой при разработке игр является наличие всего одной версии. Как только Ваши пользователи прошли Duke Nukem 3D, они не будут обновляться до Duke Nukem 3.1D только ради исправления нескольких ошибок и нового оружия. За некоторым исключением после прохождения игры до конца, опять в неё играть довольно скучно. Поэтому у игр такие же требования к качеству, как и у встроенного ПО, и существует невероятный финансовый императив правильно сделать всё с первого раза. Разработчики ширпотреба могут позволить себе роскошь знания, что если версия 1.0 не удовлетворяет желания пользователей и не продаётся, то, возможно, версия 2.0 будет.
И, наконец, Одноразовый код, который создаётся на время исключительно с целью получения чего-либо ещё, что никогда более не понадобится. К примеру, маленький скрипт, перемалывающий полученный входной файл в какой-нибудь другой формат, нужный всего один раз.
Есть, наверное, и другие типы разработки программ, которые я уже забыл.
Важно знать, что когда бы Вы ни читали книгу о методологии программирования, написанную гуру/консультантом по разработке ПО, работающим на полную ставку, можете быть спокойны, что он говорит о разработке внутреннего, корпоративного ПО. Не ширпотребного, не встроенного и, конечно же, не игр. Почему? Потому что именно корпорации нанимают этих гуру. Они им платят. (Поверьте мне, id software никогда и ни за что не собирается нанимать Эда Йордона, чтобы тот размышлял о структурном анализе.)
На прошлой неделе Кент Бэк заявил, что системы отслеживания ошибок не нужны при экстремальном программировании, потому что комбинация парного программирования (с постоянной проверкой кода) и разработка, основанная на тестах (гарантирующая 100% покрытия кода автоматическими тестами) означает, что у Вас вряд ли когда-либо будут ошибки. Это показалось мне неправильным. Я заглянул в нашу собственную базу хранения ошибок, чтобы проверить, каких типов ошибок в ней особенно много.
Имеющий глаза да увидит – я обнаружил, что очень мало тамошних ошибок могли бы быть обнаружены парным программированием или тестами. Многие наши "ошибки" на языке экстремального программирования называются историями – по существу, это лишь запросы о возможных улучшениях. Мы используем систему отслеживания ошибок для запоминания, выставления приоритетов и управления всеми маленькими улучшениями и большими возможностями, которые мы хотели бы реализовать.
Много других ошибок были обнаружены только лишь после длительного использования на месте. Проблема с польской клавиатурой. Нет способа, которым парное программирование поможет найти такие вот ошибки. Ещё есть логические ошибки использования различных возможностей, которые никогда с нами не случались. Чем больше и сложнее программа, тем больше взаимодействий между возможностями, о которых Вы и не догадываетесь. Определённая последовательность символов ({${?, если хотите знать) вводит в замешательство лексер. Некоторые ftp-сервера сообщают об ошибке при попытке удаления несуществующего файла (наш на такое не жалуется, поэтому такого никогда с нами не случалось).
Я внимательно изучил каждую ошибку. Из 106 ошибок, которые мы исправили в первом пакете обновления для CityDesk, ровно 5 могли бы быть предотвращены с помощью парного программирования или разработки на основе тестов. У нас на самом деле было больше ошибок, о которых мы уже знали, но не считали их важными (только если нас не поправят наши покупатели!), чем ошибок, которые могли бы быть выловлены методами ХР.
Но Кен прав, только вот для других типов разработки. Для большинства корпоративных приложений ни одна из рассмотренных выше не считалась бы ошибкой. Программа вылетает от неверного ввода? Запустите ещё раз, и на этот раз следите за своими {${?! И мы используем только лишь один FTP-сервер и никто во всей компании не использует Польские Windows.
Большей частью разработка ПО одинакова вне зависимости от проекта, но не вся. Когда Вам говорят о методологии, подумайте о том, как она согласуется с делаемой именно Вами работой. Подумайте, откуда говорящий. Стив МакКоннелл, Стив Магуайр и я все из одной песочницы: мира ширпотребных электронных таблиц, написанных в Редмонде, штат Вашингтон. И у таких у нас высокая планка на лёгкость в использовании и низкая для ошибок. Большинство других гуру методологии зарабатывают свой кусок хлеба, консультируя внутренние корпоративные разработки, поэтому о них они и говорят. В любом случае, мы должны уметь учиться друг у друга.
В английском оригинале статья называется Five Worlds
Джоель Спольски - основатель Fog Creek Software, небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky
