Ремонтопригодность — наиболее важная ценность любого развивающегося программного продукта. Ремонтопригодность измеряется в рабочем времени, необходимом новому подрядчику для изучения продукта до того, как он начнет вносить в него существенные изменения. Чем больше времени на это тратится, тем ниже ремонтопригодность. В некоторых проектах это время стремится к бесконечности, что означает абсолютно непригодный к какой-либо поддержке или внесению изменений продукт. Мы верим, что есть 7 фатальных ошибок, которые ведут к созданию таких неподдерживаемых продуктов. Вот они.
Антипаттерны
К сожалению, все современные программные языки обладают слишком большой гибкостью. Они слишком много позволяют и слишком мало запрещают.
Например, Java не имеет ничего против того, чтобы вы вместили целое приложение в один единственный «class» с помощью 5000 разных методов. Технически приложение компилируется и запускается, но это хорошо всем известный антипаттерн, который называется Божественным объектом.
Таким образом, антипаттерн — это технически допустимый способ разработки, общеизвестный и ошибочный. В каждом языке уйма таких антипаттернов; их присутствие в продукте аналогично наличию опухоли в живом организме. Как только он начинает разрастаться, остановить его уже невозможно. В конечном итоге погибает целый организм. Целый программный продукт становится неремонтопригодным и должен быть переписан.
Как только вы допустили один антипаттерн, их сразу становится больше и больше, и эта «опухоль» только растет.
Это утверждение особенно правдиво для
Всегда старайтесь относиться с достаточной долей скептицизма к своему проекту и не расслабляйтесь, если он «просто работает». Чем раньше вы диагностируете проблему, тем проще ее вылечить.
Неотслеживаемые изменения
При работе с любым программным продуктом вы должны в любой момент быть в состоянии объяснить, что было изменено, кто это сделал и почему. Более того, время, требуемое для того, чтобы получить ответы на эти вопросы, должно измеряться в секундах. Для большинства проектов это не так. Приведем несколько практических рекомендаций:
Всегда используйте тикеты. Неважно, насколько мал проект или команда, которая его обслуживает — даже если вы работаете над ним в гордом одиночестве, всегда используйте тикеты для любой возникающей проблемы. Объясните в двух словах суть проблемы, зафиксируйте свои предположения. Используйте
Ссылайтесь на тикеты в коммитах. Нет необходимости поучать, что каждый коммит должен сопровождаться сообщением. Коммиты без сообщений достаточно противная штука; тем не менее, просто сообщения недостаточно. Каждое сообщение должно начинаться с номера тикета, над которым вы работаете. Многие
Ничего не удаляйте. Некоторые
Ad Hoc релизы
Перед доставкой к конечному пользователю каждый программный продукт должен быть упакован. Если это библиотека Java, она должна быть заключена в файл.jar и распаковываться в
Идеальное решение — автоматизировать эту процедуру, чтобы было возможным выполнять ее с командной строки посредством одной команды:
Многие проекты далеки от этого. Процессы их релиза — это всегда
Здесь может быть только один совет: автоматизируйте процесс.
Волонтерский статический анализ
Статический анализ — это то, что «причесывает» код. Делая его лучше внешне, мы обеспечиваем его лучшую работу. Однако так происходит только тогда, когда вся команда должна выполнять правила, продиктованные статическим анализатором кода.
Обязательно используйте анализатор кода. В большинстве проектов, где используется анализатор кода, разработчики просто делают на его основе красивый отчет и продолжать писать код дальше — так же, как и делали это раньше. Такой «волонтерский» подход к статическому анализу не делает чести программному проекту. Более того, он просто создает иллюзию хорошего качества.
Статический анализ должен быть обязательным этапом в конвейере разработки продукта, и его правила не должны игнорироваться.
Неизвестное тестовое покрытие
Тестовое покрытие — это степень, в которой ПО прошло интеграционное тестирование. Чем больше покрытие, тем больший объем кода был выполнен во время тестирования. Очевидно, что высокое покрытие — хорошая штука.
Тем не менее, многие разработчики не знаю, каково их покрытие: они просто не измеряют этот показатель. Возможно, они и проводят
Конечно, высокое покрытие — не гарантия высокого качества. Но неизвестное покрытие — это четкий индикатор проблем с функциональной надежностью продукта. Когда проект попадет в руки нового разработчика, он или она должны иметь возможность внести
Непрерывная разработка
Под непрерывной здесь подразумевается разработка без временных рамок и релизов. Неважно, ПО какого типа вы создаете, вы должны часто делать релизы и изменять его. Проект без четкой истории релизов — это просто неподдерживаемая программная неразбериха. Все это потому, что возможность поддержки продукта — это если, например, мы будем в состоянии понять вас, читая ваш код.
Просматривая исходный код и историю его релизов, каждый должен быть в состоянии определить намерения его разработчика, скажем, год назад, что происходит сейчас, дальнейшие перспективы
Некоторые
Недокументированные интерфейсы
Каждый участок ПО имеет свой интерфейс, через который предполагается его использовать. Если это
Как и все сказанное выше, этот факт относится к возможности поддерживать продукт. Любой новый программист начинает изучение проекта с его интерфейсов, и любой должен понимать, для чего нужен тот или иной интерфейс и как его использовать.
Мы здесь говорим о документировании для пользователя, а не для разработчика. В общем и целом, мы против документации внутри ПО: работающее ПО гораздо лучше, чем понятная документация к нему. Но это не относится к «внешней» документации, которая предполагается для использования пользователями.
Взаимодействие конечного пользователя с ПО должно быть документировано в обязательном порядке. Если ваша программа — это библиотека, то ее конечные пользователи — разработчики, которые не развивают продукт, а просто используют его как «черный ящик».
Все эти критерии используются для проектов с открытым исходным кодом.
