Несмотря на то, что управление программным обеспечением кажется слишком сложным, в некоторых аспектах оно похоже на управление зданиями. Давайте рассмотрим аналогию.
Установка
Допустим, вы являетесь управляющим нового многоэтажного дома в вашем городе. Он совершенно новый, поэтому, естественно, все в идеальном состоянии.
Некоторое время спустя начали появляться первые проблемы, хотя бизнес по-прежнему шел хорошо. Люди по-прежнему платили арендную плату, так что вы продолжали. Вы увидели возможность расширения, и вы это сделали. Вы построили больше этажей поверх старых, потому что в этой аналогии это возможно. Более того, вы продолжали добавлять все больше и больше этажей, в то время как старые части начали рушиться.
Поскольку вы не обращали внимания на состояние первого здания, водопровод начал протекать, так что вы просто склеили все воедино и на этом покончили. Проводка была опасной, хотя нет ничего, что не решило бы достаточное количество изоленты, верно? Промыть и повторить.
Снова перемотайте вперед, и имущество, которым вы управляете, стало больше связано с лентой, чем с чем-либо еще. В этот момент недвижимость стала опасной для проживания, хотя масштабы ремонта ошеломили вас. Получается, что экономить время и деньги на регулярном ремонте не так уж и выгодно.
Опять же, люди все еще жили там, поскольку основная цель была достигнута; была крыша над головой, так что ничего страшного, не так ли? Предполагая, что это будет продолжаться далеко в будущем, вы однажды столкнетесь с выбором: снести все бульдозерами и начать заново или начать кропотливый процесс ремонта? Когда вы начали размышлять, недвижимость превратилась в бомбу замедленного действия; казалось, что он вот-вот рухнет.
Где программное обеспечение вписывается в аналогию?
Ситуация с кодом может быть аналогичной. Поскольку «единственная константа — это изменение», у нас есть два варианта обслуживания программного обеспечения. Ты мог бы:
- Продолжайте добавлять функции в существующий код, пока, в конце концов, все не станет неподдерживаемым.
- Постоянно модифицируйте систему, чтобы обеспечить стабильную основу для текущей и будущей функциональности.
Конечно, говоря в долгосрочной перспективе, гораздо предпочтительнее постоянно модифицировать существующие основы, чтобы не накапливать проблемы со временем — и, возможно, что более важно, сэкономить деньги. В конце концов кодовую базу нужно будет модифицировать, и чем позже это начнется, тем хуже для вас. Начиная с этого момента мы будем использовать глагол «рефакторить» вместо «модифицировать». Рефакторинг — это улучшение внутреннего состояния вашего продукта без изменения того, что он делает.
Большое открытие
Что касается шагов или стадий разработки программного обеспечения, то, что происходит в процессе рефакторинга, не слишком отличается от того, что происходит при написании системы в первый раз. Конечно, помимо этой детали, это огонь и вода. Рефакторинг — это внутренний ремонт без изменения внешнего функционала вместо того, чтобы все снести и построить заново.
Этапы разработки программного обеспечения определяются структурой, которой архитекторы и менеджеры следуют уже около 60 лет (начиная примерно с 1960-х годов).
Эта структура представляет собой жизненный цикл разработки систем (SDLC), который описывает процесс разработки ИТ-систем. Важно отметить, что структура никогда не потеряет актуальности в будущем, так как в конечном итоге все шаги придется повторять.
Весь процесс в целом выглядит так, как показано на изображении выше, хотя, естественно, есть и исключения. Каждый должен основывать процесс на индивидуальном анализе. Например, может случиться так, что менеджеры захотят изменить структуру, чтобы она лучше подходила им.
Если вы уже знакомы с SDLC, можете пропустить следующий раздел.
Анализ и планирование
Именно здесь команда будет собирать информацию о системе и планировать, как должна проходить вся операция. При решении конкретной проблемы важен и более широкий контекст; более широкий набор целей организации имеет значение при подходе к проблеме.
Затем мы можем начать определять цели нашей операции и планировать, как именно мы их достигнем. Кроме того, полезно привлекать реальных пользователей (или потенциальных пользователей), чтобы иметь возможность уточнить определение проблемы и то, как мы можем ее исправить.
Дизайн
Этот этап посвящен составлению согласованного решения. Сначала команда составляет общий план, а затем переходит к детальному планированию.
На этапе проектирования все необходимые и актуальные проектные документы попадают в руки клиента. Документы, которые мы получаем, настолько подробно описывают систему, что у разработчиков программного обеспечения и инженеров не должно возникнуть проблем с разработкой продукта.
Разработка
Это «сочная» часть. Только на третьем этапе происходит фактическое кодирование. Мы хотим не быть Всадником без головы.
Интеграция и тестирование
На этом этапе мы демонстрируем, что то, что мы создали, действительно соответствует требованиям и целям, которые мы установили заранее.
Развертывание (реализация)
Мы почти готовы идти. Однако теперь самое сложное. Нам нужно развернуть наше творение, шаг за шагом, попутно проверяя, все ли работает как положено. Если все предыдущие шаги выполнены тщательно и правильно, это должно быть на одном дыхании. Конечно, жизнь есть жизнь, и в редких случаях все идет не так, как должно.
Обслуживание
Последний шаг. Нам нужно определить задачи, которые должны быть выполнены, чтобы у нас была здоровая кодовая база.
Конечно, этап обслуживания часто является самым продолжительным. Этот этап длится до тех пор, пока мы не решим добавить новые функции или функции или изменить существующие. Если мы хотим что-то добавить/изменить, мы повторяем весь цикл заново.
Здесь мы удостоверяемся, что у нас есть прочная основа для текущих и будущих функций.
Уродливая правда
Переписывание неправильно управляемого программного обеспечения не только поднимает планку сложности само по себе; у вас также может не быть надлежащей документации или даже не с кем поговорить об изменениях, которые были реализованы в прошлом.
Ваш боевой дух или боевой дух всей команды может упасть. Несмотря на то, что команда усердно работает, бизнес-преимущества часто можно увидеть только через несколько месяцев или даже лет. Это не так, как если бы мы мгновенно модернизировали старый Fiat до нового Mercedes-Benz.
Несмотря на то, что это так, возможно, это разочаровывает, возможный рефакторинг является необходимостью. Код нужно обновлять и поддерживать, как машину. Если одна бригада годами не смазывает машину, другой бригаде придется выполнять необходимый ремонт после того, как машина начнет ломаться все чаще и чаще, превратившись в бомбу замедленного действия.
Спасательная партия
Спасательная команда также не может быть группой «случайных» разработчиков. Они должны быть лучшими из лучших, с редким увлечением старыми частями языков программирования и платформами разработки. Конечно, код, который они пишут, использует все новейшие приемы и фреймворки, хотя это только часть их работы. В конце концов, они в первую очередь ныряют с головой в горящую тарелку со старыми спагетти-кодами.
Менеджеры, которым поручено организовать работу каждого, должны всегда быть в курсе всего. Во-первых, изменения, которые были бы правильными с точки зрения искусства программирования, не всегда хорошо вносить. В конце концов, клиент ждет, что мы предоставим что-то, что повысит ценность его решения, а не сделает кодовую базу «косметически» правильной.
Долго и счастливо
Когда рефакторинг готов, наступает момент истины. При развертывании проблем возникнуть не должно, однако, естественно, некоторые возникают. Время от времени отсутствуют файлы, могут возникнуть проблемы с установкой правильных переменных среды (в целях настройки); могут быть проблемы с управлением версиями, например перезапись файла, когда это не должно было быть сделано, и наоборот, и так далее.
Еще одна трудность заключается в том, что иногда приходится запускать в производство руками разработчика из-за рубежа — например, в случаях, когда присутствуют ограничения доступа из-за конфиденциальных или конфиденциальных данных. Не совсем проблема, хотя иногда это может быть проблемой. Возникают недопонимания между зарубежной командой и инженером в компании. Иногда они могут поставить под угрозу всю операцию.
Магдалена Левандовска, с которой я разговаривал, чтобы получить представление о процессе, в этом году участвовала в масштабном проекте по рефакторингу. Поскольку год подходит к концу, она и ее команда могут гордиться: им удалось завершить его с полным успехом.
Первоначально опубликовано на https://www.itmagination.com.
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку. Получите эксклюзивный доступ к возможностям письма и советам в нашем сообществе Discord.
