Мастерство

Joel on Software - Мастерство

Мастерство

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

Переводчик: Станислав Миронов

1 декабря 2003

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

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

Написание кода это не производство, не всегда это и мастерство (хотя может оказаться и им), это -- дизайн. Дизайн -- это та туманная область, в которой вы добавляете ценность быстрее, чем себестоимость. Журнал New York Times писал восхищённые статьи о iPod и о том, что Apple одна из немногих компаний, знающих как использовать хороший дизайн для повышения ценности. Но я достаточно говорил о дизайне, я хочу немного поговорить о мастерстве: что это и как вы его определяете.

Я бы хотел рассказать вам об одном куске кода, который я переписывал для CityDesk 3.0: код импорта файлов. (Реклама: CityDesk -- это лёгкая в использовании система управления публикациями производства моей компании.)

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

Это превратилось в отличный пример того как "последний 1% кода занимает 90% времени". Первый набросок кода выглядел так:

Открыть файл

Прочитать его весь в большой массив байтов

Поместить этот массив в запись

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

Большая Ошибка обнаружилась когда я проводил стресс-тестирование и перетащил файл размером 120 Мб в CityDesk. В наше время, люди вряд ли будут размещать 120-мегабайтные файлы на своих веб-сайтах. Но ведь и это возможно. Программа сработала, но работала почти минуту и ничем своей акивности не проявляла -- программа попросту замерла и выглядела зависшей. Это, конечно, не было идеальным решением.

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

Из одного потока, проводя частые опросы входящих событий

Запустив второй поток и аккуратно синхронизируясь с ним

Запустив второй процесс и синхронизируясь с ним менее аккуратно

Мой опыт с №1 показывает, что это никогда не работает как надо. Очень трудно убедиться в том, что весь код вашей программы будет безопасно работать в то время, пока копируется файл. И Eric S. Raymond убедил меня, что потоки обычно не такое хорошее решение, как отдельные процессы: безусловно, годы опыта показали мне, что программирование многопоточных приложений создаёт дополнительную сложность и даже привносит новые категории ошибок ужасно опасных ошибок типа "HeisenBug". №3 показался хорошим решением, особенно в свете того, что наша используемая база данных многопользовательская и ничего не имеет против множества процессов, одновременно работающих с ней. Так что это я и планирую сделать после того как вернусь из отпуска после Дня Благодарения.

Хотя, обратите внимание на общую картину. Мы ушли от простого чтения файла и сохранения его в базе данных к чему-то значительно более сложному: запустить дочерний процесс, приказать ему прочитать файл и сохранить его в базе данных, добавить индикатор выполнения и кнопку отмены дочернему процессу и обеспечить некий механизм, с помощью которого дочерний процесс сможет сообщить родительскому о том, что файл получен и может быть показан. Также придётся проделать некоторую работу по передаче аргументов дочернему процессу через командную строку, и убедиться что фокус окна ведёт себя как и ожидается, и предусмотреть случай, когда пользователь закрывает систему пока идёт копирование файла. Я бы предположил, что когда всё было бы сделано, у меня было бы в десять раз больше кода для обработки больших файлов -- кода, который, может быть, только 1% пользователей и увидят.

И, конечно, определённый тип программистов будет спорить, что моя новая архитектура с дочерними процессами стала хуже, чем была. Она "раздута" (из-за дополнительных строк кода). В ней больше возможностей для ошибок из-за дополнительных строк кода. Это "стрельба из пушки по воробьям". Скажут, что в некотором роде это показывает почему Windows такая плохая операционная система. Зачем все эти линейки прогресса? - спросят они. Просто нажмите Ctrl-Z, а потом несколько раз повторите "ls -l" и посмотрите растёт ли размер файла!

Мораль истории в том, что иногда исправление 1% ошибок занимает 500% усилий. Это присуще не только программированию, что я могу сказать после того как я занимался всеми этими строительными работами. На прошлой неделе, наконец, наши рабочие наконец-то сделали последние штрихи к нашему новому офису Fog Creek. Это состояло из установки на входные двери блестящего синего акрила, окантованного алюминиевой рамкой, привинченной шурупами через каждые 20 см. Если вы посмотрите внимательно на фотографию, алюминиевые рамки обрамляют со всех сторон каждую дверь. Когда двери сходятся, то две рамки оказываются прилегающими друг к другу. Вы не увидите это на фотографии, но винты в серединных секциях почти, но не совсем совпадают. Они, может быть, на 2 миллиметра, но расходятся. Плотник, сделавший их, отмерял аккуратно, но он устанавливал рамки когда двери были на полу, то есть ещё не установлены, но "опс!", вдруг стало очевидно, что они не совпадают.

Возможно, это и не так уж необычно -- в нашем офисе много шурупов, которые не винчены точно по линейке. Проблема в том, что исправление этого уже после того, как отверстия просверлены -- необычайно дорого. Несмотря на то, что правильное положение шурупов всего в паре миллиметров от того как есть сейчас, вы не можете просто просверлить новые отверстия -- скорее всего вам придётся заменить всю дверь. Это не стоит того. Это как раз тот случай, когда исправление 1% ошибок займёт 500% усилий и объясняет почему в нашем мире столько много вещей хороших на 99%, а не на все 100%. (Наш архитектор не прекращает говорить об одном очень, очень дорогом доме в Аризоне, где каждый шуруп точно выверен.)

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

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

В английском оригинале статья называется Craftsmanship

Джоель Спольски - основатель Fog Creek Software, небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky

Содержание раздела