Для багатьох із нас наші автомобілі, мотоцикли та велосипеди є критичними для щоденної роботи. Навіть якщо ми не використовуємо автомобіль регулярно, таксі, автобуси, потяги чи пароми, якими ми користуємось для поїздок, є важливими для нашого повсякденного життя.
Що б ви подумали, якби дізналися, що автомобіль, на якому ви їдете, не проходив перевірку, або хоча б не було змінено олію протягом останніх кількох років? Ігнорували б ви свого механіка, чи відвезли б ви автомобіль на перевірку, хоча б для найпростіших процедур, коли це необхідно?
Ідея не обслуговувати свій автомобіль здається безглуздою. Усі власники автомобілів знають, що таке обслуговування необхідне для правильної роботи машини. Якщо не виконувати базове технічне обслуговування, це, можливо, не спричинить жодних проблем у короткостроковій перспективі, але одного дня ви просто не зможете завести автомобіль, і він відмовиться рушити з місця.
Чому ж ми припускаємо, що веб-додатки, які працюють на серверах, не потребують такого ж технічного обслуговування? Часто компанія витрачає набагато більше — іноді в 10 або 100 разів більше — на розробку веб-додатка, ніж на покупку одного автомобіля для компанії. І все ж ми майже не звертаємо увагу на постійну підтримку та обслуговування цього веб-додатка.
Кожен працюючий веб-додаток потребує технічного обслуговування. Як і ваш автомобіль чи автобус, більшість додатків «працюють добре»… поки не перестануть працювати.
А коли вони перестануть працювати, може статися багато чого:
- Сайт може бути повністю недоступним, і ніхто не зможе отримати доступ до нього.
- Ще гірше, сайт може бути частково доступним, і при цьому ви втратите важливі дані через постійні збої.
- І навіть більш небезпечно: сайт може бути зламаний без вашого відома через довгострокову, не виправлену проблему безпеки, і хтось може тихо витягувати ваші дані користувачів.
Протягом багатьох років роботи в компанії reinteractive ми працювали з сотнями додатків Ruby on Rails. Одне, що об’єднує всі ці додатки без сумніву — це те, що вони були розроблені з обмеженнями часу, що іноді призводить до скорочень, які можна було б вважати виправданими на той момент. Але ці скорочення можуть накопичуватися у вигляді технічного боргу в коді і ускладнювати майбутнє обслуговування та виправлення помилок.
Досить просто підтримувати додаток актуальним за допомогою останніх версій коду, якщо це робити регулярно. Рекомендується робити це двічі на рік. Якщо ж цього не робити роками, задача оновлення коду, виправлення всіх проблем з безпекою та помилок може стати дуже складною. Ми рекомендуємо, щоб кожен додаток на Rails перевірявся щорічно за дев'ятьма критичними пунктами, і щоб було складено звіт для подальших дій. Це може зробити ваша власна команда розробників, або ж ви можете звернутися до компанії reinteractive. Ми встановили ціну на нашу послугу Rails App Review так, щоб це було очевидним вибором для виконання цієї перевірки.
Дев'ять пунктів, які потрібно перевірити:
1) Налаштування та документація Як добре документовано ваш додаток? Як швидко новий розробник може зрозуміти, що і як працює? Чи є щось, що відсутнє в README щодо налаштування та запуску додатка? Чи є інформація про місце розташування хостингу вашого додатка і до кого звертатися, щоб отримати доступ? Це критична інформація, яка завжди необхідна в разі виникнення проблем. Важливо, щоб ця інформація була актуальною.
2) Автоматизовані тести Чи має ваш додаток достатнє покриття тестами? Золотий стандарт — 100% покриття тестами, хоча не всі додатки досягають цього рівня (і справді не завжди це потрібно).
Ключовим моментом є те, що важливі частини вашого додатка повинні бути протестовані настільки, наскільки це можливо, щоб новий розробник, який працює над додатком, міг швидко побачити, чи не зламав він щось важливе своїм оновленням.
3) Налаштування бази даних Чи не закінчується простір у вашій базі даних? Чи є у вас актуальна версія? Чи достатньо потужна вона? Чи налаштовані індекси для забезпечення швидких запитів? Але найголовніше — чи є система резервного копіювання, і чи працює вона?
У нас був клієнт на Різдво, який звернувся до нас (буквально в день Різдва), тому що віддалений розробник, якого вони найняли, запустив автоматизовані тести на їхній живій базі даних, повністю її стерши. Ми отримали доступ до їхнього додатка та розслідували ситуацію, намагаючись відновити резервну копію, і з’ясували, що її не було, а була лише одна копія за два місяці до цього. Цей клієнт втратив усі дані про бронювання за два місяці найбільш завантаженого часу року… не дуже гарний різдвяний подарунок.
4) Продуктивність Чи є запити, які сповільнюють роботу додатка? Скільки часу займає завантаження додатка? Чи використовуєте ви кешування? Чи є можливості для покращення швидкості роботи додатка? Згідно з Google: > Погана новина: за нашими новими даними, на це все ще потрібно близько 15 секунд. Це занадто повільно, коли врахувати, що 53% відвідувачів мобільних сайтів покидають сторінку, якщо вона завантажується більше трьох секунд. Мати швидкий час відгуку на вашому додатку може стати вирішальним фактором між тим, щоб отримати цього клієнта чи втратити його.
5) Безпека Часто додаток працює на тих самих версіях програмного забезпечення, на яких він був створений. Це погано. Насправді виправлення цього пункту може бути вирішальним для запобігання серйозних порушень безпеки або блокування вашого сайту. Ви повинні використовувати найновіші основні версії залежних бібліотек програмного забезпечення, а якщо це неможливо — хоча б найновіші версії патчів, щоб забезпечити проведення критичних оновлень безпеки.
6) Версії Разом з пунктом 5, оновлення до найновіших версій коду може покращити продуктивність і усунути помилки. Важливо при оновленні версій вашого програмного забезпечення та залежних бібліотек мати автоматизований набір тестів, щоб переконатися, що оновлення чогось не зламає ваш додаток.
7) Якість коду Якість коду — це сфера, наповнена безліччю різних думок, але є кілька чітких показників, яких потрібно дотримуватися для кожного додатка на Ruby on Rails. Правильне виконання цих пунктів може означати різницю між тим, чи швидко новий розробник розбереться і почне розробляти нові функції, чи буде він застрягати, намагаючись виправити постійні проблеми.
8) Чутливі дані У додатку можуть бути записані чутливі дані в коді чи збережені в базі даних. Ви повинні переконатися, що всі паролі, API-ключі, секретні токени тощо зберігаються в середовищі виконання додатка, а не в самому коді.
9) Технічний борг І, нарешті, вищезгадані пункти, якщо їх не обробляти, стають технічним боргом. Що означає: > Технічний борг (також відомий як борг за проектуванням або борг коду) — це концепція в розробці програмного забезпечення, яка відображає передбачувану вартість додаткової роботи, спричиненої вибором легкого рішення зараз замість використання кращого підходу, який займе більше часу. Виявлення цих проблем, якщо вони існують, може допомогти знайти області, де трохи часу та грошей, витрачених зараз, дозволять значно прискорити подальшу розробку.
Вищезгадані дев'ять пунктів — це мінімум, який ми б очікували, щоб додаток перевірявся щорічно.
Ви можете зробити це самі з вашою командою, але якщо ви хочете, щоб це зробила зовнішня компанія, reinteractive може виконати перевірку через нашу Rails App Review service за низькою фіксованою ціною.
Перекладено з: Have you serviced your Ruby on Rails Application?