Аудит перед підхопленням застосунку: що ми перевіряємо

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

Чому порядок має значення

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

1. Доступи й власність

Перше питання — не «чи хороший код?», а «чи можете ви опублікувати оновлення, нікого не питаючи?»

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

2. Чи можна зібрати й випустити його сьогодні?

Застосунок, якого давно ніхто не торкався, часто не може вийти з оновленням, навіть якщо в ньому нічого не зламано. Обидва стори щороку підвищують вимоги: Google Play вимагає, щоб оновлення були націлені на свіжий рівень Android API (вимоги до target API), а Apple — щоб нові білди збиралися свіжим Xcode і SDK (майбутні вимоги).

Тож спершу робимо нудне:

1. Чиста збірка з репозиторію на новій машині для обох платформ. 2. Відставання інструментів збірки (тулчейну): версії Flutter і Dart, Gradle й Android build tools, Xcode, мінімальні версії ОС, які підтримує застосунок. 3. Залежності: покинуті пакети, пакети, прибиті до старих версій, або такі, що блокують оновлення всього іншого. 4. Шлях релізу: чи є конвеєр автоматичних збірок (CI), чи він працює і чи публікує з акаунтів, які ви контролюєте. 5. Статус у сторах: відхилені білди, попередження щодо правил, застарілі декларації.

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

3. Сам код

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

• Структуру — чи розділені екрани, бізнес-логіка й доступ до даних так, щоб зміна в одному місці лишалася в одному місці.
• Керування станом — тобто як дані рухаються застосунком: один послідовний підхід чи кілька, нашарованих один на одного.
• Ризиковані місця — платежі, автентифікація, синхронізація, усе, що стосується грошей чи персональних даних.
• Платформний код — нативні модулі, плагіни й обхідні рішення, які вимагатимуть уваги з наступним релізом ОС.
• Тести, що мають значення — не відсоток покриття, а те, чи захищені сценарії (флоу), які приносять гроші.

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

4. Збої, дані й приватність

Четверта зона — що відбувається в продакшні:

• Звіти про збої: найчастіші збої, скільки користувачів вони зачіпають і чи тягнуться вони місяцями.
• Аналітика: що відстежується, чи це ще збирається і хто має доступ.
• Персональні дані: що застосунок зберігає на телефоні й на сервері, як це захищено і чи відповідають декларації приватності в сторах тому, що застосунок робить насправді.
• Сторонні SDK: кожен SDK у застосунку — це обіцянка вашим користувачам, яку ви даєте за когось іншого.

Що ви отримуєте наприкінці

Письмовий висновок, а не дзвінок від відділу продажу. Для кожної частини застосунку він каже: лишити, виправити, рефакторити чи переписати — і чому; як ухвалюється кожне з цих рішень, пояснено в статті виправити, рефакторити чи переписати успадкований застосунок. Далі роботу ділимо на модулі, кожен із фіксованою ціною, погодженою до написання коду. За замовчуванням ми лишаємо те, що працює; «перепишемо все» каже нова команда, яка ще не прочитала код.

Як читати пропозицію на підхоплення від будь-кого

Хоч кого б ви наймали, хороша пропозиція щодо успадкованого застосунку має такі риси:

1. Починається з доступів, а не з функцій. 2. Називає конкретні проблеми, знайдені у вашому коді, а не загальні найкращі практики. 3. Розділяє лишити, виправити, рефакторити й переписати, а не рахує переписування за замовчуванням. 4. Каже, як ви бачитимете прогрес — тестові білди, які можна встановити, кращі за звіти про статус. 5. Тримає код, акаунти й конвеєр на вас з першого дня.

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

Як ми працюємо з підхопленням

DriveCode розробляє застосунки для iOS та Android, Flutter-first. Це процес, що стоїть за нашою послугою підхоплення застосунку: спершу доступи на вас, потім письмовий висновок, далі фіксована ціна за модуль і знову регулярні релізи. Якщо попередній розробник просто зник, почніть із того, що повернути найперше.

Що часто питають

Вам потрібен доступ до всього, щоб щось сказати? Щоб дати висновок — так: репозиторій і доступ на читання до акаунтів у сторах і бекенду. До того ми можемо сказати, що дивитимемося і в якому порядку.

Ви порадите переписати застосунок? Лише ті частини, які дешевше замінити, ніж виправити, і висновок пояснює чому. Кожна частина отримує одну з чотирьох відповідей — лишити, виправити, рефакторити чи переписати, — а за замовчуванням ми лишаємо те, що працює.

Наш застосунок нативний. Ви все одно його підхопите? Так. Повертаємо доступи, переглядаємо застосунок і плануємо перехід на Flutter за принципом «спершу ядро»: Flutter-ядро виходить як MVP, поки нативний застосунок і далі отримує оновлення; решта приходить у регулярних оновленнях, починаючи з найпотрібніших.

Нам потрібні тести, перш ніж ви почнете? Ні. Відсутність тестів — це пункт у висновку, а не перешкода; ми додаємо їх там, де ризик найбільший.