Joel on Software

Joel on Software   Програм Джоеля

 

Інші статті "Joel on Software" українською

Інші статті "Joel on Software" англійською

Напишіть e-mail авторові (тільки англійською)

 

Тест Джоеля: 12 Кроків до Кращого Коду


Джоеля Сполскі
Перекладено Роман Дощак
Відредаговано Сергій Кліменчук
9 Серпня 2000

Чи ви коли-небудь чули про SEMA? Це досить езотерична система для визначення якості роботи команди програмістів. Але ні, чекайте! Не ходіть туди! Ви витратите десь років шість тільки на те, щоб зрозуміти її. Так що я придумав свій, безвідповідальний, сирий тест для визначення якості команди програмістів. Найкраще в ньому те, що він займе всього 3 хвилини. Зекономленого часу вистачить на навчання в медінституті.

Тест Джоеля

  1. Чи ви використовуєте систему контролю за версіями коду?
  2. Чи можете відкомпілювати весь проект за раз?
  3. Чи ви робите щоденні білди?
  4. Чи маєте базу даних помилок?
  5. Чи виправляєте помилки перед написанням нового коду?
  6. Чи маєте завжди оновлений графік роботи?
  7. Чи маєте специфікації?
  8. Чи програмісти працюють в спокійних умовах?
  9. Чи використовуєте найкращі засоби, які можна купити за гроші?
  10. Чи у вас є люди, що тестують?
  11. Чи кандидати, які до вас наймаються на роботу, пишуть пробний код на співбесіді?
  12. Чи ви робите "коридорні" тести зручності продукту?

 

Чудовим в Тесті Джоеля є те, що ви можете швидко відповісти так чи ні на кожне запитання. Вам не потрібно вказувати кількість ряків-коду-за-день або середню-кількість-помилок-на-кожен-проміжний етап. Поставте вашій команді 1 бал за кожну відповідь "так"! Недоліком Тесту Джоеля є те, що ви не повинні використовувати його для визначення безпечності вашого програмного забезпечення для атомної станції.

Загальний бал у 12 є просто чудовим, 11 є допустимим, але 10 або менше говорить про те, що ви маєте серйозні проблеми. Правдою є те, що дуже багато програмістських контор працюють з балом в 2 або 3, і вони потребують серйозної допомоги, бо контори типу Майкрософт працюють з балом 12 завжди.

Звичайно, не тільки ці фактори визначають успіх чи провал: наприклад, якщо у вас чудова команда, що працює над нікому непотрібним продуктом, відповідно, люди не будуть купувати його. Також можна уявити команду "демонів", які не роблять нічого з вищезгаданого, але примудряються писати програми, що змінюють світ. Але в цілому, якщо у вас все в нормі з цими 12 речами, ви маєте дисципліновану команду, що працюватиме рівно.

1. Чи використовуєте ви систему контролю за версіями коду?
Я використовував комерційні системи контролю за версіями коду, також використовував CVS, який є безкоштовним, і скажу я вам, CVS просто чудовий. Але якщо у вас немає такої системи, матимете проблеми, організовуючи колективну роботу програмістів. Програмісти не мають можливості знати, що зробили інші. Помилки не вдасться легко виправити, повернувшись до попереднього стану. Ще однією приємною рисою таких систем є те, що робоча копія коду знаходиться на комп'ютері кожного програміста - Я ніколи не чув, щоб проекти, які використовують контроль за кодом, коли-небудь втратили багато коду.

2. Чи ви можете відкомпілювати весь проект за раз?
Під цим я маю на увазі: скільки кроків вам потрібно, щоб відкомпілювати проект до готового на продаж стану? Хороші команди мають один скрипт, який перевіряє весь код, компілює кожен рядок коду, робить EXEшники, у всіх їх версіях, мовах, комбінаціях #ifdef, створює інсталяційний пакет, і створює остаточний носій - образ CDROM, вебсайт для закачки, інше.

Якщо цей процес займає більше ніж один крок, він схильний до помилок. І коли ваша система майже готова до виходу у світ, ви хочете мати дуже швидкий цикл виправлення "останнього" багу, формування остаточних EXEшників, та ін. Якщо це займає 20 кроків, щоб відкомпілювати код, запустити програму створення інсталяційного пакету, та ін., ви зійдете з розуму і почнете робити дурні помилки.

Саме з цієї причини остання фірма, де я працював, перейшла з WISE на InstallShield: нам було потрібно, щоб процес інсталяції можна було запустити автоматично зі скрипта, вночі, використовуючи NT scheduler, а WISE не міг запуститись із шедулера вночі, тому ми його і викинули. (Добрі люди з WISE переконують мене в тому, що їх остання версія підтримує нічні білди.)

3. Чи ви робите щоденні білди?
Коли ви використовуєте контроль за версіями, інколи один програміст робить зміни, які роблять неможливим процес компіляції. Наприклад, він додає новий файл до коду, і все компілюється нормально на його машині, але він забуває додати цей файл до репозитарія. Далі він виключає свій комп'ютер і йде додому, розсіяний і задоволений. Але ніхто далі не може працювати, тоді вони також йдуть додому, але незадоволені.

Зіпсувати білд так погано (і так просто) що краще робити щоденні білди, аби переконатись, що ніякі проблеми не проскочили непоміченими. У великих командах способом переконатись, що все в нормі, є виготовлення щоденного білду, наприклад, під час обіду. Кожен робить якомога більше змін і додавань перед обідом. Коли вони повертаються з обіду - білд готовий. Якщо працює - чудово! Кожен отримує останню версію коду і йде працювати далі. Якщо ж відкомпілювати не вдається, ви виправляєте помилки, але кожен при цьому може продовжувати працювати з попередньою, робочою версією коду.

В команді, яка займалася Excel, ми мали правило, що коли хто-небудь псує білд, в якості "покарання" відповідає за догляд за білдами до тих пір, доки хто-небудь інший не зробить цю помилку. Це було хорошим стимулом не псувати білд, і гарним спосібом дати кожному можливість зрозуміти, як це все працює.

Ви можете докладніше прочитати про щоденні білди тут: Щоденні білди-Ваші друзі

4. Чи у вас є база даних помилок?
Мене не цікавить, що ви говорите. Якщо ви розробляєте програму, навіть наодинці, без організованої бази по всім відомим помилкам в коді ви випустите низькоякісний продукт. Багато програмістів вважають, що можуть втримати все в своїй голові. Нісенітниця. Я не можу запам'ятати про більше ніж 2-3 помилки за раз, і на наступний ранок або в гарячці перед випуском, вони забуваються. Ви просто мусите мати формальний список помилок.

Бази по багам можуть бути складними і простими. Щонайменше така база має мати таку інформацію щодо кожного багу:

  • докладний опис кроків, необхідних для відтворення багу

  • очікувана поведінка

  • дійсна (неправильна) поведінка

  • хто відповідальний за виправлення

  • чи виправлено, чи ні

Якщо єдина причина, з якої ви не відстежуєте помилки, є складність призначених для цієї справи програм, просто створіть таблицю з цими п'ятьма полями і починайте її використовувати.

Додатково можете почитати про це тут: Безболісне відстежування помилок.

5. Чи виправляєте помилки перед написанням нового коду?
Найперша версія Microsoft Word for Windows вважалася "смертельним" проектом. Робота тягнулась вічність. І ставало дедалі гірше. Вся команда працювала і після роботи, в стані неймовірного стресу, але проект затримувався знову, і знову, і знову. Коли ж нарешті програму випустили, з затримкою у кілька років, Microsoft відправила всю команду в Канкун у відпустку і провела серйозний аналіз ситуації.

Вони зрозуміли пізніше, що менеджери проекту були настільки наполегливі в дотриманні "розкладу", що програмісти просто мчали по процесу кодування, пишучи надзвичайно поганий код, бо фази виправлення помилок просто не було в розкладі. Не не було навіть спроби тримати під контролем кількість помилок. Якраз навпаки. Історія розповідає, що один програміст, який мав написати код для обчислення висоти рядку тексту, просто написав "return 12;" і чекав на звіт по баrам, що його функція не завжди працює вірно. Розклад був просто переліком фіч, що чекали на те, щоб стати багами. В некролозі це називалось "методологією нескінченої кількості дефектів".

Щоби виправити проблему, Microsoft прийняла те, що називається "методологією відсутності дефектів". Багато з програмістів з цього сміялись, бо це виглядало так, ніби керівництво могло зменшити кількість помилок простим наказом. Насправді, "відсутність дефектів" означає, що в даний момент часу найвищим пріоритетом є виправлення помилок перед написанням нового коду. І ось чому.

Взагалі, чим довше ви відволікаєте виправлення помилок, тим дорожче (і час, і гроші) це вам коштує.

Наприклад, якщо ви робите описку або синтаксичну помилку, яку виловлює компілятор, виправити це тривіально.

Коли ви бачите баг в коді при першому запуску програми, можете виправити його взагалі без втрати часу, бо в вашій пам'яті все свіже.

Якщо ви бачите баг в коді, який ви написали декілька днів тому, ви трохи попрацюєте, щоб його знайти, але коли ви перечитаєте код, ви все пригадаєте і зможете виправити баг за прийнятний відрізок часу.

Але якщо шукаєте баг в коді, який ви написали декілька місяців тому, ви напевно забули більшість з коду і очевидно, це набагато важче виправляти. Крім того, ви можете виправляти код когось іншого, а він може бути у відпустці десь на Канарах, у такому випадку виправлення схоже на науку: ви маєте робити все повільно, методично, вникаючи в усі деталі, і ви не можете знати, скільки часу займе ця робота.

Але якщо ви знайдете баг в коді, який вже продано, вас чекають надзвичайно великі витрати на те, щоб його виправити.

Це одна причина виправляти помилки відразу: тому що це займе найменше часу. Є ще одна причина, яка стосується того факту, що набагато легше передбачити, скільки часу піде на написання нового коду, ніж на виправлення існуючого багу. Наприклад, якщо я запитаю, скільки часу піде на написання коду для сортування списку, ви скажете досить точний час. Але якщо запитати, скільки часу піде на виправлення багу у вашій частині коду, яка не працює, коли Internet Explorer 5.5 проінстальовано, ви навіть не зможете вгадати, бо ви не знаєте (за означенням) що ж є причиною багу. Може піти 3 дні, щоб виявити, а може, і 2 хвилини.

З цього висновок - якщо у вас є розклад робіт з великою кількістю невиправлених багів, ваш розклад є ненадійним. Але якщо ви виправили всі відомі баги, і все що залишилось-написати новий код, ваш розклад стає набагато більш точним.

Ще одним чудовим наслідком підтримування лічильника невиправлених багів на нулі є те, що ви можете набагато швидше реагувати на виклик конкурентів. Деякі програмісти думають про це як готовність постачати продукт весь час. Тоді, якщо ваш конкурент запропонує супернову можливість, яка переманює ваших клієнтів, ви зможете ввести цю можливість в ваш продукт і почати його постачати без потреби у виправленні великої кількості нагромаджених помилок.

6. Ви маєте завжди оновлений графік роботи?
Що ж прив'язує нас до графіків. Якщо ваш код є важливим для вашої фірми, тоді є багато причин, чому для вашої фірми так важливо знати, коли він буде готовий. Програмісти жахливо неохочі до складання графіків. "Воно буде готове коли воно буде готове!" кричать вони керівництву.

На жаль, так бути не може. Фірма має прийняти багато планових рішень перед постачанням готової програми: демо-версії, виставки, реклама, та ін. І єдиним способом це робити є мати графік, і постійно тримати його оновленим.

Іншою важливою причиною мати графік є те, що він змушує вас визначитись, які функції програми ви збираєтесь реалізувати, а потім вибрати найменш важливі з них і викинути геть, а не перетворювати на "фічурітіс" .

Мати графіки не має бути так складно. Почитайте мою статтю Безпроблемні Графіки для Програмістів, яка описує простих шлях мати чудові графіки.

7. Ви маєте специфікації?
Написання специфікацій подібне до флоссінгу зубів шовковою ниткою: всі погоджуються, що це добре, але ніхто цим не займається.

Я не впевнений, чому так виходить, можливо, тому, що більшість програмістів ненавидить писати документи. У підсумку, коли команда складається тільки з програмістів, що займаються вирішенням завдань, вони полюбляють висловлювати свої рішення у коді, а не в документах. Вони скоріше поринуть з головою в написання коду, аніж будуть спершу виробляти специфікації.

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

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

Ви можете навчитись писати специфікації з моєї серії з 4х частин.

8. Чи програмісти працюють в спокійних умовах?
Добре відомо, як підвищується продуктивність роботи працівників "розумових галузей", якщо їх робоче місце є просторим, тихим і без зайвих людей. Класична книжка з менеджменту програмного забезпечення Peopleware докладно висвітлює переваги такого підходу.

Тут є своя проблема. Ми всі знаємо, що розумові працівники краще за все працюють попадаючи в "потік", або "хвилю", коли вони повністю зосереджені на роботі і ніби висмикнуті з оточення. Вони втрачають лік часу і роблять чудові речі завдяки абсолютній концентрації на роботі. Це той час, коли робиться вся продуктивна робота. Письменники, програмісти, науковці, навіть баскетболісти скажуть вам, що таке бути в "потоці".

Але проблема в тому, що попасти в "потік" не так просто. Якщо спробувати це виміряти, десь 15 хвилин йде на те, щоб почати працювати з максимальною продуктивністю. Інколи, коли ви втомлені або вже багато чого креативного зробили за день, ви просто не можете попасти в "потік", і проводите залишок робочого часу вештаючись навколо, читаючи веб-сторінки та граючи в Тетріс.

Інша проблема полягає в тому, що вибитись з "потоку" дуже легко. Шум, телефонні дзвінки, похід на обід, похід за кавою, відволікання співробітниками - особливо відволікання співробітниками - все це викидає вас з "потоку". Якщо співробітник вас щось запитує, відволікаючи на 1 хвилину, але це викидає вас з "потоку" і вам потрібно ще півгодини, щоб знову стати продуктивним, тоді ваша загальна продуктивність під серйозною загрозою. Якщо ж ви працюєте в шумному кофеїнованому оточенні, яке полюбляють створювати доткоми, з хлопцями з відділу маркетингу, що верещать в телефон поряд з програмістами, продуктивність дуже сильно впаде, бо розумові працівники постійно перериваються і ніколи не попадають в "потік".

У випадку з програмістами все ще складніше. Продуктивність залежить від здатності втримати велику кількість дрібних деталей в короткотривалій пам'яті. Будь-яке переривання призведе до втрати цих деталей. Коли ви продовжуєте працювати, ви вже не можете пригадати всіх деталей (імен локальних змінних, чи до чого ви дійшли, пишучи алгоритм пошуку) і ви маєте згадувати все з самого початку, що уповільнює роботу, аж доки ви знову не вийдете на нормальний ритм.

Ось проста математика. Скажімо так (факти це доводять): якщо ми перериваємо программіста, навіть на хвилину, насправді ми втрачаємо 15 хвилин продуктивності. Наприклад, садимо двох програмістів, Джефа і Мутта, у відкриті відсіки (відгороджені тонкими стінками частини кімнати) на стандартну ферму Ділберта. Мутт не може пригадати назву Unicod-версії функції strcpy. Він може пошукати її, що займе 30 секунд, або запитати Джефа, що займе 15 секунд. Оскільки він сидить прямо біля Джефа, він запитує Джефа. Джеф відривається від роботи і втрачає 15 хвилин продуктивного часу (зекономивши 15 секунд Мутту).

Тепер садимо їх в окремі кімнати зі стінами і дверима. Тоді, коли Мутт не може пригадати ім'я функції, він може пошукати її, що займе ті самі 30 секунд, або ж запитати Джефа, що займе 45 секунд, і крім того ще є потреба встати з місця (не така вже і проста задача для середньої фізичної форми програміста!). Так що він дивиться в довідник. Тоді Мутт втрачає 30 секунд продуктивності, але рятує 15 хвилин Джефові. Отак!

9. Чи ви використовуєте найкращі засоби, які можна купити за гроші?
Написання коду є однією з тих останніх речей, які не можна миттєво зробити на посередньому домашньому комп'ютері. Якщо процес компіляції займає більше, ніж декілька секунд, найновіший і найкращий комп'ютер зекономить вам час. Якщо компіляція йде навіть 15 секунд, програмісти починають нудьгувати і переключаються на читання The Onion, який затягує їх і вбиває години роботи.

Відлагодження графічного коду на системі з одним монітором є справою важкою, якщо і не неможливою. Якщо ви пишете графічний код, два монітори суттєво полегшать роботу.

Більшість програмістів час від часу мають робити картинки для іконок або тулбарів, і більшість з них не має нормального графічного редактора під рукою. Використовувати Microsoft Paint для цієї справи є невдалим жартом, але це те, що більшість програмістів робить.

На моїй останній роботі системний адміністратор постійно висилав мені спам, скаржачись на те, що я використовую більше ніж, дивіться сюди, ... 220МБ дискового простору на сервері! Я ж вказав на те, що беручи до уваги ціни на жорсткі диски в теперішній час, вартість цього дискового простору є значно менше вартості туалетного паперу, що я використав. Втрата навіть 10 хвилин на очистку моєї директорії була би нечуваною втратою продуктивності .

Найкращі команди розробників не мучають своїх програмістів. Навіть дрібні незручності, спричинені недостатньо дієвими інструментами, роблять програмістів незадоволеними та роздратованими. А роздратований програміст – це непродуктивний програміст.

До всього цього... програмістів легко купити, даючи їм круті штучки. Це набагато дешевший шлях змусити їх працювати на вас, аніж піднімати зарплатню!

10. Чи у вас є люди, що тестують?
Якщо у вашій команді нема окремих тестерів, хоча би один на два-три програміста, ви або продаєте продукти, повні помилок, або викидаєте гроші, тому що 100-доларовий-за-годину програміст мусить робити роботу, яку міг би зробити 30-доларовий-за-годину тестер. Економія на тестерах є такою жахливою економією на сірниках, що мене просто вбиває, чому більшість людей цього не розуміє.

Прочитайте П'ять (Невірних) Причин Чому У Вас Нема Тестерів, статтю, що я написав на цю тему.

11. Чи кандидати, які до вас наймаються на роботу, пишуть пробний код на співбесіді?
Ви б найняли чарівника, не запропонувавши йому показати свої фокуси? Звісно ж, що ні.

Чи ви найняли б кухаря на весілля, не скуштувавши його страв? Маю сумніви. (Хіба що це тьотя Маня, але й вона вас зненавидить, якщо ви не замовите її "фірмовий" печінковий пиріг).

При цьому, кожен день програмісти приймаються на роботу під впливом від вражаючого резюме чи з тої причини, що тому, хто проводив співбесіду, сподобалось з ними спілкуватись. Або їм давали тривіальні питання ("яка різниця між CreateDialog() та DialogBox()?"), відповідь на які можна легко знайти в документації. Вас не обходить, чи вони запам'ятали тисячі таких дрібниць з програмування, для вас має значення , чи здатні вони писати код. Або, що ще гірше, їм задавали питання типу "АГА!": тобто тип питань, які виглядають простими, якщо знаєш на них відповідь, але коли не знаєш, дати відповідь просто неможливо.

Будь-ласка, не робіть так. Робіть що завгодно під час співбесіди, але нехай кандидат напише трохи коду. (Більш детально дивіться моє Партизанське Керівництво до Співбесід.)

12. Чи ви проводите "коридорні" перевірки зручності продукту?
"Коридорна" перевірка зручності - це коли ви хапаєте першу-ліпшу людину, що проходить коридором, і примушуєте її спробувати покористуватись кодом, який ви щойно написали. Якщо ви це зробите з п'ятьма людьми - ви будете знати 95% з того, що потрібно знати про проблеми зі зручності у вашому продукті.

Гарний дизайн інтерфейсу не є аж такою важкою справою, як ви думаєте, але він є дуже важливим, якщо ви хочете, щоб ваші користувачі любили та купували ваш продукт. Ви можете прочитати мою онлайнову книгу про дизайн інтерфейсу користувача, невеличкий буквар для програмістів.

Але найсуттєвішою річчю про інтерфейси є те, що якщо ви покажете вашу програму декільком людям, (5 або 6 досить), ви швидко дізнаєтесь про найбільші проблеми, з якими вони стикаються. Прочитайте статтю Джейкоба Нілсена, яка вам це пояснить. Навіть якщо вам бракує навичок у розробці інтерфейсу користувача, але при цьому ви примушуєте себе робити коридорні перевірки зручності, які нічого не коштують, ваш інтерфейс буде значно, значно кращий.

Чотири шляхи використати Тест Джоеля

  1. Визначте за ним рівень вашої контори і скажіть це мені, щоб я міг попліткувати.
  2. Якщо ви є менеджером команди програмістів, використайте його, щоби переконатись, що ваша команда працює якнайкраще. Якщо ви зможете поставити оцінку 12, залиште програмістів у спокою і займіть весь ваш робочий час захистом вашої команди від контактів з надокучливим керівництвом.
  3. Коли ви вирішуєте, чи вартує прийняти пропозицію працювати програмістом, попросіть потенційного працедавця оцінити його фірму по цьому тесту. Якщо оцінка занадто низька, переконайтесь, що ви матимете змогу це виправити. Інакше ви будете розчаровані та непродуктивні.
  4. Якщо ви інвестор, і намагаєтесь визначити цінність команди програмістів, або якщо ваша фірма вирішує питання об'єднання з іншою, цей тест може дати перше наближення.


Ця стаття є перекладом з англійської статті The Joel Test: 12 Steps to Better Code  

Джоель Сполскі є засновником Fog Creek Software, невеликої компанії у місті Нью-Йорку. Він закінчив Йєльський університет і працював програмістом та менеджером у Майкрософт(Microsoft), Віаком(Viacom) та Джуно(Juno).


Вміст цих сторінок відображає думки окремої людини.
Всі права захищені Copyright ©1999-2005 Joel Spolsky.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky