Мастерство

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

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

1 декабря 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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