10 причин, чому вам потрібна оптимізація коду
Хоча ми пишемо код, ми постійно приймаємо рішення і вибираємо між рішеннями, які можуть здатися еквівалентними спочатку. Пізніше зазвичай виявляється, що деякі вибори призводять до більш ефективної програми, ніж інші, тому, природно, виникає пошуки найкращих методів кодування та методів оптимізації, і ми починаємо розглянемо весь процес розробки як проблему оптимізації.
Незважаючи на те, що проблеми з оптимізацією не єдині, з якими регулярно займаються розробники, наприклад, існують проблеми з вирішенням і пошук проблем, оптимізація - це завдання, яке охоплює різні етапи веб-розробки, ймовірно, найбільш.
Оптимізація коду може відбуватися на різних рівнях, залежно від того, наскільки близька оптимізація, яку ми виконуємо, до машинного коду. У веб-розробці ми можемо виконувати лише оптимізацію більш високого рівня, як оптимізація на рівні збірки або виконання не є для нас можливим, але у нас ще є багато можливостей.
Ми можемо оптимізувати наш код на архітектурному рівні смарт-шаблонів дизайну, на рівні вихідного коду, використовуючи найкращі практики кодування та використовуючи відповідні інструменти, і ми також можемо підвищити продуктивність нашої команди впроваджуючи керівництва стилю кодування в наш робочий процес.
Незалежно від того, яким методом ми хочемо йти разом, існує емпіричне правило, яке потрібно слідувати кожній спробі оптимізації коду: ми завжди повинні здійснювати оптимізацію таким чином, щоб не змінювати значення коду.
Переваги оптимізації коду зростають відповідно до зростання нашого проекту, а також навіть початково малі проекти можуть з часом стати великими, отримання навичок оптимізації твердих кодів майже завжди має вимірні позитивні результати.
1. Основа чистого коду
Як проект дозріває, так і все більше і більше розробників починають працювати над цим, дублювання і накладання, як правило, рано чи пізно з'являються, і раптом ми розуміємо, що навряд чи ми розуміємо, що відбувається.
Це не випадково, що дотримання принципу DRY (Не повторювати себе) є одним з наріжних каменів ефективної розробки програмного забезпечення. Добре стрункіша, ретельно оптимізована кодова база, в якій ми можемо повторно використовувати ті ж самі елементи кілька разів завжди є більш гладким і чистим, і тому набагато легше зрозуміти і працювати.
2. Вища консистенція
Консистенція - це як робота по дому, коли її належним чином доглядають ніхто, але коли її нехтують, все це виглядає безладним, і ми знаходимося в хаосі.
Виконання повної консистенції важке, як забезпечення зворотної сумісності може зрештою стати на шляху поліпшення, але звертаючи увагу з використанням узгоджених кодексів, сумісних API та відповідних стандартів безсумнівно може зменшити біль.
Особливо важливим є збереження послідовності коду коли нам потрібно мати справу з застарілим кодом, або у випадках великих проектів залучити багато розробників.
3. Швидкі сайти
Оптимізація коду схожа на купівлю більш швидкого автомобіля. У результаті наш код виконується швидше, і наш сайт або додаток споживає менше пам'яті ніж раніше. Хоча процес оптимізації може знадобитися додатковий час і гроші, результат - a кращий досвід, не тільки для розробників, але й для кінцевих користувачів.
Швидкий код тягне за собою коротший час завантаження сторінки а також, що є великою угодою в обох світів пошукової оптимізації і маркетингу конверсії. Дослідження стверджують, що “майже половина користувачів Інтернету очікують, що сайт завантажиться за 2 секунди або менше, і вони прагнуть відмовитися від сайту, який не завантажується протягом 3 секунд”, тому швидкість явно не є областю, яку ми можемо безпечно ігнорувати.
4. Краща читаність коду
Чистота є важливим аспектом підтримки коду. Нечистий код із спеціальним форматуванням важко читати, тому важко зрозуміти, особливо для розробників, які є новими для проекту.
Ми можемо захистити себе біль у справі з нерозбірливим кодом якщо застосовувати певні методи оптимізації коду, такі як:
- з використанням узгоджених іменних угод зі значущими іменами, такими як BEM
- послідовне форматування з логічним використанням відступів, пробілів і вертикальних інтервалів
- уникнення зайвого шуму, наприклад, очевидних, очевидних коментарів
Саме тому великі проекти, такі як WordPress, jQuery і Mootools, мають чіткі вказівки стилю кодування, кожен розробник яких повинен брати участь,.
5. Більш ефективне рефакторинг
У веб-розробці це часто відбувається, що ми успадковуємо код від когось іншого, і швидко розуміємо, що це так далеко не оптимальним, чи то в термінах структура, продуктивність або ремонтопридатність. Те ж саме може статися з нашими власними попередніми проектами, які ми написали, коли у нас було набагато менше досвіду програмування.
В інших випадках цілі інакше великого проекту змінюються з часом, і ми повинні визначення пріоритетів інших речей у додатку ніж раніше.
Ми говоримо про рефакторинг, коли ми змінити (очистити) існуючий код для того, щоб оптимізувати його, не змінюючи жодної своєї функціональності. Рефакторінг необхідно виконувати з великою обережністю, так як якщо це зроблено неправильно, ми можемо легко отримати код, який є навіть менш оптимальним, ніж оригінал..
На щастя, у нас є багато перевірених методів, які можуть зробити процес рефакторингу безперебійним.
6. Більш пряма налагодження
Налагодження займає значну частину робочого процесу веб-розробки, і зазвичай це складне або навіть складне завдання. Досить важко, якщо нам доведеться налагоджувати свій код, але це набагато гірше, коли нам потрібно знайти помилки в чужому, особливо якщо це щось подібне до безконечного спагеті-коду, який використовує тільки функції.
Розумний дизайн і архітектурні візерунки, як от з використанням об'єктів і різних модулів, і чіткі правила кодування може полегшити процес налагодження, навіть якщо він, швидше за все, не буде нашим улюбленим завданням.
7. Покращений робочий процес
Багато проектів веб-розробки запускаються розподіленими командами, такими як спільноти з відкритим кодом або віддалені команди. Одна з найважчих речей в управлінні таким робочим процесом - знайти спосіб, який робить комунікацію достатньо ефективною дозволити членам команди легко зрозуміти один одного, і не потрібно постійно обговорювати дефолти.
Погоджені з найкращими практиками та методичними посібниками можуть подолати розрив між людьми з різних фонів, не кажучи вже про звичайні труднощі між командами розробки та розробки в більшості веб-проектів..
Оптимізація коду також є оптимізація робочого процесу, як якщо члени команди говорять на спільній мові і поділяють однакові декларовані цілі, вони також зможуть працювати разом без особливих труднощів.
8. Легше обслуговування коду
Незважаючи на те, що побудова чогось з самого початку, як правило, більше задоволення, ніж підтримка вже існуючого коду, іноді нам все одно потрібно виконувати поточне обслуговування коду. Робота з вже існуючими системами також може дати нам нові погляди на оптимізацію коду, оскільки це інший досвід, ніж ранні оптимізації в новому проекті..
У обслуговуванні програмного забезпечення ми вже знаходимося на стадії, коли ми можемо зловити реальні проблеми продуктивності та ефективності, а також працювати з реальними користувачами замість гіпотетичних випадків використання..
Підтримка кодексу зазвичай отримує мало уваги в колах розробників, але вона все ще може бути корисним завданням, якщо ми дотримуємося найкращих практик, наприклад, використовуючи надійний контроль версій, управління залежностями, платформи для тестування та тестування, і правильно дбати про документацію.
9. Швидше розробка функцій
Постійні інновації ядро залишається актуальним у нашій області, як і в тому випадку, якщо ми не покажемо нічого нового для наших користувачів, ми можемо швидко залишитися позаду. Розширення проекту та додавання до нього нових функцій зазвичай набагато швидше, якщо ми працюємо з добре оптимізованою базою чистих кодів.
Окрім вже обговорених методів оптимізації коду, розробка функцій може також набирати обертів, якщо ми будемо в курсі сучасні методи управління проектами, наприклад, якщо ми використовуємо ітераційні моделі життєвого циклу замість традиційної моделі водоспаду.
10. Менший технічний борг
Термін "технічний борг" був введений Уордом Каннінгем, програмістом, який також розробив першу вікі. Він порівнює наслідки наших поганих програмних рішень, які накопичуються з плином часу, до фінансового боргу, в якому люди платять відсотки в майбутньому, щоб швидко отримати гроші в даний час..
Такі менш оптимальні рішення зазвичай проявляються у вигляді швидких виправлень, копіювання та вставки програм, жорсткого кодування, програмування вантажів та інших кодують антипатерни і недбалі робочі звички.
Це в основному Неможливо повністю уникнути технічного боргу, оскільки навіть хороші рішення можуть бути менш бажаними наслідками в майбутньому, але якщо ми старанно оптимізуємо наш код, ми, безумовно, будемо обтяжений значно меншим технічним боргом.
