Как да поемете сайт или приложение, изградено от друг екип

За да поемете сайт или приложение, изградено от друг екип, първо си осигурете достъп и собственост върху всички акаунти, после прегледайте кода и хостинга, без да променяте нищо, и едва тогава поправяйте проблемите на малки стъпки, които могат да се върнат назад. Редът е важен. Нов екип, който започне да пренаписва още през първата седмица, обикновено губи знанието, скрито в стария код, и чупи неща, от които бизнесът зависи. Пренаписването е оправдано само в няколко конкретни случая, а прегледът показва дали вашият е един от тях.

#Първо достъпът и собствеността

Най-рисковият момент при предаването на проект е, когато предишният екип още държи ключове, които вие нямате. Преди каквато и да е техническа работа съставете списък на всички акаунти, от които продуктът зависи, и проверете, че всеки е на името на вашата фирма, а собственици или администратори са ваши хора. Предишният разработчик може да запази потребителски достъп за известно време, ако отношенията са добри, но не бива да е единственият, който може да влезе.

• Изходен код: Git хранилището (GitHub, GitLab, Bitbucket или собствен сървър) с цялата история, всички клонове и тагове. ZIP архив с текущите файлове не е предаване на проект.
• Домейни и DNS: акаунтът при регистратора и достъпът до DNS зоната. Изгубеният домейн е най-трудният за поправяне проблем.
• Хостинг и облак: сървърът или облачният акаунт, контролният панел, SSH ключовете, достъпът до базата данни и мястото, където се пазят архивите.
• Външни услуги: платежни доставчици, изпращане на имейли, карти, статистика, проследяване на грешки, CDN, SMS и всички API ключове в конфигурацията.
• Магазини за приложения: при мобилно приложение това са акаунтите в Apple Developer и Google Play Console, сертификатите и ключовете за подписване. Проверете кой държи ключа за подписване на Android версията: ако Google Play App Signing не е включен и ключът бъде изгубен, съществуващата страница в магазина не може да получава обновления.
• Документация и достъпи: README файлове, бележки за внедряване, файлове с настройки на средата и записи в мениджъра на пароли.

След като получите достъп, сменете паролите и ключовете, които предишният екип е знаел. Планирайте смяната предварително: ако стар API ключ е записан директно някъде в кода, съответната функция ще спре да работи и това може да не се забележи веднага.

#Какво трябва да обхваща прегледът на кода и хостинга

Прегледът отговаря на един въпрос: може ли продуктът да се поддържа и развива на разумна цена и какво трябва да се оправи първо. Резултатът е писмен доклад с констатации, подредени по степен на риск, така че да можете да вземате решения, без сами да четете кода.

Кодът

• Версиите на езика и фреймуърка и дали още получават поправки за сигурност.
• Зависимостите: колко са, доколко са остарели и дали имат известни уязвимости. Инструменти като composer audit и npm audit показват това.
• Дали проектът се изгражда и стартира от хранилището на чиста машина само по писмените инструкции.
• Автоматичните тестове: има ли ги, минават ли и покриват ли плащанията, влизането в системата и промените по данните.
• Структурата: дали бизнес правилата са събрани на едно място или са копирани из контролери, шаблони и скриптове.
• Пароли и ключове, записани в хранилището. Те трябва да се сменят, дори ако по-късно са изтрити, защото Git пази цялата история.

Хостингът и данните

• Къде работи приложението, кой поддържа сървъра и как се публикуват нови версии. Ръчното качване на файлове по FTP е тревожен знак.
• Архивите: къде са, колко често се правят и дали някой скоро е възстановявал данни от тях. Непроверен архив е само предположение.
• Наблюдението и логовете: дали грешките се записват някъде, където можете да ги прочетете.
• Разликите между хранилището и това, което реално работи. Често се оказва, че има поправки, направени директно на сървъра, които никога не са влезли в контрола на версиите.

Последната проверка изисква специално внимание. Сравнете публикуваните файлове с хранилището преди първото си внедряване, иначе първата ви версия може незабелязано да отмени нечия спешна поправка.

#План на етапи, при който бизнесът продължава да работи

След прегледа работата върви на етапи, всеки достатъчно малък, за да се пусне самостоятелно и при нужда да се върне.

1. Стабилизиране. Кодът се премества в хранилище, което е ваше, внедряването става повторяемо, проверява се, че архивите се възстановяват, и се добавя проследяване на грешки. За потребителите нищо не се променя.
2. Защита на критичните процеси. Пишат се автоматични тестове за частите, от които зависят приходите: поръчка и плащане, вход, регистрация, експорт на данни и интеграции. Тези тестове записват как системата работи днес и стават основата за всяка следваща промяна.
3. Сигурност и версии. Фреймуъркът и зависимостите се обновяват стъпка по стъпка, а тестовете се пускат след всяка стъпка.
4. Подобрения на място. Преработват се частите, които най-много бавят екипа, обикновено тези, които прегледът е отбелязал като заплетени или дублирани.
5. Нови функции. Вече екипът познава кода и новата работа стъпва на тествана основа.

Всеки етап трябва да има писмен обхват и ясен край, за да можете да спрете между етапите, ако бюджетът или приоритетите се променят. Ако планирате бюджет за тази работа, статията колко струва изработката на уеб приложение разглежда същите фактори от страната на оценката.

#Грешки, които да избегнете през първите седмици

• Прибързана оценка на стария екип. Странният код често обработва реален частен случай, специален договор с клиент или грешка в API на партньор. Попитайте защо е написан така, преди да го изтриете.
• Обновяване на всичко наведнъж. Скок през няколко версии на фреймуърка заедно с нов сървър и нов дизайн прави невъзможно да се разбере коя промяна какво е счупила.
• Промени по базата данни без план за миграция. Промените в схемата трябва да са описани в скриптове, да могат да се върнат и да са тествани върху копие на реалните данни.
• Интеграции, които никой не е описал. Опишете всяка външна система, с която продуктът обменя данни, включително уебкуковете, които идват отвън. Те обикновено се чупят тихо. Какво да проверите, ще намерите в статията какво е нужно за надеждна API интеграция.
• Знанието да си отиде втори път. Записвайте наученото още докато го научавате. Предаване без документация прави и следващото предаване също толкова трудно.

#Кога пренаписването е оправдано

Пренаписването излиза скъпо, защото старата система продължава да работи и да се променя, докато се изгражда новата, а всяко правило в стария код трябва да бъде открито наново. Все пак има случаи, в които то е правилният избор:

• Платформата или езикът вече не се поддържат и няма път за обновяване, например версия на фреймуърк, чийто наследник на практика е друг продукт.
• Кодът не може да се изгражда и публикува по повторяем начин, а поправянето на това би струвало почти колкото нов старт.
• Предназначението на продукта се е променило толкова, че повечето текущи функции така или иначе ще отпаднат.
• Моделът на данните е сгрешен из основи и всяка нова функция трябва да го заобикаля.

Дори тогава постепенната подмяна обикновено е по-безопасна от превключване на всичко в един ден. Прехвърляйте към новия код по един раздел от продукта, оставете старата система да обслужва останалото и я изключвайте на части. Потребителите виждат постоянен напредък, а вие можете да спрете във всеки момент с работещ продукт.

#Какво да попитате предишния екип

Ако предишните разработчици са на разположение дори за няколко часа, струва си да платите за времето им. Полезни въпроси:

• Кои части на системата се чупят най-често и какво правите, когато това се случи?
• Има ли cron задачи, опашки или фонови процеси и къде са настроени?
• Какво е променяно директно на сървъра, без да влезе в хранилището?
• Кои функции са недовършени или изключени?
• Кои външни услуги изпращат данни към системата и какво става, когато не работят?

#Как може да помогне PN Scripts

PN Scripts поема съществуващи сайтове и приложения, написани на всякакви технологии. Работата започва с преглед на кода и писмен доклад, след което следва план на етапи вместо пренаписване. Кодът, акаунтите и документацията остават на ваше име през цялото време. Повече за начина ни на работа ще намерите на страницата за уеб разработка по поръчка.