Коли ви хочете їсти, є 2 варіанти: прийти додому, приготувати смачний, корисний, насичений обід і насолодитися їжею, або швиденько забігти в кафешку і перекусити гамбургером з колою. Завдання виконано — ви ситі. Але які наслідки? Так виглядає антипатерн у програмуванні. Те, що, на перший погляд, безпечно і вигідно, може виявитися проблемою. Розберімо, що таке антипатерн і які помилки легко зробити на старті.
Антипатерн — ваша шкідлива звичка
Антипатерни програмування — це протилежність класичним і зрозумілим шаблонам проєктування. Процес розробки будується на певних принципах, шаблонах, які можна повторно використовувати і отримувати потрібний результат. Але буває ситуація, коли в голову приходить «екстра вигідне» рішення. Воно здається ефективним і навіть правильним. Вирішує проблему «тут і зараз».
Але так ви створюєте антипатерн — процес, який призводить до неправильних результатів надалі. Чому так відбувається:
- Є проблема в частині коду. Ви придумали «геніальне» рішення, яке відрізняється від класичних шаблонів проєктування.
- Впроваджуєте це рішення в код і дана частина працює. Але ви не знаєте, як вона буде працювати далі. Тому що архітектура будувалася без урахування цього рішення.
- Зовсім інша частина коду від цього може постраждати. Або код взагалі ще не написаний. Але інший розробник не знає про антипатерн (та й ви самі можете просто забути). Потім не розуміє, чому код не працює як потрібно.
Створюється технічний борг, який сніжним шаром накопичується. Anti Pattern — це шкідлива звичка. Вона дійсно може бути відмінним рішенням наразі, але надалі створює більше проблем.
5 ключових антипатернів в програмуванні
Розберімо ключові помилки, які допускають не тільки новачки, але і досвідчені програмісти. Ці антипатерни дуже поширені.
Спагеті-код
Цей антипатерн отримав таку назву, тому що код виглядає, як спагеті на тарілці. Не зрозуміло, де початок, а де кінець. Відбувається тому, що програміст пише функцію, потім ще одну, за нею — наступну. Але не дивиться на загальну логіку і структуру.
У підсумку, коли код написаний, він дивиться на загальну структуру. А вона хаотична. Застосунок працює, але рефакторити його вкрай важко або неможливо. Простіше заново все переписати.
Такий код складно читати, змінювати, тестувати, масштабувати. А якщо там ще й є помилки (що в 90% випадків), то відсутність нормальної структури створить проблему. Рішення: вибудовувати відразу правильну структуру:
- кожен логічний шматок розбивати на функції та окремі частини;
- давати нормальні імена змінним, класам та іншим компонентам коду;
- писати коментарі, де це важливо;
- при використанні повторюваних частин копіпаст збирати в окремі блоки;
- робити рефакторинг ітераціями.
Антипатерни програмування можуть здаватися несуттєвими. Але в підсумку призводять до величезних проблем надалі. Спагеті-код — один з таких.
Золотий молот
У програмуванні кожен шаблон вирішує певний тип завдань. Але тепер уявіть, що ви придумали рішення, яке підійшло для завдань А, В, С. Ось у вас в руках «золотий молоток», який здатний забивати будь-який цвях. Але це не означає, що він забиватиме шуруп.
Цей antipattern є проблемою багатьох розробників. Якщо рішення спрацювало кілька разів, це не означає, що воно підійде для всього. Не потрібно намагатися вирішити будь-яке завдання одним інструментом. Уявіть, що ви навчилися готувати яєчню. Тепер ви робите її на сніданок, обід і вечерю, на свята, подаєте всім гостям. І навіть у закладі замовляєте яєчню. Начебто їжа, але щось не так.
Якір для човна
Думати наперед іноді корисно. Але цей anti pattern призводить до негативних наслідків. В першу чергу, для програміста. У чому суть:
- ви думаєте наперед, що потенційно може знадобитися;
- додаєте в код додаткові рядки, щоб «потім було легше»;
- коли прийде час – пара кліків, і нова функція працює;
- потім виявляється, що ця функція не потрібна, або вона повинна працювати інакше;
- ваш код написаний просто так, завантажив обсяг, вкрав ваш час.
Код стає неактуальним. Цей «якір» стає важким, незручним і не факт, що взагалі знадобиться. Але він вже у вашому човні.
Об’єкт Бога
Уявіть, що у вас в офісі є колега, який пише код, тестує його, веде проєктну документацію, спілкується зі стейкхолдерами, керує процесами бізнес-аналізу. А ще він розробляє візуал для додатка, підключає API й видає вам зарплату. Завтра він захворіє і не вийде на роботу. Що буде в компанії?
Antipattern Об’єкт Бога і є таким «співробітником». Тільки в коді. Коли один клас робить занадто багато, стає «всемогутнім», він створює залежність інших класів від нього. Наприклад, клас User зберігає не тільки ім’я, але ще й телефон, кошик клієнта, історію покупок і транзакції. Програміст додає нові фічі в цей же клас, як правило, через лінь. Тому що зручно. Він розростається, стає складно читається і критично важко тестується. А якщо потрібні зміни — ймовірність помилок сильно зростає.
Щоб такі антипатерни, як Об’єкт Бога, не виникали, використовуйте принципи SOLID.
Копіювання та вставка
Використання іншого коду як шаблону — норма. Але чому тоді це антипатерни програмування? Тому що шкідливе саме бездумне копіювання. Рішення, яке здається очевидним і зрозумілим, створює надалі проблему.
Наприклад, вам потрібно додати на ряд сторінок форму реєстрації. Вона вже є на StackOverflow або ви написали самі. Копіюєте, вставляєте без змін на кожну сторінку просто шматком коду.
Замовник каже, що потрібно додати в форму ще одне поле. А вона у вас на 24 сторінках. Вам доведеться в кожній формі внести зміни.
Щоб вирішити цю проблему, потрібно:
- спочатку відмовитися від ідеї бездумного копіювання, вивчати код і робити його адаптованим під ваш проєкт;
- провести код-рев’ю, перш ніж робити безліч копій;
- провести рефакторинг, винести в окремі функції і класи, щоб змінювати в одному місці, а не в десятках інших;
- провести тестування, переконатися, що код підходить, а не є «золотим молотком».
Якщо копіюєте код (неважливо, чужий або робите дублікат свого), переконайтеся, що він не стане anti pattern.
YouTube
Висновок
Тепер ви знаєте, що таке антипатерни програмування, які існують найбільш поширені і що робити, щоб їх не допускати. Пам’ятайте, що швидке, на перший погляд, ідеальне рішення може призвести до великих наслідків. Позбавляйтеся від шкідливих звичок програмування ще до їх появи.
