Веб-розробка 10 кодування Antipatterns ви повинні уникати

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

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

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

Що таке Антипатерни?

Термін “антипаттерн” був придуманий у книзі під назвою AntiPatterns в 1998 році повторно використовувані рішення, які спочатку здаються корисними, але потім виявляється робити більше шкоди, ніж користі.

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

Також часто називають антипаттерни закономірності невдачі. Доброю новиною є те, що вона їх можна розпізнати і уникнути.

У цьому пості ми розглянемо 10 загальних кодуючих антипаттернів у веб-розробці, які можуть спонукати нас до думки, що ми маємо добре оптимізований код. (Зауважте, що антипаттерни, перераховані в цій публікації, не обов'язково збігаються з тим, що ви можете знайти в згаданій вище книзі.)

1. Передчасна оптимізація

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

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

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

Щоб запобігти передчасному оптимізації, хороша ідея дотримуватися принципу програмування YAGNI (Ви не маєте потреби). “завжди виконуйте речі, коли ви насправді потребуєте, ніколи, коли ви просто передбачаєте, що ви їх потребуєте.”

2. Відновлення колеса

The “винаходити колесо” антипаттерн іноді називають також “проектування у вакуумі”. Це відбувається, коли ми хочемо робити все самі і писати все з нуля, без пошуку вже існуючих методів, API або бібліотек.

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

3. Залежність пекла

Протилежність “винаходити колесо” антипаттерн - це ще один загальновідомий антипатерн “залежність пекла”.

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

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

4. Код спагетті

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

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

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

5. Програмування за допомогою перестановки

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

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

6. Програмування копіювання та вставки

“Копіювання та вставка програм” виникає, коли ми не дотримуємося принципу кодування "Не повторювати себе" (DRY), а замість створення загальних рішень вставляємо вже існуючі фрагменти коду в різні місця, а пізніше редагуємо їх, щоб відповідати даному контексту.

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

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

7. Програмування вантажно-культові

Назва “вантажопідйомні програми” виходить з конкретного етнографічного явища, званого “вантажний культ”. Вантажні культи з'явилися в південній частині Тихого океану після Другої світової війни, коли вимушені контакти з передовими цивілізаціями призводили до того, що вироблені продукти, такі як Coca-Cola, телевізори і холодильники, привезені на острови, були створені надприродними методи; і якщо вони виконують магічні обряди, подібні до звичаїв Заходу, вантаж, наповнений товарами, знову прийде.

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

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

8. Лавовий потік

Ми говоримо про “лавовий потік” антипаттерн, коли нам потрібно мати справу з кодом, який має надлишкові або неякісні деталі що здаються невід'ємними до програми, але ми не повністю розуміємо, що він робить або як він впливає на всю програму. Це робить його ризикованим.

Зазвичай це відбувається з застарілий код, або коли код був написаний іншим (зазвичай без належної документації), або коли проект переходив занадто швидко від розробки до фази виробництва.

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

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

9. Жорстке кодування

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

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

10. М'яке кодування

Якщо ми намагаємося дуже важко уникнути падіння жорсткого кодування, ми можемо легко запустити в інший антипаттерн, який називається “м'яке кодування”, що є його прямо протилежністю.

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

У крайніх випадках програма з м'якою коду може стати таким абстрактним і заплутаним, що його практично неможливо зрозуміти (особливо для нових членів команди), і надзвичайно важко підтримувати і налагоджувати.