Мої найважливіші кроки для вдосконалення коду в команді

Партнер видання

Блогер та розробник Джозеф Круз розповів, як покращити роботу команди розробників, так показати їм справжню пристрасть і… ненависть.

Пропонуємо вам переклад його його авторського блогу від нашої редакції. Далі — слово автору.

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

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

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

І моя відповідь — можна. І потрібно!

Усвідомлення

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

Я навмисно підкреслив слово «поточних». Поганий код у будь-якому випадку рано чи пізно стане на заваді подальшого розвитку продукту і зробить його підтримку не тільки кошмаром для клієнтів і програмістів, але й вкрай збитковим бізнесом для компанії.

Спецпроєкти

Google запускає оновлений курс із машинного навчання українською мовою. Він займає 15 годин

Процеси, люди та культура: як побудувати ефективне управління техборгом. Досвід FAVBET Tech

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

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

Крок перший. Ненависть

Це найсуперечливіший тезис з усіх, які я тут наведу. З ним часто не погоджуються (навіть до особистих нападок і ображених поглядів), але його ефективність доведена на практиці. Отже, на самому початку програмістам потрібно прищепити ненависть. Ненависть до поганого і брудного коду, до дурних помилок, до п’ятисотрядкових випадків і класів, що складаються з одного методу розміром з будинок.

Як це зробити?

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

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

І ще одне: не переходьте на особистість (хто написав ЦЕ? Вася? Вася, тобі не соромно? Ти втратиш премію!). Але не щадіть руйнівний код. Я вважаю цілком нормальним запитати: «З якою метою цей підсвідомий смітник був завантажений в код?». Тому що код — це лайно. Тому що програмісти не розуміють його, поки ви їм не поясните. Це жорстко, але ефективно.

Крок другий. Пристрасть

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

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

Крок третій: здоровий глузд

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

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

Це найскладніше. Найскладніше пояснити, чому «вивантаження підсвідомості в код» є складним завданням, але впровадження фабрики для створення постійних рядків для підписів кнопок є не менш складним (припустимо, що локалізація не передбачена).

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

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

Висновок

Ось і все. З власного досвіду можу сказати, що «ненависть» і «пристрасть» прищеплюються приблизно за півроку, а іноді потрібно більше двох років, щоб досягти етапу «здорового глузду». Це приходить з досвідом.

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

Партнер видання

Favbet Tech – це ІТ-компанія зі 100% українською‌ ДНК, що створює досконалі сервіси для iGaming і Betting з використанням передових технологій та надає доступ до них. Favbet Tech розробляє інноваційне програмне забезпечення через складну багатокомпонентну платформу, яка здатна витримувати величезні навантаження та створювати унікальний досвід для гравців.