У видавництві «Фабула» вийшла друком книга «Чистий кодер» Роберта Мартіна в українському перекладі. Роберт,також відомий як Дядечко Боб й один із творців всесвітньовідомого Agile-маніфесту, написав книжку для всіх, хто займається програмуванням і прагне бути справжнім професіоналом, незалежно від досвіду.  У ній Роберт викладає свої очікування від професійного розробника у всіх можливих аспектах: із погляду управлінських взаємодій, тайм-менеджменту, зовнішнього тиску, співпраці в команді та вибору відповідних інструментів. 

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

У 1978 році я був провідним розробником 32-кілобайтної вбудованої програми для Z-80, написаної мовою асемблера. Програма «прошивалась» на 32 перепрограмованих мікросхемах. Ці мікросхеми вставлялися у три плати, по 12 мікросхем на кожну.

У нас були сотні пристроїв, установлених на центральних телефонних станціях по всіх Сполучених Штатах. І щоразу, як ми виправляли помилку або додавали нову функцію, нам доводилося відряджати техніків до кожного пристрою для заміни всіх 32 мікросхем!

Це був справжній жах. Мікросхеми і плати були крихкими, контакти мікросхем гнулися та ламалися. Ненавмисні деформації плат могли пошкодити місця пайки. Ризик помилок і поломок був величезний, а витрати компанії зависокі.

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

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

Рішення виглядало досить простим. Мікросхеми потрібно було ізолювати одну від одної. Вміст кожної мікросхеми при цьому перетворювався на незалежну одиницю компіляції, яку можна було записувати незалежно від інших.

Я визначив розміри всіх функцій у застосунку й написав просту програму, що «укладала» їх, немов фрагменти пазла, на мікросхемах, залишаючи по 100 байт вільного простору для розширення. На початку кожної мікросхеми розміщувалася таблиця вказівників на всі функції даної мікросхеми. Під час завантаження, ці вказівники переміщувалися в оперативну пам’ять. Весь код системи було змінено таким чином, аби функції ніколи не викликалися безпосередньо — лише через вектори, що зберігалися в пам’яті.

Так, ви правильно зрозуміли: ці чіпи перетворилися на аналоги об’єктів з v-таблицями, а функції викликалися поліморфно. Саме так я дізнався про деякі принципи об’єктно-орієнтованого програмування задовго до того, як познайомився з поняттям «об’єкт».

Вигода від такого рішення виявилася величезною. Ми отримали можливість обмежитися заміною окремих чіпів, а окрім цього спосіб вносити виправлення «у польових умовах», переописуючи вектори оперативної пам’яті. Це значно спростило відлагодження та оперативні виправлення.

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

Мені знадобилося три місяці.

Я напивався тільки двічі у житті і лише раз напився ґрунтовно. Це сталося на святкуванні Різдва в Teradyne у 1978 році. Мені на той час було 26 років.

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

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

Я сидів по-турецьки на підлозі з Кеном (моєму босу тоді було 29 років, і він був тверезий), нарікаючи на те, скільки мого часу поглинула векторизація. Алкоголь вивільнив мої приховані страхи і відсутність упевненість щодо вихідного оцінювання. Сподіваюся, я не клав голову йому на плече — але ці подробиці не дуже чітко зафіксувалися в моїй свідомості.

Пригадую, як спитав, чи не сердиться він на мене і чи не вважає, що робота зайняла забагато часу. І як би смутно я не пам’ятав той вечір, його відповідь чітко відклалася у мене в пам’яті, закарбувавшись на всі наступні десятиліття. Він сказав: «Так, я думаю, що витрачено багато часу, але бачу, що ти старанно працюєш, і робота не стоїть на місці. І нам це дійсно потрібно. Тому, ні, я не гніваюся».

Що таке оцінка?

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

Зобов’язання

Зобов’язання — це щось таке, що ви повинні зробити. Якщо ви зобов’язуєтесь зробити щось до певної дати, то до цієї дати «щось» має бути готове. Якщо для цього вам доведеться працювати по 12 годин на добу й у вихідні, нехтуючи сімейними святами, — то так тому і бути. Ви взяли зобов’язання, і його треба дотримуватися.

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

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

Оцінка

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

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

Оцінка — це не число, а розподіл.

Ось приклад:

Майк: Скільки, за твоєю оцінкою, знадобиться для завершення роботи над Frazzle?

Пітер: Три дні.

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

А якби Майк поцікавився в Пітера, наскільки високою є ймовірність його оцінки?

Майк: Яка ймовірність того, що ти впораєшся за три дні?

Пітер: Мабуть, впораюся.

Майк: Можеш назвати цифру?

Пітер: П’ятдесят чи навіть шістдесят відсотків.

Майк: Отже, є доволі висока ймовірність, що тобі знадобиться чотири дні?

Пітер: Так. Може знадобитися навіть п’ять або шість, хоча я сумніваюся у цьому.

Майк: Наскільки сумніваєшся?

Пітер: Ну, я не знаю… Я на дев’яносто п’ять відсотків упевнений, що робота буде зроблена менше ніж за шість днів.

Майк: Тобто може бути і сім?

Пітер: Ну, якщо все піде шкереберть... Чорт, якщо все піде шкереберть, може бути і десять, і навіть одинадцять днів. Але ж імовірність такого збігу подій дуже мала, так?

Ми поступово починаємо наближатися до істини. Оцінка Пітера є ймовірнісним розподілом. У власній уяві він бачить можливість завершення завдання наступним чином (див. рис. 10.1).

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

Рис. 10.1. Імовірнісний розподіл

Чи має Майк перейматися цим? Звісно! Закон Мерфі[1] ще ніхто не скасовував, тому завжди можуть виникнути непередбачені ускладнення.

Передбачувані зобов’язання

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

Майк: Пітере, можеш назвати остаточну дату, коли задача буде виконана?

Пітер: Ні, Майку. Як я вже казав, роботу буде виконано за три, а може, за чотири дні.

Майк: Тоді пишемо чотири?

Пітер: Ні, теоретично може бути і п’ять, і шість.

Поки що все відбувається чесно. Майк попросив розробника взяти на себе зобов’язання, а Пітер ввічливо відмовився його давати. Тоді Майк пробує застосувати іншу тактику:

Майк: Добре, Пітере, але ти можеш хоча би спробувати вкластися у шість днів?

Прохання Майка звучить доволі безневинно, до того ж він керується найкращими намірами. Але чого саме Майк вимагає від Пітера? Що означає «спробувати»?

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

Які ще інтерпретації тут можливі? Що саме Пітер збирається зробити, щоби спробувати? Він збирається працювати понад 8 годин? Очевидно, це мається на увазі, якщо він дасть згоду. Він збирається працювати у вихідні? Так, це також мається на увазі. Втратити години спілкування із сім’єю? І це також. Усе перелічене міститься у слові «спробувати». І якщо Пітер чогось не зробить, Майк зможе звинуватити його в тому, що він доклав недостатньо зусиль.

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

[1] Закон Мерфі проголошує: якщо щось може піти шкереберть, то воно обов’язково піде шкереберть.