• Преамбула
    Давайте уявимо, що вас попросили очолити один з напрямків у вашій компанії. Ви, звичайно, знаєте всіх людей в команді, неодноразово перетиналися в коридорах і пили пиво на корпоративах. Минулий керівник був непоганим людиною, але у нього змінилися плани і він звільнився.
    І ось ви, беручи пост, знайомитеся з командою: начебто є потенційно сильні розробники з досвідом, є кілька, які подають надії юніорів. Але що-то відразу впадає в очі. І чим довше ви вдивляється у ці зайняті роботою розумні обличчя, тим більше розумієте, що перед вами не команда, а «група розробників». А те, що вони пишуть… Ви і не думали, що програмісти можуть так писати код. Ви дивитесь на пластилиновую архітектуру, на класи в 6000 рядків коду, на методи, які займають десять сторінок машинописного тексту, на кейси, сильногіллясті як голови Лірнейської гідри. І у вас з'являється мимовільний питання: а чи можна щось з такою командою зробити взагалі?
    І моя відповідь - можна. І потрібно!
    Усвідомлення
    Отже, з чого почати? Почати треба з розуміння того, що ніхто і ніколи свідомо не пише погано. Найімовірніше, попередній керівник або зовсім не стежив за якістю коду його підопічних, повністю зосередившись на поточних фінансових показниках і плани, або свідомо приносив якість коду в жертву тим самим поточним фінансовим показникам.
    Я спеціально зробив наголос на слово «поточним». Поганий код, у будь-якому випадку, з часом стане на шляху подальшого розвитку продукту і зробить його підтримку не тільки пеклом для замовників і програмістів, але і вкрай збитковим для компанії справою. У цьому випадку, ваша фірма, замість того, щоб інвестувати в розвиток, змушена буде вкладати величезні суми в виправлення помилок і підтримку життя вмираючого під вагою власного внутрішнього неподобства продукту. Або витрачати ресурси на написання нових версій продукту, який, при належному підході, міг би ще довго жити і приносити прибуток бізнесу і радість розробнику.
    Взагалі, для того, щоб сформовані програмісти раптом стали писати правильно, потрібно або диво, або довга копітка робота. Незважаючи на будь-який ваш оптимізм, я рекомендую вибрати другий шлях. Цей шлях складається з трьох нерівних кроків, які я розкрию нижче.
    Пам'ятайте, що Івана Царевича в казках, пожвавлюючи, спочатку поливали мертвої водою і тільки потім живий. Ймовірно, в кінці він одружився на який-небудь Василині Премудрої. У розробці приблизно так само.
    Крок перший. Ненависть
    Ймовірно, це найбільш спірний тезу з усіх, які я буду приводити тут. Зі мною часто не погоджувалися (доходило до переходу на особистості і скривдженого сопіння в кутку), але ефективність його перевірена на практиці.
    Отже, на самому початку програмістам потрібно прищепити ненависть. Ненависть до поганого і брудного кодом, до прикрих помилок, до кейсах п'ять рядків і класів, що складається з одного методу розміром з будинок.
    Як це зробити? Почніть проводити відкриті інспекції коду. Збирайтеся всією командою раз в тиждень, і нехай хто-небудь шукає в коді бруд і антипаттерны. Якщо у вас є навички відрізнити поганий код від хорошого - беріть участь в них самі, якщо немає - просите того, кому ви в цьому відношенні довіряєте.
    Після декількох таких ревью програмісти, найімовірніше, вже будуть розуміти, що таке магічна кнопка і звідки викликати рефакторинг «винести метод». Ще раз: виходьте з того, що поганий код писати ніхто не любить. Просто багато хто не розуміють, що він поганий.
    І ще: не переходити на особистості (хто написав ЦЕ? Вася? Вася, як тобі не соромно? Залишишся без премії!). Але поганий код не пожалійте. Я вважаю - абсолютно нормально довідатися «з якою метою в код був залитий цей дамп підсвідомості». Тому, що код - погань. Тому, що програмісти цього не розуміють, поки не скажеш. Це жорстко, але ефективно.
    Крок другий. Пристрасть
    Покажіть програмістам патерни, приклади гарної архітектури та гарний код. Заразіть їх цим. Нехай вони кидаються розумними словами типу «фабрика» і «декоратор», усвідомлюючи свою професійну компетентність, а їх код рясніє нікому не потрібними стратегіями і нічого не викликають шаблонними методами. Зробити цей крок простіше, але робити це треба приблизно в один час з першим. Нехай вони конструюють, мислять і насолоджуються фактом свого знання теоретичних основ архітектури. Це тільки на користь і, між іншим, дуже мотивує.
    Але головне, що треба усвідомити - у жодному разі не можна зупинятися на цьому кроці, незважаючи на те, що він здається дуже привабливим і створює відчуття роботи з командою професіоналів.
    Крок третій. Розсудливість
    Тепер, коли ваші програмісти вміють вловити запах, що йде від протухлого коду, і сконструювати фабрику по створенню віконних інтерфейсів різних кольорів, саме час подумати про головне - про реалізм. Поясніть хлопцям, що патерн проектування застосовується тільки в потрібному місці і потрібному часу, метод може бути і більше, ніж з двох рядків, а строкові константи в тексті, у загальному-те, іноді допустимі. Поясніть, що, перш за все, треба писати просту і прозору стабільно працюючу систему, а вже потім «досконале архітектурне рішення, на 93% покрите патернами проектування».
    Це найскладніше. Складніше всього пояснити, чому «дамп підсвідомості код» - це складно, але не менш складна і реалізація фабрики по створенню константних рядків для підписів до кнопок (будемо вважати, що локалізація не передбачається). Але позбавлятися від цього треба. Не зробити цей крок означає залишити програміста в вічної впевненості, що він пише добре і розбирається в архітектурі тоді, як пише він трохи краще, ніж раніше, а його архітектурні рішення змушують схопитися за голову. І це біда для будь-якої команди.
    Тому, тут доведеться прикласти максимум зусиль, щоб пояснити, чому раніше було «фабрика - це добре», а тепер «фабрика - це погано». Але я впевнений, вони окупляться сповна.
    Пара слів в висновок
    Ну, власне, і все. Можу тільки сказати на своєму досвіді, що «ненависть» і «пристрасть» прищеплюються приблизно за півроку, а на доведення кроку «Розсудливість» іноді йде більше двох років, і воно приходить разом з досвідом. І приготуйтеся, що ваші «поточні фінансові показники», ймовірно, просядуть на деякий час. Але отримана замість команда, яка вміє створювати легкий, акуратний код, підходящий для тривалої підтримки і розширення, на мій погляд, варто цих інвестицій.