8 вещей, которым я научился, работая над огромной устаревшей кодовой базой

Моя первая работа разработчика привела меня к огромной устаревшей кодовой базе. Мой последний большой билет заключался в том, чтобы заставить современную библиотеку работать с устаревшей структурой пользовательского интерфейса, которую она использует. После этого путешествия я хотел бы поделиться некоторыми советами, которые я узнал на этом пути.

(1) Изучайте кодовую базу, исправляя ошибки.

[ ] (https://res.cloudinary.com/practicaldev/image/fetch/s--yTQL8rSf--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://c.tenor.com/8Tr3SyO82lkAAAAM/bug-eating. гиф)

В идеале у вашей компании должна быть хорошая документация, но часто унаследованные кодовые базы — это те, которые раньше поддерживал один разработчик, который ушел. Чтение всей кодовой базы, чтобы ускориться, может быть почти невозможным. Я обнаружил, что исправление ошибок — отличный способ узнать «индивидуальность» вашего приложения, а также лучше ознакомиться с его рабочими процессами. Даже простое чтение тикетов невыполненной работы дает вам представление о приоритетах компании, сокращениях и о том, что пользователи хотят исправить.

(2) Учебные пособия и справочные материалы может быть трудно найти.

Это особенно верно, если какой-либо из пакетов, библиотек или инструментов в кодовой базе устарел. Ознакомьтесь с версиями того, что вы установили. Включите версию в свой Google. Даже если вы можете найти учебные пособия, ваше приложение может быть написано с использованием другого шаблона проектирования. Кроме того, многие учебные пособия ведут себя так, как будто приложение построено вокруг инструмента, который они демонстрируют. Заставить что-то работать внутри установленного, самоуверенного приложения — это совершенно новая игра. Не бойтесь пробовать буквально любую идею, которая приходит вам в голову.

(3) Вы можете положиться на людей, у которых больше опыта работы с приложением.

Это касается не только других разработчиков. Контроль качества, наука о данных и менеджеры проектов, которые годами работали над приложением, будут знать вещи, которые вам очень помогут. Когда я застреваю, пытаясь найти, откуда берется ошибка, я часто спрашиваю их: «Есть ли рабочий процесс, который может повлиять на это, который я упускаю?» Иногда знание того, как была реализована функция, даст вам представление о том, почему ошибка начала появляться только сейчас, о ней только что сообщили или ее исправление не является приоритетным.

(4) Всегда проверяйте, не решил ли кто-нибудь проблему ранее, прежде чем писать совершенно новый способ ее решения.

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

(5) Старайтесь никогда не дублировать код.

Ознакомьтесь с утилитами вашей кодовой базы и методами импорта, чтобы вы могли использовать уже написанный код в любом месте кодовой базы. Не нужно добавлять сложности или менять что-то в нескольких местах. Унаследованная кодовая база, над которой уже работало множество разработчиков, вероятно, имеет более одного примера того и другого. Кроме того, они могли знать о причуде системы, которой не знаете вы.

(6) С другой стороны, множество утилит означает много абстракции.

[ ![Чайка и краб обсуждают загадочное путешествие краба в маленькой весельной лодке, заканчивая фразой «любые подробности останутся тайной».

Источник. https://res.cloudinary.com/practicaldev/image/fetch/s--8PozYIzq--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i /88u7xuipr0mj1kxlwkn5.png)

Функции, которые полагаются на установленные утилиты, могут стать очень плотными для чтения от начала до конца. Это нормально, если вы понимаете, что делает утилита, только на высоком уровне. Если вам когда-нибудь понадобится реализовать его в другом месте или что-то в нем пошло не так, самое время углубиться в то, как это работает.

(7) Если у вас нет ответа, как бы вы это улучшили, не жалуйтесь на это.

Вы не знаете временных ограничений, в которых находился разработчик, или того, было ли им сказано идти в направлении, с которым они лично не были согласны. Если у вас есть ответ, обсудите со своей командой, является ли это приоритетом, которому вы можете посвятить время. Если это небольшой билет или что-то, что вы можете разбить на маленькие билеты, вы можете использовать эти увлеченные проекты в качестве награды за устранение ошибок, которые действительно бросали вам вызов или не бросали вам вызов вообще.

(8) "Давайте ограничим масштаб этого." Ваш новый девиз.

Вы хотите попытаться повлиять на как можно меньше рабочих процессов. Унаследованная кодовая база обычно довольно стабильна, и люди рассчитывают, что она будет работать. Радикальные реформы заманчивы, но часто ваша задача состоит в том, чтобы просто залатать маленькие дыры.