Автор: Джоэл Сполски
Переводчик: Марианна Евсеева
Редактор: Дмитрий Майоров
9 августа 2000
В английском оригинале статья называется The Joel Test: 12 Steps to Better Code
Переводчик: Марианна Евсеева
Редактор: Дмитрий Майоров
9 августа 2000
Вы когда-либо слышали о программе SEMA? Это весьма эзотерическая система, предназначенная для определения того, насколько хороша команда разработчиков. Нет,погодите, не ходите туда, а то потратите лет шесть только чтобы понять, что там написано. Я предлагаю вам свой собственный, совершенно безответственный и несерьёзный тест для определения качества команды разработчиков. Главное его преимущество в том, что он отнимет у вас от силы три минуты. Сэкономленного времени хватит на то, чтобы получить медицинское образование.
Тест Джоэла
|
Отличительной чертой теста Джоэла является то, что вы сможете быстро ответить да или нет на каждый из его вопросов. Вам не придётся подсчитывать количество-строк-кода-в-день или среднее-количество-ошибок-на-модуль. За каждый положительный ответ начисляйте один балл. Главный недостаток теста в том, что его действительно не следует применять для оценки безопасности программного обеспечения ядерных электростанций.
12 баллов - отлично, 11 - хорошо, 10 и менее - у вас серьёзные проблемы. Большинство существующих организаций, производящих программное обеспечение, набирают всего 2 или 3 балла, и им нужна серьёзная помощь, потому что компании вроде Microsoft работают на 12-ти всё время.
Естественно, это не единственный фактор, который определяет успех или поражение: например, даже если у вас выдающаяся команда разработчиков, но они работают над продуктом, который никому не нужен, то люди всё равно просто не будут его покупать. И в то же время можно представить себе команду "головорезов", которые не делают ничего из вышеперечисленного, и при этом умудряются производить удивительное программное обеспечение, способное изменить мир. Но при прочих равных, если вы наберёте эти 12 баллов, то получите организованную команду, которая сможет постоянно производить хорошие продукты.
1. Пользуетесь ли вы системой контроля версий?
Я работал как с коммерческими системами контроля версий, так и с CVS, который предоставляется бесплатно, и должен сказать, что CVS достаточно хорош. Но вот если у вас нет никакой системы контроля версий, то вы напрасно потратите свои усилия, пытаясь заставить разработчиков работать сплочённо. У них не будет никакой возможности узнать, что делают другие. Станет невозможным легко откатиться назад после внесения ошибок. Ещё одно преимущество использования систем контроля версий - это то, что рабочие копии исходного кода есть на жётских дисках всех разработчиков. Я никогда не слышал о каком-либо проекте, в котором при использовании системы контроля версий было потеряно большое количество кода.
2. Можете ли вы собрать продукт за один шаг?
Под этим я подразумеваю, сколько шагов вам потребуется, чтобы собрать версию для продажи из последнего исходного кода. В хороших командах есть один-единственный скрипт, который вы можете запустить. Он выполняет полную проверку с нуля, пересобирает каждую строку кода, создаёт исполняемые файлы для всех платформ, языков и комбинаций #ifdef, инсталляционный пакет, СDROM, весь веб-сайт и т.п. Если данный процесс занимает более одного шага, то он подвержен ошибкам. И когда вы подойдёте вплотную к созданию версии для продажи, вам захотчется иметь очень быстрый цикл исправления последних ошибок, создания исполняемых файлов и т.п. Если вы управляетесь со всем этим за 20 шагов, то скоро сойдёте с ума и наделаете кучу глупых ошибок. По этой причине последняя компания, в которой я работал, перешла с WISE на InstallShield; нам было необходимо, чтобы инсталляционный процесс мог автоматически запускаться из скрипта, созданного накануне вечером при помощи планировщика задач NT. WISE не мог запускаться из планировщика накануне вечером, и поэтому мы от него отказались. (Добрые люди, работающие в WISE, уверяют меня, что их последняя версия поддерживает ночные билды).
3. Выполняете ли вы ежедневные билды?
Иногда при использовании системы контроля версий один разработчик случайно вносит изменения, которые нарушают нормальный ход сборки. Например, добавляет новый файл с исходным кодом, и на его машине всё компилируется просто замечательно, но при этом забывает поместить этот файл в репозиторий. Он гасит свою машину и в хорошем настроении идёт домой. Но после этого уже никто не может работать, и все вынуждены тоже идти по домам, причём в гораздо худшем настроении.
Нарушение хода сборки - вещь настолько распространённая и неприятная, что имеет смысл проводить ежедневные билды, чтобы обнаруживать сбои как можно раньше. В больших командах оптимальный способ - это проводить ежедневные билды, скажем, в обед. Каждый может вносить сколько угодно изменений до обеда. Когда люди возвращаются, билд уже завершён. Получилось - хорошо, все берут последнюю версию и продолжают работать. Нет - вы его исправляете, при этом все остальные могут продолжать работать на утренней рабочей версии.
В команде Excel у нас было правило, своего рода "наказание". Тот, кто сломал билд, назначался ответственным за строительство до тех пор, пока кто-нибудь другой не облажается. Это был хороший стимул не ломать билды и заставить всех знать, как они работают.
Подробнее про это написано в моей статье "Ежедневное построение - ваш союзник и друг".
4. Используете ли вы базу данных ошибок?
Мне всё равно, что вы говорите. Даже если вы работатете над кодом в одиночку, без базы данных, содержащей все известные ошибки в коде, вы не сможете выдавать качественный код. Многие программисты думают, что они в состоянии держать всё в своей голове. Чушь. Я не могу помнить больше двух-трёх ошибок за раз, а на следующее утро в спешке перед подготовкой версии к выпуску даже они забываются. Вам совершенно точно придётся формально следить за ошибками.
База данных ошибок может быть простой или сложной. Любая база данных, чтобы от неё был хотя бы минимальный прок, должна содержать следующую инофрмацию о каждой ошибке:
- подробное описание шагов, необходимых для воспроизведения ошибки;
- ожидаемое поведение;
- наблюдаемое (неправильное) поведение;
- кому поручено исправить;
- исправлено или нет.
Если единственная причина, по которой вы не отслеживаете ошибки, это сложность отслеживающего ошибки программного обеспечения, просто начертите таблицу из пяти колонок, и начните ей пользоваться.
Подробнее см. статью про Работа над ошибками малой кровью.
5. Исправляете ли вы ошибки перед написанием нового кода?
Самая первая версия Microsoft Word для Windows была проектом типа "смертельный бой". Работа над ней повисла навечно. Вся команда вкалывала, не покладая рук, и при этом выпуск откладывался снова, и снова, и снова, и стресс был просто невыносимым. Когда эту чёртову штуку всё-таки выпустили с задержкой в несколько лет, Microsoft отправил всю команду в отпуск в Мексику и провёл серьёзный анализ.
Вскрытие показало, что менеджеры проектов так упорно придерживались сроков, что разработчикам приходилось гнать во весь опор и писать ужасный код, потому что исправление ошибок не входило в общий план действий. Не было даже попытки вести счёт ошибкам. Как раз наоборот. Говорят, что один программист, который должен был написать код для вычисления высоты строки, просто написал "return 12;" и стал ждать сообщения об ошибке - написаная им функция не всегда правильно работала. План работ был больше похож на список функций, проверка которых переводила их в ранг ошибок. Такой подход получил название "метода бесконечных дефектов".
Чтобы справиться с этой проблемой, Microsoft повсеместно стал внедрять "метод отсутствия дефектов". Большинство программистов в компании посмеивалось. Выглядело это так, будто они могли сократить количество ошибок по приказу начальства. В действительности же термин "отсутствие дефектов" трактовался следующим образом. В любой момент времени наиболее важным является исправление ошибок донаписания нового кода, и вот почему.
В общем случае чем больше вы тянете с иправлением ошибки, тем дороже (во временном и денежном отношении) вам это обойдётся.
Например, исправление опечатки или синтаксической ошибки, которую поймал компилятор, вещь по существу весьма банальная.
Если в вашем коде есть ошибка, которая обнаруживается при первом запуске, вы можете тут же её исправить, так как код ещё свеж в вашей памяти.
Если ошибка обнаруживается в коде, который вы написали несколько дней назад, вам потребуется какое-то время, чтобы отследить её, но если вы перечитаете свой код, то сможете всё вспомнить и исправить ошибку в разумные сроки.
Но если вы обнаружили ошибку в коде, который написан несколько месяцев назад, то вы скорее всего уже многое в нём забыли, и исправить её будет гораздо сложнее. Может случиться так, что вам придётся исправлять чужой код, автор которого отдыхает на Карибских островах. В этом случае поиск ошибки - целая наука: приходится долго, методично и тщательно искать и неизвестно, сколько времени это займёт.
А если ошибка обнаруживается в продукте, который уже продаётся, вы понесёте невероятные расходы, чтобы её исправить.
Так что первая причина, по которой лучше исправлять ошибки сразу: это занимает меньше времени. Есть и другая причина: легче прогнозировать, сколько времени займёт написание нового кода, чем исправление имеющейся ошибки. Например, если бы я вас попросил оценить, сколько понадобится времени, чтобы написать код для сортировки списка, вы бы легко это сделали. Но если бы я попросил вас спрогнозировать, сколько может занять времени исправление ошибки в вашем коде, который не работает, если установлен Internet Explorer 5.5 , вы не сможете даже предположить, потому что не знаете (по определению) причину ошибки. Может уйти 3 дня, а может всего 2 минуты.
Что я хочу всем этим сказать - если у вас есть план работ, в котором большое количество ошибок остаётся неисправленным, этот план ненадёжен. Но если вы исправили все известные ошибки и единственное, что осталось - это новый код, ваш план намного более точен.
Ещё одно преимущество методики нулевых дефектов в том, что вы сможете гораздо быстрее реагировать на конкуренцию. Некоторые программисты это понимают следующим образом - продукт надо разрабатывать так, чтобы его можно было выпустить в любой момент. Более того, если ваш конкурент представил какую-то супер новую убийственную функциональность и переманивает ваших клиентов, вы можете добавить эту же функцию и незамедлительно выпустить очередную версию, не исправляя при этом большое количество накопившихся ошибок.
6. Есть ли у вас актуальный план работ?
Что заставляет нас планировать? Если ваш код нужен для дела, есть масса причин, по которым хотелось бы знать, когда он будет закончен. Программисты очень не любят планы работ. "Будет сделано тогда, когда будет сделано!" - вопят они на управляющий персонал.
К сожалению, такая оценка не подходит. Слишком много плановых решений, которые необходимо принять до выпуска: демонстрации, выставки, реклама и т.д. Единственное решение - это составить план, установить сроки и придерживаться их.
Другой ключевой момент в составлении плана - это то, что он заставляет вас определиться, какую функциональность вы собираетесь поддержать, и выкинуть наименее важные функции. Лучше сделать это сразу, чем страдать от"ползучего фичуризма" (creeping featuritis), также известного под английским названием "scope creep".
Составить план и придерживаться его не так уж сложно. Почитайте мою статью, в которой описан простой способ делать отличные планы.
7. Есть ли у вас спецификация?
Написание спецификаций похоже на флоссинг: все согласны, что это здорово, но никто этого не делает.
Я не знаю наверняка, почему так происходит. Может быть, потому что разработчики ненавидят писать какую-либо документацию. В результате когда команда, состоящая исключительно из программистов, атакует проблему, ей проще выразить своё решение в коде, чем в документации. Такая команда лучше уйдёт с головой в написание кода, чем создаст спецификацию.
На стадии проектирования, когда вы обнаруживаете проблемы, вы можете легко их устранить, отредактировав несколько строк текста. Как только код написан, затраты на исправление ошибок значительно возрастают как в эмоциональном (люди ненавидят выбрасывать код), так и во временном аспекте, т.о. создаётся сопротивление исправлению ошибок. Программное обеспечение, созданное без спецификации, обычно оказывается плохо спроектированным и планы со сроками выходят из под контроля. Подобная ситуация образовалась в Netscape, где первые четыре версии превратились в такую неразбериху, что руководство глупо решило выбросить весь код и начать снова. В последствии они делали подобные ошибки с проектом Mozilla, создав монстра, который вышел из под контроля и только спустя несколько лет добрался до стадии альфа-версии.
Моя излюбленная теория легко решает подобную проблему. Просто научите разработчиков писать, отправив их наинтенсивные курсы, и они будут меньше сопротивляться. Другое решение - наймите хорошего менеджера по разработке и сопровождению программ, который будет писать спецификации. В любом случае вам следует обеспечить исполнение простого правила: "никакого кода без спецификации".
Узнайте всё про написание спецификаций, прочтя моюсерию из четырёх статей.
8. Предоставлены ли вашим программистам спокойные условия для работы?
В специальной литературе уже давно описано увеличение производительности работников умственного труда при предоставлении им рабочего пространства, тишины и уединённости. Классическая книга по управлению компаниями, производящими программное обеспечение,Peopleware, обстоятельно описывает пользу этих мер.
Все мы знаем, что люди умственного труда лучше всего работают, когда они полностью сконцентрированы на своей работе и полностью "отключены" от окружающей среды, как бы находясь "в потоке". Они теряют счёт времени и производят грандиозные вещи посредством абсолютной концентрации. Вот когда они продуктивно выполняют всю свою работу. Писатели, программисты, учёные и даже баскетболисты расскажут вам, что такое быть "в потоке".
Проблема в том, что попасть "в поток" не так-то просто. Если вы попытаетесь это дело измерить, то окажется, что требуется в среднем 15 минут, чтобы начать работать с максимальной производительностью. Иногда, когда вы устали или уже выполнили большую часть творческой работы за день, вы уже не сможете войти в неё и остаток дня уже проведете, валяя дурака, исследуя интернет и играя в Тетрис.
Другая проблема заключается в том, что очень легко выпасть из "потока". Шум, телефонные звонки, обеды и особенно реагирование на сослуживцев - всё это выбивает вас из колеи. К примеру, ваш коллега задал вам вопрос. Вы отвлеклись всего на минуту, но этого уже достаточно, чтобы выбить вас из режима работы, и вам уже потребуется по меньшей мере полчаса, чтобы вновь втянуться. Ваша общая производительность может от этого сильно пострадать. Если вы работаете в шумном "загоне", где ребята из отдела маркетинга висят на телефонах, и тут же рядом работают программисты, ваша производительность резко снижается, так как люди умственного труда то и дело отвлекаются и не могут сконцентрироваться.
С программистами дело обстоит весьма серьёзно. Производительность зависит от способности одновременно держать в кратковременной памяти огромное количество различных мелких деталей. Любое вмешательство может вмиг всё это разрушить. Когда вы подводите итоги работы, вы не можете удержать в памяти все детали (имена локальных переменных, которые вы использовали, или на каком месте вы остановились в кодировании поискового алгоритма). Поэтому вам приходится то и дело просматривать эти вещи, что в свою очередь, будет замедлять процесс работы до тех пор, пока вы не вернётесь в нормальный режим.
Вот вам простая арифметика. Факты свидетельствуют, что если мы отвлекаем программиста даже на 1 минуту, мы отнимаем у него 15 минут продуктивной работы. К примеру, у нас есть два программиста: Джеф и Мат, сидящие за соседними столами на обычной Дилбертской ферме по откорму телят. Мат забыл название Unicode версии функции strcpy. Он может найти его самостоятельно, для чего надо 30 секунд, иди спросить Джефа, на что уйдёт 15 секунд. Так как он сидит рядом с Джефом, почему бы не спросить Джефа. Джеф отрывается от работы и теряет 15 минут продуктивной работы (чтобы сэкономить 15 секунд Мата).
Давайте теперь переместим их в отдельные офисы со стенами и дверями. Теперь, когда Мат забыл название функции, он может найти его самостоятельно, что по-прежнему займёт 30 секунд, или спросить Джефа, на что уйдёт 45 секунд, и при этом ещё придётся вставать и куда-то идти (нелёгкая процедура для большинства программистов, если принять во внимание их физическую форму!) Таким образом, он разбирается сам. Мат тратит 30 секунд, но при этом сохраняет 15 минут продуктивной работы Джефа. Вот как!
9. Используете ли вы новейшее дорогое оборудование?
Компиляция - это одна из последних задач, которую всё ещё нельзя мгновенно выполнить на домашнем компьютере. Если процесс компиляции занимает у вас больше нескольких секунд, купите себе самый последний продвинутый компьютер. Это сэкономит ваше время. Если на компиляцию уходит 15 секунд, программисты умрут со скуки или переключатся на чтение журнала The Onion, на что уйдут часы рабочего времени.
Отладка GUI кода при помощи одного монитора - вещь мучительная, если не сказать невозможная. Если вы пишите GUI код, два монитора справятся с задачей куда быстрее и легче.
Большинству разработчиков приходится использовать растровые изображения для иконок и панелей инструментов. При этом некоторые даже не имеют хорошего растрового редактора. Пользоваться Microsoft Paint просто смешно, но это то, что многим программистам приходится делать.
На моём предыдущем месте работы системный администратор постоянно присылал мне спам, жалуясь, что на жёстком диске сервера на меня приходится - представьте себе - больше 220 мегабайт дискового пространства. Я обратил его внимание на то, что с учётом сегодняшних цен на жёсткие диски цена того дискового пространства, которое я занимал, была значительно ниже цены туалетной бумаги, которой я пользовался. 10 минут, потраченные на освобождение моей директории, были бы замечательным способом транжирить моё время.
Выдающиеся команды не мучают своих разработчиков. Даже небольшой сбой, вызванный маломощноым оборудованием, нервирует и раздражает программистов. А раздражительный программист - это непродуктивный программист.
Обобщая вышесказанное, программиста легко подкупить, предоставив ему самое новейшее и продвинутое оборудование. Этот способ мотивации обойдётся вам гораздо дешевле, чем выплата конкурентноспособной зарплаты.
10. У вас есть тестеры?
Если в вашей команде нет тестеров, по крайней мере одного на 2-3х программистов, вы либо выпускаете продукты, кишащие ошибками, либо теряете деньги. Работа, выполненная программистом, обойдётся вам в 100 $/час, а та же самая работа, выполненная тестером - 30 $/час. Экономия на тестерах - это оскорбительно ложная экономия. Я просто возмущён, почему большинство людей не замечает этого!
Почитайте статью Пять (ложных) причин не иметь тестеров, в которой я подробнее обсуждаю эту тему.
11. Пишут ли кандидаты на работу код во время собеседования?
Вы бы приняли на работу фокусника, не попросив его предварительно продемонстрировать свои фокусы? Конечно, нет.
Вы бы обратились в фирму, обслуживающую свадьбы, не попробовав их еды? Сомневаюсь.
Тем не менее, каждый день программисты принимаются на работу под впечатлением от их резюме или потому, что интервьюеру понравилось с ними болтать. Либо им задавались примитивные вопросы типа "в чём разница между CreateDialog() и DialogBox()?", ответ на которые легко найти в документации. Вам не важно, запомнили ли они тысячи разных мелочей о программировании или нет, вам нужно понять, способны ли они программировать. Или даже ещё хуже, им задают вопросы типа "Ага!": тип вопросов, которые кажутся лёгкими, когда знаешь ответ, а когда не знаешь - они просто бесполезны.
Пожалуйста, перестаньте так делать. Делайте что угодно во время собеседования, но заставьте кандидатанаписать какой-нибудь код. (Более подробно смотрите в моей статье "Искусство проведения интервью.")
12. Проводите ли вы коридорное тестирование удобства использования программ?
Коридорное тестирование - это процедура, при которой вы выбегаете в коридор, хватаете первого попавшегося человека и заставляете его попользоваться программой, которую вы только что написали. Если вы проделаете эту процедуру на пяти разных людях, вы получите 95% иноформации о проблемах с удобством использования в вашей программе.
Хороший дизайн пользовательского интерфейса - это не так сложно, как вы думаете, и очень важно, если вы хотите, чтобы пользователи покупали ваш продукт и были им довольны. Подробнее читайте в онлайн версии моей книги по дизайну пользовательского интерфейса для программистов.
Самый важный момент, касающийся пользовательского интерфейса, - это то, что вы, показывая свою программу горстке людей (фактически 5-6 человек уже достаточно), очень быстро узнаете, какие проблемы у них возникали. Прочитайте статью Джекоба Нильсена (Jakob Nielsen), в которой он объясняет, почему так происходит. Даже если у вас не хватает опыта в создании пользовательского интерфейса, но при этом вы проводите коридорное тестирование, которое ничего не стоит, то с каждым разом интерфейс будет становится всё лучше и лучше.
Четыре способа использования теста Джоэла
- Подсчитайте баллы, набранные вашей компанией, и скажите мне, чтобы я мог распускать слухи.
- Если вы менеджер, используйте эту статью как памятку, чтобы убедиться, что ваша компания работает настолько хорошо, насколько это возможно. Если вы набираете 12 баллов, то можете оставить своих программистов в покое и полностью сконцентрироваться на том, чтобы оградить их от назойливого начальства.
- Если вы хотите устроиться программистом в компанию, спросите у вашего предполагаемого работадателя, сколько баллов набирает его компания. Если балл слишком низок, убедитесь, будут ли у вас достаточные полномочия, чтобы всё наладить и изменить ситуацию. Иначе вы мало чего добьётесь и вряд ли будете довольны.
- Если вы инвестор и хотите объективно оценить уровень команды программистов, или ваша компания готовится к слиянию с другой компанией, то данный тест даст вам первое приближение.
В английском оригинале статья называется The Joel Test: 12 Steps to Better Code
