Обновление программного обеспечения — это процесс улучшения сломанных, плохо работающих и нефункционирующих частей программной системы.
Основное различие между обновлением и реконструкцией заключается в возможности частично перестраивать части программного обеспечения, сохраняя при этом другие части без модификаций; для этого требуется создать несколько уровней защиты от коррупции, чтобы обеспечить интеграцию между недавно отремонтированными частями и устаревшими частями.
В ходе обновления ожидается, что ранее написанные юнит-тесты станут недействительными, и потребуется их переписывание.
Поскольку обновление обычно звучит привлекательно, особенно после того, как разработка программного обеспечения передается от одной команды к другой, руководство редко оправдывает его. В большинстве случаев инженеры, которые просят о ремонте, не могут дать убедительного ответа, когда их спрашивают о рентабельности инвестиций с точки зрения ценности для бизнеса.
В этой статье мы обсудим систематическую методологию обновления программного обеспечения.
1- Определить
Перед началом любого процесса улучшения необходимо определить цели улучшения.
Целями обновления программного обеспечения должны быть главным образом нефункциональные требования.
1- Выбранные цели должны соответствовать целям организации.
2. Выбранные цели должны быть направлены на решение очевидной проблемы или задачи.
3- На данный момент вы не можете предоставить какие-либо подробности о том, как вы будете решать эту проблему.
4- На данный момент вы не можете предоставить какие-либо количественные измерения улучшения.
5. Основная проблема заключается в том, почему вы хотите это улучшить.
2- Измерьте и определите
Этот этап требует более глубокого изучения текущей кодовой базы, чтобы найти основные причины, которые привели к ранее выявленной проблеме. В основном речь идет об идентификации модулей или операций, которые сильно влияют на проблему.
Например, если обновляемая система представляет собой систему управления контентом, цель состоит в повышении производительности. Ожидаемый результат анализа примерно такой.
Накладные расходы действительно оцениваются по кодовой базе, опыт инженера-программиста является важным фактором точности.
Столбец комментариев имеет решающее значение для уменьшения количества заливов и ошибочных суждений; следовательно, он должен быть
- Указывая пальцем на код или технологию, но не на людей, во многих случаях проблема создается неквалифицированным инженером, который был частью команды. Впрочем, это может быть фактом, но упоминание о том, что это никоим образом не поддерживает процесс реновации; нас интересует то, что они сделали, а не почему они это сделали.
- Он должен оправдывать накладные расходы; Он используется для ответа на вопрос, почему, по вашему мнению, у нас есть такая сумма накладных расходов.
- Если возможно, он должен поддерживаться тестом; когда выяснится, что проблема связана с библиотекой, определенным шаблоном или архитектурным стилем, по возможности постарайтесь изолировать ее в проекте сравнительного анализа (чистом проекте, содержащем фрагмент кода для проверки). сравнивались друг с другом) для .net проектов рекомендуется использовать https://benchmarkdotnet.org/articles/overview.htm
Его должен проверить другой член команды; легко допустить множество ошибок, например провести несправедливый бенчмаркинг.
3- Расставьте приоритеты и оцените
Результатом предыдущей фазы является набор компонентов, которые необходимо обновить; наиболее вероятно, что будут совпадения между компонентами, определенными для каждой цели. Компоненты с более высоким перекрытием должны быть приоритетными для обновления.
Очень важно оценить усилия, необходимые для изменения этих компонентов, и риск.
4- Запрос на инициацию проекта
Прежде чем приступить к какой-либо реализации, важно согласовать ее с руководством организации и инициировать проект реконструкции.
Запрос на запуск проекта должен включать:
— Цели проекта (этап 1)
— Объем проекта (этап 3)
— Ожидаемые результаты проекта (этап 2)
— Расчетное время и бюджет проекта (Этап 3)
5- Варианты дизайна
Эта фаза очень важна; самая распространенная ошибка, которая здесь происходит, заключается в том, что инженеры сразу начинают перереализовывать компонент. Основано на их вере в то, что то, что они реализуют, лучше, чем то, что обычно создавалось под влиянием инженерного опыта или новых модных технологий, быстро развивающихся в настоящее время. Эта ошибка очень дорого обходится в долгосрочной и даже средней перспективе. Программное обеспечение закончится в той же ситуации, в которой оно находится сейчас, или даже в худшем.
5.1- Обязанности компонента Спецификация
Первый шаг — определить, какие функции предоставляет текущий компонент и к какому компоненту вычислений он относится (обработка, хранение, связь).
Регистрация пользователей — это компонент, который проверяет данные пользователей (обработка) и сохраняет их в базе данных (хранилище).
5.2- Разбивка компонентов
После определения обязанностей и ответственности компонентов новый компонент соблюдает принцип единой ответственности, что означает, что каждая обязанность должна выполняться его модулем или подкомпонентом.
— Граница между подкомпонентами должна быть четкой
— Связь между подкомпонентами не должна включать в себя зависимости между ними (использование контрактов или неявный вызов).
5.3- Компромисс
Для каждого подкомпонента должно быть предложено более одной реализации, а затем необходимо найти компромисс, чтобы выбрать одну из них.
Распространенной ошибкой является придерживаться одной реализации, предложенной инженером, но как убедиться, что она лучше всего подходит, может быть, есть лучшая, которую мы не знаем.
6- Реализовать
Эта фаза очень проста; наиболее важным является обеспечение того, чтобы реализация соответствовала дизайну. Если блокировщик препятствует реализации проекта, необходимо подать запрос на изменение дизайна.
7- Проверить
Проверка должна происходить после внедрения каждого компонента, чтобы убедиться, что программное обеспечение по-прежнему работает правильно и движется к цели.
Если программное обеспечение становится нестабильным или метрики движутся в неправильном направлении, необходимо принять немедленные меры для выяснения причины и оценки ситуации.
Запланируйте сеанс DDIChat в разделе Кодирование, программное обеспечение и разработка мобильных устройств:
Подайте заявку на участие в программе DDIChat Expert здесь.
Работайте с DDI: https://datadriveninvestor.com/collaborate
Подпишитесь на DDIntel здесь.
