Библиотека сайта rus-linux.net
ITK
Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 2.Оригинал: ITK
Авторы: Luis Ibanez, Brad King
Перевод: А.Панин
Знать, когда остановиться
Также существует риск того, что при разработке будет "сделано очень много хороших вещей", подразумевающий риск чрезмерного использования шаблонов или чрезмерного использования макросов. Достаточно просто зайти слишком далеко и в итоге создать новый языка программирования на основе C++, реализованный с помощью шаблонов и макросов. Это тонкая грань, которая требует постоянного внимания со стороны команды разработчиков для уверенности в том, что возможности языка программирования используются должным образом без злоупотреблений.
В качестве конкретного примера можно привести широко используемую схему явного именования типов с помощью оператора typedef С++, которая оказалась достаточно важной. Эта практика позволяет выполнить две задачи: с одной стороны, она позволяет использовать понятные для человека и информативные имена, описывающие характер и назначение типа; с другой стороны, она позволяет быть уверенным в том, что тип используется последовательно в рамках тулкита. В качестве примера следует упомянуть о том, что в ходе рефакторинга тулкита при подготовке версии 4.0 были приложены большие усилия для того, чтобы установить случаи использования таких целочисленных типов C++, как int, unsigned int, long и unsigned long и заменить их на типы, названные в соответствии с надлежащими концепциями, связанными с представляемыми переменными данными. Эта часть работы, направленной на предоставление возможности использования 64-битных типов для обработки изображений объемом более четырех гигабайт на всех платформах, была наиболее сложной. Данная задача имела крайне важное значение для последующего использования ITK в области микроскопии и дистанционного зондирования, где изображения объемом в десятки гигабайт встречаются достаточно часто.
Возможность поддержки кода
- Модульность (на уровне классов)
- Большое количество файлов небольших размеров
- Повторное использование кода
- Повторное использование шаблонов
- Модульность (на уровне классов) позволяет применять техники разработки через тестирование на уровне фильтров изображения или в общем на уровне классов ITK. Строгая дисциплина тестирования, применяемая к небольшим и модульным фрагментам кода, позволяет воспользоваться полезной возможностью сокращения количества фрагментов кода, в которых могут быть скрыты ошибки, а также естественным результатом разделения кода на модули является упрощение поиска и устранения дефектов.
- Большое количество файлов небольших размеров позволяет упростить выделение фрагментов кода для работы над ними определенных разработчиков и упростить отслеживание дефектов в том случае, если они ассоциированы с определенными коммитами в системе контроля версий. Дисциплина работы с файлами небольшого размера также ведет к применению золотого правила функций и классов: выполнять одну задачу и выполнять ее правильно.
- Повторное использование кода: При повторном использовании кода (вместо копирования и вставки или повторной реализации) качество кода увеличивается ввиду повышения уровня его исследования, что происходит из-за его применения в различных обстоятельствах. Это обстоятельство позволяет рассмотреть код большим количеством глаз или, по крайней мере, получить эффект и, соответственно, преимущества, описанные законом Линуса (Linus's Law): "При достаточном количестве глаз все ошибки лежат на поверхности".
- Повторное использование шаблонов упрощает работу мэйнтейнеров, трудозатраты которых на самом деле составляют более 75% трудозатрат, вложенных в разработку проекта в течение всего периода его существования. Использование шаблонов проектирования, которые постоянно повторяются в различных местах кода, значительно упрощает понимание разработчиком того, что код делает или должен делать сразу же после открытия файла.
- Предположения о том, что некоторые фильтры принимают определенные типы пикселей входных и выходных изображений, но не устанавливают их с помощью проверок типов и концептуальных проверок, а также эти типы не описаны в документации.
- Разработка кода, не являющегося удобным для чтения. Это одна из наиболее часто встречающихся сложностей в рамках любого программного обеспечения, новые реализации алгоритмов которого появляются в сообществе исследователей. Часто разработчики реализуют код, который "просто работает" и забывают о том, что задачей кода является не только исполнение в ходе работы приложения, но и возможность его простого чтения следующим разработчиком. Стандартные хорошие правила разработки "чистого кода" - например, разработка небольших функций, которые выполняют одну задачу и только одну задачу (принцип единой ответственности (Single Responsibility Principle) и принцип наименьшей неожиданности (Principle of Least Surprise)) наряду с корректным именованием переменных и функций - обычно игнорируются тогда, когда исследователи вдохновлены реализацией своего нового великолепного алгоритма.
- Игнорирование случаев неудачного завершения задач и обработки ошибок. Стандартной практикой является приоритетное рассмотрение "счастливых случаев" в процессе обработки данных и отсутствие кода для обработки всех случаев, в которых процесс работы приложений может протекать некорректно. Пользователи тулкита довольно быстро сталкиваются с такими случаями сразу же после того, как они начинают разработку и развертывание приложений в реальных условиях.
- Недостаточное тестирование. Требуется большое количество дисциплинарных мероприятий для того, чтобы следовать практике разработки через тестирование, особенно при приоритетной разработке тестов и реализации функций только после того, как они будут протестированы. Практически всегда ошибки в коде встречаются в тех местах, которые были пропущены при реализации кода тестирования.
Благодаря практикам взаимодействия сообществ разработчиков приложений с открытым исходным кодом, многие из этих ошибок в конце концов обнаруживаются с помощью вопросов, обычно задаваемых в списках рассылки или в отправляемых напрямую пользователями сообщениях об ошибках. После рассмотрения множества подобных случаев разработчики учатся писать код, который "подходит для сопровождения". Некоторые из свойств этого кода относятся и к стилю оформления кода, и к самой организации кода. На наш взгляд, разработчик достигает мастерства только после некоторого времени работы - хотя бы года - по сопровождению кода и рассмотрения "всех случаев, в которых код может работать некорректно".
Продолжение статьи: Невидимая рука