«Совершенство — враг хорошего»
"Оптимизировать позже"
«Все будет хорошо» / «Это достаточно хорошо»
«В полевых условиях этого никогда не случится»
Каждый слышал любую из этих фраз? Я уверен, что у вас есть. Все слышали о них в отношении программного обеспечения? Возможно. Но если речь шла о встроенном или системном программном обеспечении, кто бы это ни говорил, он глубоко ошибался.
Почему? Есть множество причин, по которым встроенное программное обеспечение должно быть (почти) идеальным, но есть несколько простых и очевидных. Это программное обеспечение, которое лежит в основе всего; это нижний уровень в устройствах; все остальное программное обеспечение — логика промежуточного программного обеспечения, базы данных, веб-серверы, пользовательские интерфейсы, все это в конечном итоге зависит от правильной работы нижнего уровня программного обеспечения.
А на верхнем уровне программного обеспечения — и при всем уважении к тем, кто прилагает невероятные усилия, чтобы сделать их правильными — иногда не имеет значения, отсутствуют ли пиксели в пользовательском интерфейсе или это неправильный цвет — это не особенно важно. влияют на работу нижележащего программного обеспечения.
Тестирование — это скучно
Есть грязный секрет программного обеспечения. Многие из них плохо проверены. Часть этого делается в спешке без учета остальной части системы. Тестирование поверхностное или проводится без полного понимания системы. Разработчики находят тестирование скучным или боятся того, что могут найти. QA-инженеры (те, чья работа заключается в тестировании), иногда работают без полных спецификаций или глубокого понимания, которое было у разработчика, когда они это делали (источник вечного разочарования для QA-инженеров).
Так оно и есть. Даже в мире систем/встраиваемых систем это остается верным. Но мы должны быть гораздо более осторожными при создании этого программного обеспечения. Любой промах становится очевидным быстро — по причинам, которые я изложил ранее. И поэтому прилагаются реальные усилия, чтобы сделать все очень и очень хорошо — мы проверяем ошибки везде, даже в том, что «никогда» не произойдет.
Есть много вещей, которые вы можете сделать, чтобы улучшить код заранее. Эти инструменты часто используются, но, к сожалению, не так широко. Многие разработчики никогда о них не слышали или не утруждают себя их запуском. Рассмотрим некоторые из них (это далеко не полный список):
cppcheck
Это анализатор исходного кода. Он может обнаружить логику, стиль и другие проблемы, которые компилятор часто не замечает. Иногда очень тонкие вещи, которые не очевидны на первый взгляд, такие как утечка дескриптора файла или несоответствие с бесплатным/удалением.
предупреждения компилятора
Как и некоторые разработчики, я максимально накрутил предупреждения в GCC (-Wall -Wextra -Werror), и все исправил. Некоторые из них утомительны, но, учитывая, насколько свободными могут быть языки C и C++, это может окупиться в долгосрочной перспективе. Особенно несоответствие знаков.
Вальгринд
Это средство проверки памяти во время выполнения. Это особенно полезно для обнаружения неинициализированной памяти, повреждения памяти и утечек памяти. Это замедляет работу кода при запуске под ним, но такие проблемы может быть чрезвычайно сложно обнаружить вручную.
Эти проблемы с памятью могут быть коварными. Они могут вызывать случайные сбои или просто сбои далеко от того места, где была создана проблема. Неинициализированная память может вызвать случайность там, где она не предполагалась, а утечки памяти — это плохо в долго работающих программах. Так что ценность подобных инструментов должна быть очевидна.
Это никогда не произойдет
В одном случае мне стало ясно, что некоторое устаревшее программное обеспечение было несколько нестабильным и могло зависнуть, а теперь еще и потому, что оно было вызвано недавними улучшениями в программном обеспечении, с которым оно взаимодействовало. Мне было ясно, помимо различных отчетов клиентов, что это будет реальная проблема клиента.
Полная сага длинная и неприятная, но было много возражений даже против того, чтобы исправить это, и неверия, что это вообще произойдет. Конечно, во время одного из моих посещений сайта именно это и произошло. В конце концов, я все-таки исправил ее — и почти 30 других подобных проблем — к сожалению, было уже слишком поздно — вовлеченные заказчик и подрядчик были настолько раздражены, что это стало в значительной степени политической катастрофой.
Вывод
Исправьте встроенное программное обеспечение; не торопитесь. Это не обязательно должно быть идеально, но лучше быть чертовски близким.
