Ідеальний програміст. Частина 2



Це друга частина статті по книзі Роберта Мартіна «Ідеальний програміст». першої частини статті ми почали вивчати, ніж ідеальний програміст відрізняється від ідеального. Розглянули відповідальність, навчилися говорити «ні» нереальним завданням і казати «так» так, щоб замовник був упевнений, що все буде готове вчасно. Ми визначилися, як писати код, приймати допомогу і допомагати іншим. Продовжимо.



7. Розробка через тестування
Про TDD говорять багато всякого різного, наприклад, стаття на хабре. Роберт Мартін, однак, говорить, що ця методика дуже хороша.

Короткий робочий цикл. Чим коротше інтервал від написання коду до його запуску, тим продуктивніше виходить ваша робота. Ви можете запускати код щогодини (довго), а можете кожні пару хвилин (відмінно!). Автотесты сприяють збільшенню швидкості. Написав → запустив тести.

Три закону TDD:
  1. Робочий код пишеться тільки після того, як буде написаний модульний тест, який не проходить.
  2. Ви пишете рівно такий обсяг коду модульного тесту, який необхідний для того, щоб цей тест не проходив (не компілюється = не проходить).
  3. Ви пишете рівно такий обсяг робочого коду, який необхідний для проходження модульного тесту, який в даний момент не проходить.


Переваги
  1. Ви впевнені в написаному коді
  2. Багів стає менше
  3. Ви сміливіше вносите зміни. Коли весь код покритий тестами, рефакторинг робиться безболісно.
  4. Тести — відмінна документація. Ваші тести — прекрасні приклади використання коду.
  5. Гарна архітектура. Тільки добре ізольований і слабо пов'язаний код піддається тестуванню. З TDD ви вже не напишете метод, який викликає інший метод, який викликає інший метод, який викликає інший метод.


8. Тренування
Якщо ми не розвиваємося, значить, ми деградуємо. Музиканти грають гами, Ф. Р. Кутів у своїй книзі «Серце хірурга» (http://fb2bookdownload.ru/modern-prose/213-serdce-hirurga.html) розповідає, як він все своє життя (а він прожив 104 роки) тренувався в накладенні швів. Адвокати тренують мова, військові беруть участь у навчаннях. А як бути програмістів? Їм теж потрібно тренуватися?

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

Ката. Ви тренуєтеся реалізовувати певний алгоритм (наприклад, швидке сортування). Ви не вирішуєте задачу, а тренуєтеся у виконанні дій, необхідних для вирішення. Це допомагає запам'ятати гарячі клавіші, закріпити у підсвідомості пари «завдання-рішення».

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

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

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

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

Проблему вирішить приймальне тестування зі строгими алгоритмами. Це TDD, тільки на більш високому рівні. Пишете тест на будь-якій мові (можна російською) і погоджуєте з замовником. Завдання повинна бути покрита приймальними тестами на 100%. Автор книги пише, що ці тести повинні бути зрозумілими замовнику і автоматизованими. Особисто я не знаю, як це зробити на ранній стадії: можна писати модульні тести, але вони незрозумілі замовнику. А можна писати тести в Селениуме, але це вже більш пізня стадія. Якщо хтось поділиться рецептами .NET, буду вдячний.

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

Інтерфейс буде змінюватися. Щоб зміна інтерфейсу не ламала селениумовские тести, думайте про це під час розробки. Використовуйте id елементів для тестування (ok_button, select_tour) або БЕМ-позначення.

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

9. Стратегії тестування
Тестувальники не повинні протистояти розробникам. Хоча і здається, що їх ролі антагоністичні, таке протистояння контрпродуктивно. Добре, коли тестувальник всіма силами допомагає розробнику: шукає баги і описує їх так, щоб розробник максимально швидко зрозумів, у чому справа, як відтворити і як полагодити.
Автор описує піраміду автоматизації тестування



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

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

Системні тести — граничний випадок інтеграційних тестів. Зазвичай, це тести продуктивності і пропускної здатності. Вони перевіряють не поведінку системи, а її конструкцію.

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

10. Планування
Роберт Мартін пише про свій розпорядок. Він каже, що встає о 5 ранку, їде на велосипеді в офіс, пише розклад робочого дня на дошці. Розклад ділить на 15-хвилинні інтервали, залишаючи щогодини по 15 хвилин на відволікання. Після 15:00 хаос досягає апогею і подальше планування безглуздо: йде розгрібання накопичених справ.
Виходить, автор використовує буфер, який описаний у статті «Зробити завтра». Така схема може давати збої, але в цілому, дозволяє навести порядок на робочому часу.

Зустрічі — зло і тільки іноді добро.
Коли я працював у найбільшої транспортної компанії країни, я зрозумів, що значить багато зустрічей. Наради там проводяться з будь-якого приводу і без приводу. Узгодження макета сторінки промо-сайту — це зустріч п'яти осіб, кожен з яких після наради збере своє міні-нараду. Для того, щоб передати якісь дані з зовнішньої частини сайту в облікову систему, потрібно не одну нараду, а п'ять. Це страшенно вимотує і служить підставою для звільнення.
Автор пише, що в США нарада коштує 200 доларів на годину на кожного учасника (зарплати, премії, приміщення). А порахував і вийшло, що в Росії сильно дешевше: ≈13 доларів на годину на кожного. Але все одно дорого.

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

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

П'ятихвилинка — ласкаво
Це частина гнучкої методології і без неї нікуди. Кожен учасник по черзі говорить:
1. Що я зробив вчора?
2. Що я буду робити сьогодні?
3. Які складності мені належить вирішити?
Це швидко і не займає багато часу. Однак, є компанії, в яких п'ятихвилинка перетворюється в сорокоминутку. Так робити не потрібно.

11. Концентрація


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

Кофеїн. Автор пише, що можна поглинати помірні дози кофеїну, але закликає бути обережним. Я з ним не згоден і відношу кава і чай до інтоксикацій, які краще не вживати. З цього приводу є книжка «Корисна шкідлива звичка». Сам не читав, але ось анотація.

Фізичні вправи. Тіло потребує вправах. Поганяйте кров і лімфу, проїхавши на велосипеді або присівши 20 разів прямо в кабінеті. Я отмеряю час помідорками і в паузах присідаю, віджимаюся, роблю «Сурью Намаскар».

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

12. Ухилення від роботи
Інверсія пріоритетів
Кілька разів я помічав за собою таку штуку: є завдання з першим пріоритетом, однак, вона мені не подобається, і я шукаю будь-який привід, щоб зайнятися чимось ще. Коли я був маленький, мені дали завдання щодо актуалізації тестових сценаріїв вже майже сдохшей системи. Ця задача була для мене настільки цікавою, що я знаходив будь-який привід, щоб відволіктися. Така поведінка називається інверсією пріоритетів: менш важливим завданням ми присвоюємо вищий пріоритет.Для професіоналів така поведінка не годиться. Ми повинні вирішувати задачі в порядку пріоритетів, а не за особистим уподобанням.

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

Бруд в коді знижує продуктивність до нуля. Всі ми хочемо писати чистий досконалий код. Однак, приходить час і до нас приходить замовник із зміненими вимогами. Тут у вас є два варіанти: повернутися назад і змінити архітектуру або прикрутити милицю. Милиці в коді мають звичку плодитися дуже швидко. Як тільки ви прикрутили перший, — чекайте другий, третій, двадцятий. Так народжується система, яку неможливо підтримувати і, після того, як ви підете, ті, хто прийдуть на ваше місце скажуть: «Це повне лайно. Тут потрібно все переписати». Так ваш проект неминуче йде до провалу.

13. Оцінка
Бізнес вважає оцінку зобов'язанням, а розробник — припущенням. В цьому є принципова відмінність. Я сподіваюся, всім зрозуміло, що зобов'язання відрізняється від припущення. Менеджер завжди буде домагатися від розробника зобов'язання:
—Ти зробиш перехід на ESB за два тижні?
—Можемо, але, думаю, мені потрібно три тижні. Я ніколи не працював з шинами.
—Тоді пишемо три тижні?
—Ні, може піти і 10-11 тижнів, якщо наші партнери не зможуть швидко перебудуватися на ESB.
Автор книги пише, що для оцінки можна використати методику PERT і давати три оцінки оптимістичну, номінальну і песимістичну.

Оптимістична оцінка дається максимально оптимістично. Це той випадок, коли все йде ідеально і немає ніяких проблем. Імовірність низька, але її треба врахувати. Номінальна оцінка — це стандартна ситуація, коли все йде більш-менш добре. Є невеликі очікувані труднощі. Песимістична оцінка — це коли все йде погано: партнери не розуміють, що ми від них хочемо, техпідтримка довго відповідає, шина втрачає пакети, а документації на вашому рідному арабській мові немає.
Часто, щоб оцінити вашу завдання недостатньо тільки вашої думки. Добре, коли завдання оцінить ще хто-небудь. Автор пропонує зібрати групу експертів і обговорювати завдання, поки не буде досягнуто згоди в її оцінці. Методик голосування безліч: від усного волевиявлення до розподілу завдань за строками на дошці.
Прочитайте оригінал книги: там даються формули і математика, якої немає в статті.

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

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

Ще керівник може сказати: «Нам потрібно терміново-терміново, тому зараз писати тести не потрібно. Потім допишемо». Не ведіться і відстоюйте свою точку зору. Навіть в кризових ситуаціях треба застосовувати TDD або TLD, але ні в якому разі не відмовлятися від тестування. Це обернеться великими проблемами в майбутньому.

15. Програмісти
Частину книги я переповім короткими тезами без детальних розшифровок.
  • Програмісти не люблять працювати з людьми. Саме тому вони і програмісти: вони воліють працювати з передбачуваними машинами, ніж з непередбачуваними людьми.
  • Програміст приймає правила роботодавця. Якщо програміст не приймає правил, він звільняється або його звільняють.
  • Програміст пише код, який належить команді. Будь-який інший член команди може внести зміни у ваш код і ви можете внести зміни в чужий шматок коду. Це накладає відповідальність за те, як ви пишете.
  • Програмісти працюють парами. Якщо не завжди, то хоча б іноді. Іноді дуже корисно підглянути за тим, як хтось працює. Програмісти-одинаки замість парного програмування дивляться скринкасты.
  • Програмісти працюють у групах. А гарні групи формуються не відразу. Процес притирання може зайняти півроку або навіть рік. Краще віддавати проект групі, ніж тимчасово формувати групу для проекту, а потім розформовувати і перерозподіляти.
  • У програміста є наставники. Краще всього, якщо це живі люди. Але, можливо, це автори книг, статей, блогів і відеоуроків. Майже всі наші знання ми отримуємо парампаре і тільки іноді придумуємо щось самі і при цьому частенько винаходимо велосипед.
  • Програмісти користуються сучасними інструментами. Використовують систему управління вихідним кодом, постановкою завдань, безперервну збірку, інструменти тестування.


Висновок
Книга перевернула моє уявлення про професіоналізм і дала розуміння, куди можна прагнути. Хтось в коментах до першої частини пише, що все це написано про сферичного програміста у вакуумі. Але погляньте на заголовок статті. Там написано «ідеальний», так що тут описано те, до чого потрібно йти. Почніть з двох-трьох пунктів і постійно повертайтеся до книги, згадуючи, що ще ви можете поліпшити.
Щастя вам!

Ілюстрації Олександра Корнілова

← Перша частина статті
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.