Життєві поради від Дядечка Боба з його книги “The Clean Coder: A Code of Conduct for Professional Programmers”

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Всім привіт, з вами Артур Шевченко, Head of Quality Department в компанії Yalantis, викладач курсу по Java, мануальному та автоматизованому тестуванню в університеті а також автор телеграм-блогу про тестування, трішки про розробку та менеджмент t.me/from_a_to_qa і ютуб-каналу youtube.com/@from_a_to_qa де є декілька курсів та записів виступів.

І в цій статті я хотів би зробити огляд книжки, яку я би рекомендував кожному хто працює в айтішці незалежно від ролі, рівня чи стеку — The Clean Coder: A Code of Conduct for Professional Programmers by Robert Martin. А кому ліньки читати багацько букв — може переглянути на ютубчику мое бурмотіння тут youtu.be/zwSH3VqEXwI

Ця книга не з числа технічної літератури, але вона про технічний світ.

Вона не привʼязана до будь-якої мови, але привʼязана до життя людей.

Актуальна як для джуніорів, так і для довсідчених людей.

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

То ж, огляд книжечки, подекуди з моїми власними думками, спостереженнями та прикладами.

Все розвивається доволі динамічно — в першому розділу автор лусне вам книгою по голові та скаже: ТЕСТУЙ СВІЙ КОД, ДРУЖЕ! Адже, хто, як не ти, повинен знати, що там відбувається та як він працює. І це насправді дуже важливий пункт, адже багато програмістів наразі не запускають свій код після того, як задеплоять його кудись, умовно кажучи «там тестери є — протестують».

Тільки встигли оговтатися від першого — одразу другий удар: ДРУЖЕ, ТОБІ ТВІЙ РОБОТОДАВЕЦЬ НІЧОГО НЕ ВИНЕН. Всі конференції, всі книжки, всі курси і т.і. лежать тільки на тобі. Ти — єдина людина, котра повинна про це піклуватись. Дбати самостійно про своє технічне зростання та розвиток. 40 годин на тиждень ти маєш вирішувати проблеми бізнесу, а весь інший час — займатися сімʼєю та саморозвитком.

Далі автор книги навчить вас казати «НІ!». І це дійсно якість професіонала. Казати ні — це дуже складно. Інколи на це треба багато сили волі. Як казав гранд-майстер Йода: «Do or do not, there is no try». Завжди згадуйте це, коли чуєте від менеджера: «Можливо, ти СПРОБУЄШ виконати цю задачу до пʼятниці?». Тим паче, коли в цей момент ти чітко роумієш, що там роботи мінімум до наступної середи. Якщо ти кажеш: «Так, я СПРОБУЮ» — твій менеджер буде очікувати від тебе це, адже в його уяві ти дав КОМІТМЕНТ. Не встигнеш — він буде негативно думати про тебе. Якщо ж ти виконаєш задачу через НАДЗУСИЛЛЯ, увімкнеш режим супергероя, пропрацюєш 16 годин на день і встигнеш — це буде означати, що ти збрехав, коли сказав про початкову дату завершення. Чи взагалі весь час НЕДОПРАЦЬОВУВАВ. То ж, кращим в цьому випадку буде або зрізати скоуп задачі, або перенести дедлайн задачі. Іншого нема. Вчись казати НІ. НІ — кажуть професіонали.

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

• Не писати код коли ви у стані сварки з кимось — з дружиною, другом, сімʼєю. Вирішіть цю проблему якомога швидше, щоб не думати про це постійно. Навіть якщо ви вже на роботі — подзвоніть та знайдіть вихід. Адже код, який ви напишите в такому стані, скоріш за все, треба буде переробляти.
• Не писати код ночами, роблячи з себе героя-рятівника проєкту. Всі ці «нічні писульки» на свіжу голову виглядають костилями, які треба буде переписувати. Кожен з нас грішить цим. Навіть не кажіть мені, що ви ніколи не засиджувались до другої ночі під шум вітру чи дощу, під звук роботи кондиціонера, настукуючи ритмічно марш літерок, циклів та операторів у редакторі. Здоровий сон, спорт, прогулянки — це запорука чистого розуму і, як наслідок, коду.
• Не пишіть код під музику. Хоча це доволі суб’єктивно. Звісно, залежить від людини. Що до мене, сам я дуже часто програмую під Моцарта або Вівальді. Мене це навпаки драйвить та заставляє бути зконцетрованішим.
• Будьте обережні з зоною «потоку». І це дійсно так. Адже коли ви «в потоці», ви можете втартити загальне бачення проєкту та програмування перетвориться не в мистецтво, а в швидкісний друк. Треба дуже обережно контролювати свій стан під час около-поточного режиму.
• Коли ви заходите в глухий кут — зупиніться. Прогуляйтесь, прийміть душ, покатайтесь на велосипеді, машині, зіграйте в теніс. Одним словом — переключить ваші думки. Це дуже допомагає мозку обробити інформацію фоново та прийняти рішення.
• Допомагайте іншим. Як професіонали, ми повинні допомагати молодим колегам. Навчіться виділяти для цього час. Але попередьте в які години вас краще не турбувати.
• Навчіться нарешті й самостійно приймати допомогу. Дуже часто люди не вміють це робити — можливо через Его чи страх. Але така допомога буває дійсно корисною. Дійсно.

А далі, після декількох ударів, навчання та корисних порад — ми з вами підемо тренуватися. Тренуватися як самурай, боксер, плавець чи футболіст. Відточуючи майстерність на вже відомих задачах та доводячи до ідеалу кожний ваш рух. Тут головне не вирішувати нову та складну задачу, а тренуватися на вже вирішених і знайомих вам. Як боксер відточує майстерність удару, як плавець відточує руки руками, як футболіст відточує удар по воротам, ви, як професійний розробник, повинні відточувати вирішення шаблонних задач. Вранці та ввечері приділяти 10 хвилин таким тренуванням. Брати найпростіші задачі (відфільтрувати масив, написати рекурсивну функцію чи різні алгоритми сортування і т.д.) та виконувати їх не поспішаючи. Сенс цієї вправи у медитації. Медитації рішення задачі, яку ти вже знаєш як вирішувати. Він називає такі вправи — ката. І це дійсно працює! Коли на моєму проєкті пожежа, тиск з усіх боків, повний хаос, коли помічаю, що й я починаю горіти, втрачати фокус — тоді я глушу всі месенжери, звуки, одягаю шумодавні навушники і 10 хвилин вирішую такі «кати». І магія працює — через 10 хвилин таких вправ, такої медитації, мій фокус знову стає відновлений, я знову бачу весь проєкт, повертається «helicopter view» і я значно ефективніше вирішую проблеми.

Трохи розслабилися? А ось ще один удав від автора: РАХУЙТЕ ЦІНУ МІТИНГУ. Мітинг дійсно стає таким корисним, коли ви знаєте його ціну. Можливо, ефективніше було б написати просто повідомлення на пошту чи в месенджер? Не соромтеся йти з мітингів, якщо ви помічаєте, що зайві. Коли створюєте мітинг, то робіть короткий опис НАВІЩО він, яка його ціль. Так людям буде зрозуміліше що від нього очікувати. Погодьтеся, в часи масових звільнень мітинг з вашим менеджером та hr-ом можно сприймати геть по-різному :D

Знову трішки корисної інформації — основи оцінювання задач. Оцінки, які бізнес сприймає як commitment, а розробники як assumption. Автор дуже нам радить використовувати відомі техніки для покращення ваших оцінок такі як PERT, Wideband Delpi, Poker planning та інші. Якщо чесно, тут доволі небагато про процес оцінювання задач. Трішки більше про оцінки з тестування можете читнути тут: dou.ua/forums/topic/40516 . Або можете підписатися на мій телеграм бложик t.me/from_a_to_qa, де зовсім скоро буде анонс 4-годинного воркшопу як оцінку правильну дати і на слизькому не посковзнутися.

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

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

Тож, це був невеличкий огляд книжки Роберта Мартіна або як його ще назвають, Дядька Боба, про нетехнічні аспекти технічної людини. В цілому книжка доволі легенька й варта, щоб її прочитали в повному обсязі. І, як завжди, чи погоджуєтесь ви з порадами та кейсами Дядька Боба? Чи цей дідуган вижив з розуму та несе дичину? :)