Введение В настоящее время широко известен принципы написания программного кода (стандарты кодирования), упрощающие его поддержку и разработку.
Эти принципы используются многими компаниями-разработчиками программного обеспечения, а также инструментами разработки и статический анализ кода Для этого они предлагают различные средства автоматизации.
В то же время инженерные задачи в программировании явно требуют расширения понятия «хороший код».
Мы попробуем вступить в дискуссию о «хорошем» инженерном коде на, казалось бы, очень конкретном примере — через практику использования постоянных параметров в алгоритмах.
Хочется сразу отметить, что данная статья ставит перед собой задачу повысить самоконтроль разработчика, особенно начинающего свою карьеру.
Все приведенные ниже примеры следует рассматривать как модельные ситуации, без ссылки на какую-либо конкретную вычислительную задачу или какой-либо конкретный алгоритм.
Можно сказать, что наша цель — сформулировать некоторые шаблоны хорошего инженерного/алгоритмического программирования.
Давайте подумаем, не режет ли нам этот код глаза:
Лично меня это очень ранит. Во-первых, совершенно непонятно, что такое 150,7? Вполне возможно, что 150,7 — это прецизионное значение резистора, которое варьируется от одного устройства к другому и фактически должно быть считано из файла калибровки.if (abs(leftVoltage - rightVoltage - 150.7 * balanceCurrent) > 0.002) doSomethingImportant();
Что такое 0,002? Судя по всему, это некий экспериментальный порог, который может быть уточнен позже, хотя конкретных комментариев по этому поводу нет.
Первая кровь
Представим себе младшего программиста Алешу, которому предложили автоматизировать контроль качества заклепок для космических кораблей компании «Обитаемая Галактика».Эти заклепки сходят с конвейера и фотографируются цифровой камерой.
Алеше нужно написать код, который анализирует фотографии этих заклепок и принимает решение о том, соответствует или не соответствует форма заклепки своему стандарту.
Предположим, что Алеша, к удовлетворению своего начальства, быстро реализовал некий алгоритм оценки заклепок.
Этот алгоритм прекрасно отделил изображения плохих и хороших заклепок из тестового набора, проблема была решена и Алешу переключили на другой проект. Затем произошло следующее.
Заклепок стало еще несколько, скорость конвейера увеличилась и инженер Боря немного укоротил выдержку камеры.
При этом изображение, поступающее с камеры, стало несколько темнее, хотя заклёпки всё равно были хорошо видны.
При этом алгоритм Алешина иногда начинал ошибочно отклонять качественные заклепки.
Что случилось?
Позволять 
это входное монохромное изображение размера 
с координатами 
И 
.
Алеша заметил, что заклепки скрипят. 
во всех обучающих изображениях можно было найти с помощью пороговой фильтрации: 
При этом качественная заклепка 
можно найти по площади: 
Всего Алеша ввёл 4 эмпирические константы 
, 
, 
И 
, хотя бы один из которых (
) потерял актуальность после перенастройки камеры.
Набравшись небольшого опыта, Алеша смог сделать следующее: перенести значения необходимых констант в конфигурационный файл и дополнить конструкторскую документацию методикой их практического расчета.
Это было бы лучше, чем просто прятать эти значения внутри своего кода, но дало бы коллегам Алеши дополнительную задачу по ручной настройке его алгоритма.
Конечно, такое решение вряд ли можно назвать удовлетворительным, хотя в особо сложных ситуациях оно имеет право на существование.
Какое решение было бы более разумным? Параметры полосовых фильтров по яркости и площади можно было преобразовать в относительные значения к средней яркости и площади изображения.
Например,
может быть заменен на 
, Где 
- тоже эмпирическое, но более инвариантное значение.
Попробуем угадать, что произошло дальше на заводе космических кораблей.
Поскольку качество отбраковки клепок было недостаточным, главный технолог Виталий, далекий от тонкостей программирования, решил срочно установить на оценочный стенд более дорогую камеру с высокой чувствительностью и вдвое большим разрешением.
Логический результат такой командной работы — 100% отбраковка, так как все заклепки стали в два раза больше по количеству пикселей и ни одна из них не прошла полосовой фильтр.
Возможно, грамотный управление проектом , но мы сейчас не об этом.
Нормализация входных данных
Многих проблем с подбором констант можно избежать, приведя входные данные к единообразному виду.Изображения - к одной форме гистограммы, 3D-модели - к одному разрешению и т. д. Против нормализации часто выдвигают аргумент, что она приводит к потере части исходной информации.
Это действительно так, но упрощение дальнейшей работы с параметрами алгоритма часто перевешивает этот минус.
Сама постановка задачи максимальной нормализации входных данных позволяет разработчику задуматься, что будет, если изображения придут с поворотом на 90 градусов? Что, если размеры указаны в дюймах? Что, если кто-то предоставит 3D-модель высокого разрешения, передающую тонкую текстуру материала? Отличным примером, когда нормализацию, однако, делать не нужно, является поиск переэкспонированных пикселей (бликов) на фотографиях.
Пиксели с максимальной яркостью RGB (255, 255, 255) могут образовывать тонкие полосы, которые при масштабировании изображения слегка размываются.
В этом случае яркость освещенных пикселей усредняется с соседними пикселями и отличить их от просто ярких точек изображения становится практически невозможно.
Соответственно, невозможно будет точно идентифицировать и резать основные моменты изображения.
Калибровочные константы
При обработке данных достаточно низкого уровня возникает классическая проблема калибровки.Это может быть преобразование напряжения на каком-нибудь термисторе в температуру или преобразование отклика радара в координаты наблюдаемого объекта.
Все эти преобразования так или иначе определяются набором постоянных параметров, и процедура определения этих параметров называется калибровкой.
Параметры калибровки обычно поступают из внешних источников.
Жёстко закодировать эти параметры — страшный грех.
Если такой код не будет немедленно отсеян код-ревью, то он может надолго испортить поведение программного продукта в целом, оставаясь при этом вне подозрений.
Система просто не будет работать совсем точно, но вряд ли где-либо выскочит сообщение об ошибке.
Однако для полноты картины следует отметить, что в некоторых задачах возможна автокалибровка, когда внутренние зависимости наблюдаемых величин позволяют рассчитать и параметры калибровки.
См.
, например, последние главы.
Многопрофильная геометрия или работать над Некалиброванная структура из движения , где параметры калибровки камер определяются по набору перекрывающихся изображений под разными углами.
Основные пометки
Дайте константам осмысленные имена и закомментируйте их значения.Помните, что это очень хрупкий фрагмент кода, который не защищен типизацией языка или компилятором.
Группируйте параметры алгоритма в структуры.
Обычно это улучшает читаемость кода и не дает вам пропустить какой-либо важный параметр во время отладки.
Если вы знаете, что один параметр выражается через другие, обязательно отразите эту связь в коде.
В противном случае кто-то из лучших побуждений изменит ваши неоптимальные, но последовательные параметры на противоречивые.
Например, вы ищете на изображении круги радиусом 
= 10 и площадь 
= 314. Это плохо, потому что по сути параметр у вас один — радиус
= 10, а 
.
Код с двумя параметрами легко взломает программист, забывший школьную математику, но код с одним параметром выглядит гораздо надежнее.
Бывает, что в алгоритм входит какая-то неэмпирическая константа.
Например, вам нужно оценить хвост некоторого распределения.
Точность такой оценки во многом определяется математической подготовкой автора алгоритма.
Константы оценки иногда можно улучшить, но такое улучшение обычно представляет собой изолированную задачу.
Важно прокомментировать этот факт для других разработчиков.
Краткое содержание
«Мпирические константы — естественная часть алгоритмического кода, которая, однако, требует пристального внимания со стороны разработчика.Перечислим еще раз правила работы с константами, о которых мы говорили выше:
- Константы имеют осмысленные имена
- Значения констант определяются перед логическим блоком, в котором они используются.
- Большие блоки констант организованы в структуры/классы параметров.
- Функционально зависимые параметры рассчитываются через базовые параметры.
- Входные данные нормализованы
- Константы калибровки явно загружаются из файлов конфигурации, в противном случае возвращается сообщение об ошибке.
Если все типы параметров введены правильно, то построение процедуры оптимизации существенно упрощается: калибровочные константы и константы оценки не оптимизируются, а оптимизируются только эмпирические параметры.
Я надеюсь, что эта простота послужит вам одним из практических критериев качества инженерного кода.
Теги: #стиль кода #алгоритмы #Идеальный код #Алгоритмы #математика
-
Мобильные Телефоны Станут Частью Ms Office
19 Oct, 24 -
Гран Парадизо Взлетает
19 Oct, 24 -
Плохой Сон == Хорошая Работа?
19 Oct, 24
