Тест Джоэла: 12 шагов к лучшему коду

From The Joel on Software Translation Project

Jump to: navigation, search

Автор: Джоэл Спольски
Переводчик: Марианна Евсеева
В оригинале статья называлась The Joel Test: 12 Steps to Better Code и была написана 9 августа 2000

Вам когда-либо приходилось слышать о SEMA? Это довольно эзотерическая система измерения, насколько хороша команда разработчиков. Нет, подождите! Не уходите по ссылке! Потребуется около шести лет, чтобы только понять эту штуку. Поэтому я выработал свой, полностью безответственный, тест чтобы выставлять оценки команде. Замечательно в нем то, что на него уходит не более трёх минут. Сэкономленного времени хватит на то, чтобы получить медицинское образование.

Contents

Тест Джоэла

  1. Вы используете систему контроля версий?
  2. Можете ли вы собрать проект в один шаг?
  3. Проводите ли вы ежедневные билды?
  4. У вас есть база данных ошибок?
  5. Исправляете ли вы ошибки до написания нового кода?
  6. У вас есть актуальный график работ?
  7. У вас есть спецификация?
  8. У программистов тихие рабочие места?
  9. Используете ли вы лучшие средства, какие только можно купить?
  10. У вас есть тестеры?
  11. Пишут ли кандидаты код во время собеседования?
  12. Проводите ли вы коридорное тестирование удобства использования программ?


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

Оценка 12 — превосходно, 11 — терпимо, но 10 или ниже означает, что у вас серьезные проблемы. Правда состоит в том, что большинство организаций живут с оценкой 2 или 3, и поэтому им нужна серьёзная помощь, потому что такие компании, как Microsoft, имеют 12 постоянно.

Конечно, это не все факторы, которые определяют успех или неудачу. В частности, если у вас великолепная команда, работающая на продуктом, который никому не нужен, ну... люди и не захотят его. И в то же время можно представить себе команду «головорезов», которые не делают ничего из вышеперечисленного, и при этом умудряются производить удивительное программное обеспечение, способное изменить мир. Но, при прочих равных, если у вас есть эти 12 пунктов — значит, у вас есть дисциплинированная команда, которая может воспроизводимо достигать результата.

Вы используете системы контроля версий?

Я работал как с коммерческими системами контроля версий, так и с CVS, который предоставляется бесплатно, и должен сказать, что CVS хороша. Но если вы не имеете контроля версий вообще, вы порветесь на части, пытаясь заставить программистов работать вместе. У программистов нет способа узнать, что остальные сделали. Нельзя быстро откатить ошибки. Ещё одна приятная особенность систем контроля версий — это то, что код копируется на диск каждого члена команды — я никогда не слышал о проекте, который использовал бы контроль версий и потерял бы много кода.

Можете ли вы собрать проект в один шаг?

Под этим я имею в виду: сколько шагов требуется, чтобы собрать приложение из последних исходников? В хороших командах это один скрипт, который вы можете запустить, и он сделает полное обновление дерева исходников из репозитория (checkout), скомпилирует каждую строчку кода с нуля, соберёт EXE (во всех их различных версиях, языках, и комбинациях #ifdef), создаст инсталляционных пакет и финальный носитель — образ CDROM, сайт для загрузки, что угодно.

Если процесс требует более одного шага, он подвержен ошибкам. А когда дата выпуска близка, вам нужен очень быстрый цикл исправления «последней» ошибки, сборки EXE, и т. д. Если требуется 20 шагов, чтобы собрать код или запустить сборщик инсталляционных пакетов, вы сойдете с ума или наделаете глупых ошибок.

Вот почему последняя компания, где я работал, перешла с WISE на InstallShield: нам было нужно, чтобы процесс инсталляции был способен запускаться из скрипта, автоматически, ночью, из планировщика NT, а WISE нельзя было запустить автоматически ночью, так что мы выкинули его. (Ребята из WISE убеждают меня, что их последняя версия поддерживает ночные билды).

Выполняете ли вы ежедневные билды?

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

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

В команде Excel у нас было правило, своего рода «наказание». Тот, кто сломал билд, назначался ответственным за него до тех пор, пока кто-нибудь другой не облажается. Это был хороший стимул не ломать билды и заставить всех знать, как они работают.

Подробнее про это написано в моей статье Ежедневная сборка - ваш союзник и друг.

Используете ли вы базу данных ошибок?

Мне всё равно, что вы говорите. Даже если вы работаете над кодом в одиночку, без базы данных, содержащей все известные ошибки в коде, вы не сможете выдавать качественный код. Многие программисты думают, что они в состоянии держать всё в своей голове. Чушь. Я не могу помнить больше двух-трёх ошибок за раз, а на следующее утро или в спешке перед выпуском даже они забываются. Вам совершенно точно нужно отслеживать все ошибки формально.

База данных ошибок может быть простой или сложной. Любая база данных, чтобы от неё был хотя бы минимальный прок, должна содержать следующую инофрмацию о каждой ошибке:

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

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

Подробнее см. статью про Работа над ошибками малой кровью.

Исправляете ли вы ошибки перед написанием нового кода?

Самая первая версия Microsoft Word для Windows была проектом типа "смертельный бой". Работа над ней повисла навечно. Вся команда вкалывала, не покладая рук, и при этом выпуск откладывался снова, и снова, и снова, и стресс был просто невыносимым. Когда эту чёртову штуку всё-таки выпустили с задержкой в несколько лет, Microsoft отправила всю команду в отпуск в Мексику и провела серьёзный анализ.

Вскрытие показало, что менеджеры проектов так упорно придерживались сроков, что разработчикам приходилось гнать во весь опор и писать ужасный код, потому что исправление ошибок не входило в график работ. Не было даже попытки вести счёт ошибкам. Как раз наоборот. Говорят, что один программист, который должен был написать код для вычисления высоты строки, просто написал "return 12;" и стал ждать сообщения об ошибке, что написаная им функция не всегда правильно работала. План работ был больше похож на список функций, ожидающих перевода их в ранг ошибок. В последствии такой подход получил название «методологии бесконечных дефектов».

Чтобы справиться с этой проблемой, Microsoft повсеместно стала внедрять «методологию отсутствия дефектов». Большинство программистов в компании посмеивалось, поскольку выглядело это так, будто они могли сократить количество ошибок по приказу начальства. В действительности же термин «отсутствие дефектов» значил, что в любой момент времени наиболее важным является устранение ошибок до написания нового кода. И вот почему.

В общем случае, чем больше вы тянете с иправлением ошибки, тем дороже (во временном и денежном измерении) вам это обойдётся.

Например, исправление опечатки или синтаксической ошибки, которую ловит компилятор, вещь по существу весьма банальная.

Если в вашем коде есть ошибка, которая обнаруживается при первом запуске, вы можете тут же её исправить, так как код ещё свеж в вашей памяти.

Если ошибка обнаруживается в коде, который вы написали несколько дней назад, вам потребуется какое-то время, чтобы отследить её, но если вы перечитаете свой код, то сможете всё вспомнить и исправить ошибку в разумные сроки.

Но если вы обнаружили ошибку в коде, который написан несколько месяцев назад, то вы скорее всего уже многое в нём забыли, и исправить её будет гораздо сложнее. Может случиться так, что вам придётся исправлять чужой код, автор которого отдыхает на Карибских островах. В этом случае поиск ошибки — целая наука: приходится долго, методично и тщательно искать, и неизвестно, сколько времени это займёт.

А если ошибка обнаруживается в продукте, который уже продаётся, вы понесёте невероятные расходы, чтобы её исправить.

Вот это и есть главная причина, по которой лучше исправлять ошибки сразу: это занимает меньше времени. Есть и другая причина: легче прогнозировать, сколько времени займёт написание нового кода, чем исправление имеющейся ошибки. Например, если бы я вас попросил оценить, сколько понадобится времени, чтобы написать код для сортировки списка, вы бы легко сделали достаточно точную оценку. Но если бы я попросил вас спрогнозировать, сколько может занять времени исправление ошибки в вашем коде, который не работает, если установлен Internet Explorer 5.5 , вы не сможете даже предположить, потому что не знаете (по определению) причину ошибки. Может уйти 3 дня, а может всего 2 минуты.

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

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

Есть ли у вас актуальный план работ?

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

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

Другой ключевой момент в составлении плана - это то, что он заставляет вас определиться, какую функциональность вы собираетесь реализовать, и выкинуть наименее важные функции. Лучше сделать это сразу, чем страдать от "ползучего фичизма" (creeping featuritis), также известного под названием "расползание возможностей" (scope creep).

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

Есть ли у вас спецификация?

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

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

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

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

Узнайте всё про написание спецификаций, прочтя мою серию из четырёх статей.

У программистов тихие рабочие места?

В литературе уже давно описано увеличение производительности работников умственного труда при предоставлении им рабочего пространства, тишины и уединённости. Классическая книга по управлению компаниями, производящими программное обеспечение, «Человеческий фактор: успешные проекты и команды» (Peopleware:Productive Projects and Teams), обстоятельно описывает пользу этих мер.

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

Проблема в том, что попасть "в поток" не так-то просто. Если вы попытаетесь это дело измерить, то окажется, что требуется в среднем 15 минут, чтобы начать работать с максимальной производительностью. Иногда, когда вы устали или уже выполнили большую часть творческой работы за день, вы уже не сможете войти в неё и остаток дня уже проведете, валяя дурака, исследуя интернет и играя в Тетрис.

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

С программистами дело обстоит весьма серьёзно. Производительность зависит от способности одновременно держать в кратковременной памяти огромное количество различных мелких деталей. Любое вмешательство может вмиг всё это разрушить. Когда вы возвращаетесь к работе, вы не можете вспомнить все эти детали (имена локальных переменных, которые вы использовали, или на каком месте вы остановились в кодировании поискового алгоритма). Поэтому вам приходится то и дело просматривать эти вещи, что в свою очередь, будет замедлять процесс работы до тех пор, пока вы не вернётесь в нормальный режим.

Вот вам простая арифметика. Факты свидетельствуют, что если мы отвлекаем программиста даже на 1 минуту, мы отнимаем у него 15 минут продуктивной работы. К примеру, у нас есть два программиста: Вася и Петя, сидящие в соседних "кубиках". Петя забыл название Unicode версии функции strcpy. Он может найти его самостоятельно, для чего надо 30 секунд, или спросить у Васи, на что уйдёт 15 секунд. Так как он сидит рядом с Васей, почему бы не спросить у Васи. Вася отрывается от работы и теряет 15 минут продуктивной работы (чтобы сэкономить 15 секунд Пети).

Давайте теперь переместим их в отдельные кабинеты со стенами и дверями. Теперь, когда Петя забыл название функции, он может найти его самостоятельно, что по-прежнему займёт 30 секунд, или спросить Васи, на что уйдёт 45 секунд, и при этом ещё придётся вставать и куда-то идти (нелёгкая процедура для большинства программистов, если принять во внимание их физическую форму!). Таким образом, он ищет сам. Петя тратит 30 секунд, но при этом сохраняет 15 минут продуктивной работы Васи. Вот как!

Используете ли вы лучшие средства, какие только можно купить?

Компиляция - это одна из последних задач, которую всё ещё нельзя мгновенно выполнить на домашнем компьютере. Если процесс компиляции занимает у вас больше нескольких секунд, купите себе самый последний продвинутый компьютер. Это сэкономит ваше время. Если на компиляцию уходит 15 секунд, программисты умрут со скуки или переключатся на чтение журнала The Onion (ну или http://www.anekdot.ru/), на что уйдут часы рабочего времени.

Отладка GUI кода при помощи одного монитора - вещь мучительная, если не сказать невозможная. Если вы пишете GUI код, два монитора позволят справится с задачей куда быстрее и легче.

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

На моём предыдущем месте (прим.пер.:это тоже статья) работы системный администратор постоянно присылал мне спам, жалуясь, что на жёстком диске сервера на меня приходится больше - представьте себе - 220 мегабайт дискового пространства. Я обратил его внимание на то, что с учётом сегодняшних цен на жёсткие диски цена того дискового пространства, которое я занимал, была значительно ниже цены туалетной бумаги, которой я пользовался. 10 минут, потраченные на освобождение моей директории, были бы замечательным способом транжирить моё время.

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

Вдобавок к вышесказанному, программиста легко подкупить, предоставив ему самое новое и продвинутое оборудование. Этот способ мотивации обойдётся вам гораздо дешевле, чем выплата конкурентноспособной зарплаты.

У вас есть тестеры?

Если в вашей команде нет тестеров, по крайней мере одного на 2-3х программистов, вы либо выпускаете продукты, кишащие ошибками, либо теряете деньги. Работа, выполненная программистом, обойдётся вам в 100 $/час, а та же самая работа, выполненная тестером - 30 $/час. Экономия на тестерах - это оскорбительно ложная экономия. Я просто возмущён, почему большинство людей не понимают этого!

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

Пишут ли кандидаты на работу код во время собеседования?

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

Вы бы обратились в ресторан, чтобы заказать свадебный стол, не попробовав их еды? Сомневаюсь.

Тем не менее, каждый день программисты принимаются на работу под впечатлением от их резюме или потому, что интервьюеру понравилось с ними болтать. Либо им задавались дурацкие вопросы типа "в чём разница между CreateDialog() и DialogBox()?", ответ на которые легко найти в документации. Вам не важно, запомнили ли они тысячи разных мелочей о программировании или нет, вам нужно понять, способны ли они программировать. Или даже ещё хуже, им задают вопросы типа "Ага!": тип вопросов, которые кажутся лёгкими, когда знаешь ответ, а когда не знаешь - догадаться почти невозможно.

Пожалуйста, перестаньте так делать. Делайте что угодно во время собеседования, но заставьте кандидата написать какой-нибудь код. (Более подробно смотрите в моей статье Искусство проведения интервью.)

Проводите ли вы коридорное тестирование удобства использования программ?

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

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

Самый важный момент, касающийся пользовательского интерфейса, - это то, что вы, показывая свою программу горстке людей (фактически 5-6 человек уже достаточно), очень быстро узнаете, какие проблемы у них возникали. Прочитайте [статью] Джекоба Нильсена (Jakob Nielsen), в которой он объясняет, почему так происходит. Даже если у вас не хватает опыта в создании пользовательского интерфейса, но при этом вы проводите коридорное тестирование, которое ничего не стоит, то с каждым разом интерфейс будет становится всё лучше и лучше.

Четыре способа использования теста Джоэла

  1. Подсчитайте баллы, набранные вашей компанией, и скажите мне, чтобы я мог посплетничать.
  2. Если вы менеджер, используйте эту статью как памятку, чтобы убедиться, что ваша компания работает настолько хорошо, насколько это возможно. Если вы набираете 12 баллов, то можете оставить своих программистов в покое и полностью сконцентрироваться на том, чтобы оградить их от назойливого начальства.
  3. Если вы хотите устроиться программистом в компанию, спросите у вашего предполагаемого работадателя, сколько баллов набирает его компания. Если балл слишком низок, убедитесь, будут ли у вас достаточные полномочия, чтобы всё наладить и изменить ситуацию. Иначе вы мало чего добьётесь и вряд ли будете довольны.
  4. Если вы инвестор и хотите объективно оценить уровень команды программистов, или ваша компания готовится к слиянию с другой компанией, то данный тест даст вам первое приближение.

--- 660450786399301566854864

Personal tools