Публикации на тему встроенных систем

[Dale]

Martin Croxford, Dr. Roderick Chapman.

Correctness by Construction: A Manifesto for High-Integrity Software.

URL: http://elsmar.com/pdf_files/A%20Manifesto%20for%20High-Integrity%20Software.pdf

В предыдущей аннотации упоминалась фирма Altran Praxis, прославившаяся качеством своих программных продуктов. Теперь желающие могут обратиться непосредственно к первоисточнику, поскольку данная статья написана самими сотрудниками Praxis.

Всем знакома банальная житейская истина (хотя далеко не все руководствуются ей на практике): болезнь проще предотвратить профилактическими средствами, чем лечить, когда она уже в разгаре. Аналогичные принципы существуют и для программного обеспечения. Один из них, названный Correctness By Construction (или просто CbyC), гласит: проще обеспечить корректность продукта, управляя самим способом его создания, нежели потом, после создания, находить аномалии в его поведении и исправлять их.

В основе CbyC лежат шесть фундаментальных принципов. Следовать им, конечно, не элементарно просто (иначе кризиса программного обеспечения не существовало бы в принципе), но в то же время в них нет ничего нереально сложного. Теоретически любая команда разработчиков могла бы ими воспользоваться, пожертвовав на это некоторые усилия и время.

Статья далека от абстрактных умствований. Напротив, все рекомендации в ней предельно точны и конкретны. В частности, авторы анализируют препятствия, встающие на пути внедрения CbyC в практику, и дают рекомендации по их преодолению для тех, кто твердо вознамерился усовершенствовать свои процессы разработки.

Статья полезна разработчикам ответственных приложений.

[Dale]

Jack Ganssle.

A Guide to Approximations (URL: http://www.ganssle.com/approx/approx.pdf)
Approximations, part 2 (URL: http://www.ganssle.com/approx/approx-2.pdf)

В процессе разработки встроенного ПО может возникнуть потребность в использовании различных элементарных функций (синусы/косинусы, логарифмы и т.п.). Конечно, можно, особо не заморачиваясь, воспользоваться той же стандартной библиотекой С, в которой все эти функции есть. Однако не всегда это оказывается рациональным.

Стандартные функции, как правило, реализуются с максимально возможной точностью, которую может обеспечить тип double. Однако эта точность может оказаться избыточной для встроенных приложений, когда сами исходные данные имеют невысокую точность (например, совершенно бессмысленно обрабатывать с точностью 15 десятичных знаков данные, полученные с 10-битного АЦП, встроенного в микроконтроллер). В то же время эта ненужная точность может доставаться слишком высокой ценой: выполнение операций над 64-разрядными значениями на 8-битном ядре без аппаратной поддержки длится весьма долго по меркам систем реального времени.

В предложенных статьях предлагается компромиссное решение: разработчик сам выбирает реализацию элементарных функций с требуемой ему точностью (выбирая соответствующее число членов ряда разложения), не переплачивая драгоценными ресурсами за избыточность. Автор не только приводит готовые формулы и их реализации, но и производит анализ ошибок в каждом случае, позволяя читателю сделать правильный выбор.

Рекомендую разработчикам систем реального времени на платформах с ограниченными вычислительными ресурсами (в первую очередь 8-разрядных).

[Dale]

Sebastián Slutzky.

Unit Testing with Design by Contract.

URL: http://sebastianslutzky.com/2011/08/08/unit-testing-with-design-by-contract/

Проектирование по контракту (Design by Contract, DBC) - мощный инструмент создания высококачественного программного обеспечения. К сожалению, непосредственная поддержка DBC не реализована в широко распространенных сегодня языках программирования (скажем, тот же Eiffel трудно отнести к популярным).

Разумеется, концепция DBC может использоваться и без соответствующей языковой поддержки (подобно тому, как, например, можно реализовать объектно-ориентированный дизайн средствами языка C или структурный - на ассемблере). Однако при этом неминуемы некоторые трудности. В частности, неочевиден ответ на вопрос: кто и каким образом должен проверять выполнение контрактов?

Автор предлагает свое решение: проверка контрактов может производиться в модульных тестах. В статье приведен пример набора тестов для такой проверки.

Рекомендую разработчикам, заинтересованным в производстве высококачественного ПО с использованием DBC, TDD, формальных спецификаций.

[Dale]

Alan S. Koch.

Personal Quality Management with the Personal Software Process.

URL: http://www.methodsandtools.com/PDF/mt200702.pdf (p.p. 46-60)

Программное обеспечение создавалось, создается и в обозримом будущем будет создаваться людьми, которым свойственно ошибаться. "Кризис программного обеспечения" начался практически с появлением первых компьютеров и длится по сей день, и конца ему пока что не предвидится.

Не подлежит сомнению факт: качество не дается даром как побочный продукт процесса; оно достигается лишь в том случае, если для этого предпринимаются соответствующие меры. Истории о создании программ в десять тысяч строк, написанных в одиночку за три ночи и не содержащих ошибок, оставим на совести желторотых юнцов (разумеется, физиологический возраст тут ни при чем,имеется в виду лишь профессиональная зрелость). Любой профессионал, постоянно создающий софт "на конвейере", знает реальную цену этим байкам.

Брукс оказался прав в своем прогнозе: "серебряной пули" не существует (во всяком случае, за несколько десятилетий интенсивных поисков ее так и не смогли отыскать). Впрочем, это вовсе не означает, что с ошибками в программном обеспечении ничего нельзя поделать в принципе и остается лишь капитулировать. Существуют методики, которые позволяют успешно находить определенные классы дефектов на ранних стадиях разработки, когда их устранение обходится гораздо дешевле.

Многие из таких методик довольно тяжеловесны, ресурсоемки и применимы лишь при разработке большими группами с соблюдением формальных процессов. В случае, когда разработчиков всего один-два человека, проблематично, например, организовать формальную ревизию кода по всем классическим канонам.

Однако и для малых коллективов есть свои методики обеспечения качества. Одной из них является довольно известный Personal Software Process, описанный Уотсом Хамфри. Статья представляет краткий обзор этой методики. Особое внимание уделяется таким ключевым моментам обеспечения качества, как протоколирование дефектов и сбор статистических данных о них, организации циклических ревизий собственного кода и составление плана обеспечения качества (которому, разумеется, впоследствии придется следовать).

Рекомендую инженерам, работающим в областях, где качество играет ключевую роль (до недавнего времени я был уверен, что высокое качество требуется вообще всегда; спасибо коллегам, открывшим для меня параллельный мир сумбурного софта).

[Dale]

Jack Ganssle.

A Firmware Development Standard Version 1.4.

URL: http://www.ganssle.com/fsm.pdf

Довольно-таки неплохой вариант стандарта проектирования и реализации firmware (хотя претензии автора на глобальность кажутся мне не вполне серьезными, особенно с учетом его (стандарта, а отнюдь не автора) некоторой сыроватости и явных пробелов).

Несмотря на компактность, данный стандарт пытается охватить практически все аспекты процесса разработки firmware. Здесь и строгая организация файловой структуры проекта (аспект, который вызвал, как ни странно, нешуточный butthurt у некоторой части читателей моих статей), и способы избежать проблем с нехваткой оперативной памяти (которой обычно отнюдь не изобилуют микроконтроллеры), и очередная попытка канонизации идентификаторов, и рекомендации по стилю оформления кода, и извечная тема содержания и оформления комментариев... Перечислять можно долго, но все же лучше не пожалейте нескольких минут и прочитайте первоисточник.

Конечно же, не обошлось и без ложки дегтя. Например, раздел, касающийся документирования кода при помощи комментариев, весьма выиграл бы, если бы формат комментариев был бы доведен до логического завершения (doxygen), который качественно изменил бы их роль в проекте. Рекомендация собирать вместе все макроопределения тоже попахивает старым добрым Паскалем, где все переменные, константы, типы и т.д. определялись/объявлялись оптом в начале программы, а не непосредственно перед использованием. Но если в случае Паскаля это хоть как-то оправданно, то в программе на C это явное излишество, затрудняющее понимание программы при чтении.

Некоторые претензии можно предъявить автору и в отношении тестопригодности кода. Об этом в предлагаемом стандарте не сказано ни слова, несмотря на то, что требования к качеству кода в области firmware гораздо более жесткие, чем в менее критичных областях. Это серьезное упущение, поскольку далеко не каждый код пригоден для тщательного тестирования и для обеспечения тестопригодности нужно предпринимать определенные усилия, начиная с самых ранних стадий проекта.

Несмотря на перечисленные недостатки, с данной статьей определенно имеет смысл познакомиться. Конечно, не следует воспринимать ее как догму и шаблон для подражания, но по крайней мере принять ее материал к сведению и подумать, что из него можно позаимствовать для своей практики, стоит.

Если свинство на рабочем месте (равно как и хаос в проекте) вызывает у вас слезы умиления, а при слове "дисциплина" рука автоматически тянется к копробластеру, эта статья определенно не для вас. Всем остальным настоятельно рекомендую.

[Dale]

Jack Ganssle.

ESD is 15? No, It’s 20 Years Old.

URL: http://www.ganssle.com/tem/tem154.htm

Статья, приуроченная к 20-летнему юбилею журнала Embedded Systems Design, представляет собой историю развития встраиваемых систем, начиная с времен, предшествовавших появлению первого микропроцессора Intel 4004, до настоящего времени. История изложена с точки зрения автора, которому выпала удача проследить ее фактически с самого начала. Это, возможно, в некоторой степени лишает ее объективности, зато красочность и эмоциональность изложения придают статье определенный шарм.

Рекомендую статью тем, кто читает не только справочники и кого интересуют корни, от которых пошли современные микроконтроллеры.

[Dale]

Steve Litt.

My favorite Intermittent Stories.

URL: http://www.troubleshooters.com/tpromag/200504/200504.htm

Много лет назад, еще в школьные годы, мне попалась на глаза шутка, показавшаяся в то время весьма забавной: "Инженер - это человек, который может объяснить, как работает то или иное устройство, но не может определить, почему оно не работает". Со временем оказалось, что доля шутки в этом афоризме не столь уж велика, и ситуация в целом не столь уж забавна. Поиск неисправностей в сложных инженерных системах, пожалуй, является самом сложной технической задачей, а если неисправность к тому же не является устойчивой и проявляется лишь от случая к случаю без всякой видимой системы, такая задача по плечу лишь виртуозам своего дела.

Стив Литт - один из таких виртуозов. Причем Стив охотно делится бесценным опытом со всеми желающими достичь такой же степени мастерства (хотя это и очень непросто). Он является автором курса Systematic Troubleshooting and Debugging, который признан настолько широко, что читается не только автором, нескольких книг о поиске сложных неисправностей, а также публикаций в журнале Troubleshooting Professional Magazine (само название которого весьма красноречиво говорит о его тематической направленности).

Предлагаемая подборка небольших статей рассказывает о нескольких случаях из практики автора, запомнившихся ему своей неординарностью. Большинство этих случаев (но не все) относятся к компьютерному оборудованию, и все их объединяет общее свойство: неприятности проявляются недостаточно регулярно, чтобы можно было легко установить (и устранить) их причину, но при этом достаточно регулярно, чтобы отравить жизнь пользователю.

Полагаю, этой информации вполне достаточно, чтобы определить, окажется ли данная публикация полезной лично вам.

[Dale]

GAO/IMTEC-92-26 Patriot Missile Software Problem.

URL: http://www.fas.org/spp/starwars/gao/im92026.htm

Нам часто доводится слышать о том, как дорого порой обходятся ошибки в программном обеспечении вообще и во встроенном программном обеспечении в частности. В данном отчете расследуются причины ошибки, в результате которой погибли 28 американских солдат, и еще порядка сотни получили ранения.

Совсем вкратце для тех, кому лень прочитать оригинал: произошло это в ходе операции "Буря в пустыне". Ракета Scud, выпущенная иракскими войсками, угодила в бараки американского лагеря; результаты попадания уже упомянуты выше. Система Patriot, предназначенная для перехвата и уничтожения ракет противника, оказалась неспособной выполнить свою задачу из-за банальнейшей ошибки округления при работе с числами в формате с плавающей десятичной точкой. Ошибка накапливалась постепенно, в течение сотни часов непрерывной работы системы; очевидно, приемочной комиссии не хватило терпения дождаться ее появления во время испытаний, а тестирование проводилось "творчески" (то есть как попало, либо вовсе не проводилось: - зеленая лампочка на панели загорелась - значит, все работает).

Рекомендую для прочтения всем без исключения. Те, кто уже осознал необходимость систематического тестирования, имеют возможность лишний раз убедиться в своей правоте; те, кто еще колеблется, получат еще один аргумент в пользу тестирования, который, возможно, окончательно перевесит чашу весов; ну а совсем уж непробиваемые хотя бы немного развлекутся занимательным чтением. Так что польза гарантирована всем.

[Dale]

Gerard J. Holzmann, NASA/JPL Laboratory for Reliable Software

The Power of 10: Rules for Developing Safety-Critical Code.

URL: http://www.spinroot.com/gerard/pdf/Power_of_Ten.pdf

Стандарты кодирования - вещь, безусловно, нужная; впрочем, обилие таких стандартов свидетельствует о том, что окончательную точку на этой теме ставить пока еще рано.

В данной публикации предлагается еще один вариант такого стандарта, разработанный в стенах JPL (лаборатории реактивного движения NASA). Разумеется, поскольку речь идет о встроенных системах, стандарт целиком и полностью ориентирован на использование языка программирования C.

По мнению автора, обширными и многочисленными рекомендациями трудно пользоваться на практике, поэтому он предлагает ограничиться десятью, на его взгляд, наиболее важными, но следовать им неукоснительно.

Лично я не рискнул бы назвать этот набор правил безукоризненным. Некоторые из них откровенно банальны (вроде моратория на использование goto); некоторые вполне практичны (например, ограничение максимального размера одной функции или требование обязательной проверки результата вызова функции, если таковой имеется); некоторые не слишком эффективны (например, использование assert); и, наконец, скрупулезное соблюдение некоторых откровенно сковывает руки разработчику (например, запрет использования указателей на функции автоматически исключает применение многих весьма полезных паттернов проектирования, основанных на полиморфном поведении).

Так или иначе, ознакомиться с документом стоит однозначно, а далее выводы делайте сами.

[Dale]

Jack Ganssle.

Contracts put the "I do" in code.

URL: http://www.embedded.com/columns/breakpoint/197008824
URL: http://www.embedded.com/columns/breakpoint/198701649
URL: http://www.embedded.com/columns/breakpoint/199202728

В цикле из трех статей рассматривается возможность применения разработки по контракту (DBC, Design by Contract) с целью улучшения качества firmware. Описываются принципы определения пред- и постусловий, приведены примеры их практического применения для исключения возможности некорректной работы программы (наподобие деления на нуль или извлечения квадратного корня из отрицательного числа).

Помимо общих вопросов ("философии" контрактов), автор анализирует применимость DBC для разработок именно встроенного ПО с учетом его специфики (в частности, ориентированности подавляющего большинства разработок на язык программирования C, не имеющий встроенных средств для поддержки контрактов). Также автор делится опытом использования инструментальных средств для поддержки DBC совместно с языком C (к сожалению, полученный результат далек от удовлетворительного). Наконец, обсуждается применение DBC не изолированно, а в сочетании с другими средствами повышения качества ПО, поскольку совместное применение таких инструментов дает больший эффект.

Рекомендую "продвинутым" разработчикам, заинтересованным в совершенствовании процессов разработки ПО.

[Dale]

Nancy Van Schooenderwoert, Ron Morsicato.

Taming the Embedded Tiger – Agile Test Techniques for Embedded Software.

URL: http://www.leanagilepartners.com/library/XR5_Taming_Embedded_Tiger.pdf

Суть статьи прекрасно отражена в аннотации:

Строгое модульное тестирование - основа гибкой разработки программного обеспечения, однако встроенные системы представляют особые проблемы. Тесты встроенного ПО тесно связаны с тестами оборудования, пересекая как профессиональные, так и организационные границы. Учитывая изменения аппаратной части системы по мере развития проекта, гибкие методы предлагают множество тестовых стратегий. Это обеспечивает значительный вклад в повышение качества систем с высокими требованиями к надежности,имеющими обычно в своей основе встроенное ПО.

В статье описывается очередная попытка применить "гибкие" технологии к проектированию встроенных систем. На этот раз иллюстрацией к статье послужил успешно реализованный проект спектрометра, включающий, помимо оборудования, достаточно сложную вычислительную часть.

Статья была опубликована в 2004 году; с учетом запоздания проникновения "гибких" технологий в консервативный мир firmware можно отнести ее к ранним (сами авторы признают, что разработчики firmware практически не слышали о "гибких" технологиях). Поэтому читатели, внимательно следящие за публикациями в данном разделе, а также за конструктивной частью раздела Инструменты и технологии проектирования ПО и его подразделом Переводы, вряд ли найдут в ней принципиально новые для себя идеи. Например, предложенной авторами реализации проектра явно не хватает уже хорошо знакомой нам архитектуры "модель-проводник-оборудование" и соответствующих паттернов.

Впрочем, одна из идей заслуживает внимания, а именно концепция "доменных тестов", которые логически находятся между модульными и функциональными.

Рекомендуется разработчикам,"дозревшим" для использования "гибких" технологий при проектировании firmware.

[Dale]

Nancy Van Schooenderwoert.

Embedded Agile Project by the Numbers With Newbies.

URL: http://www.leanagilepartners.com/library/Vanschooenderwoert-EmbeddedNumbers.pdf

История успеха сложного проекта, который довелось реализовывать команде новичков, с тщательным анализом результатов. Ее можно считать продолжением предыдущей статьи.

Разработка спектрометра для анализа зерна производилась в самый разгар раздувания "пузыря доткомов", когда спрос на программистов вырос настолько, что даже недоучки могли рассчитывать на высокооплачиваемую работу, а свободных профессионалов было не сыскать днем с огнем. Автору пришлось возглавить довольно пеструю команду разработчиков, некоторые из которых имели лишь скромный опыт программирования и совершенно не разбирались в аппаратуре, а другие занимались лишь электроникой и понятия не имели о программировании.

В этой непростой ситуации лидер проекта (она же автор статьи) сделала ставку на "гибкие" технологии разработки. Как оказалось в итоге, ставка оказалась верной - проект был реализован полностью и в срок, при этом поначалу неопытная команда (большинство разработчиков обучались по ходу дела) показала отличный темп (втрое выше среднего по отрасли) и при этом высокое качество (всего 55 обраруженных дефектов за 3 года работы).

Особенностью проекта является факт, что роль ревизий кода в процессе была невысокой с самого начала, причем ей отводилась скорее учебная роль (обмен опытом при совместном обсуждении кода), чем обычная для "гибких" технологий роль обеспечения качества. В дальнейшем (по прошествии года) ревизии были и вовсе упразднены. Их место частично заняли "мозговые шурмы" при обсуждении спосоов реализации пользовательских историй.

Статья изобилует статистикой, которую автор не ленилась собирать все три года разработки.

Рекомендую ведущим разработчикам, планирующим совершенствовать процессы разработки в своих организациях.

[Dale]

Charlie Mills.

Using Design by Contract in C.

URL: http://onlamp.com/pub/a/onlamp/2004/10/28/design_by_contract_in_c.html

Статья посвящена авторской реализации DBC для языка C.

Контракты описываются в виде комментариев специального вида, которые обрабатываются специальным препроцессором, написанным на Ruby. Достоинство такого подхода заключается в том, что компилятор не видит расширений DBC, поэтому в случае необходимости отказа от контрактов достаточно лишь не запускать препроцессор.

В статье упоминается об успешном "сотрудничестве" DBC и модульного тестирования, хотя у меня сложилось мнение, что при этом могут возникнуть довольно серьезные затруднения, причем не технические, а идеологические. Неплохо было бы разыскать публикации на эту тему.

Рекомендую статью разработчикам уровня advanced.

[Dale]

John Pultorak.

Block I Apollo Guidance Computer (AGC): How to build one in your basement.

URL: http://klabs.org/history/build_agc/

Прошло долгих 30 лет с тех пор, как я впервые соприкоснулся с миром компьютеров, чтобы остаться в нем и по сей день. За эти годы довелось повидать немало всякого.

Некоторые вещи (и их, к сожалению, в настоящее время подавляющее большинство) вызывают лишь недоумение. Поразительно, сколько сил и средств направляется на создание (и продвижение) сущностей непонятного лично мне и моим единомышленникам назначения, вроде всяких айфонов, социальных сетей, онлайновых игрушек, в которых для мало-мальского продвижения нужно провести не одну тысячу часов, и прочего модного среди бездельников хлама. Еще более поразительно, что в финансовом плане вложения в этот хлам на несколько порядков превышают бюджеты реально полезных проектов, делая своих создателей миллиардерами (фамилии называть не буду, они и так на слуху).

Есть продукты добротные и нужные, их, к счастью, тоже не мало. К ним (и их создателям) испытываешь заслуженное уважение, без них плодотворная работа весьма затруднена, если вообще возможна. Однако со временем при повседневном использовании начинаешь воспринимать их как должное.

И, наконец, есть проекты, просто поражающие своим гениальным безумием и за которые лично я никогда не рискнул бы взяться. Но находятся люди, которые рискуют - и доводят их до победного конца. Перед такими людьми я готов снять шляпу (хотя обычно я этим не злоупотребляю, поскольку со студенческой скамьи приучен скептически относиться к авторитетам и крайне осмотрительно создавать себе кумиров).

Один из таких проектов находится по ссылке. Он представляет собой детальную реконструкцию прототипа бортового компьютера космических кораблей семейства Apollo (Apollo Guidance Computer, AGC) от 1964 года. Именно этот компьютер управлял полетом и высадкой на Луну экспедиций, потрясших в свое время человечество (и, кстати, до сих пор не превзойденных ни в техническом плане, ни своей дерзостью, поскольку у принимающих ключевые решения лиц приоритеты нынче сместились в сторону "айфончегов" и "блогов в твиттере").

Нашелся человек, который в наше время собрал данные по крупицам и повторил легендарную конструкцию. Возможно, чудачество, но такие чудаки и есть соль земли. Воссоздана не только программная часть, но и аппаратура, на которой эти программы выполнялись. Все коды/схемы выложены в открытый доступ без всяких лицензионных и авторских ограничений (нашим людям они, конечно, не писаны, но есть места, где эти ограничения чтут больше, чем Остап Бендер - уголовный кодекс).

Признаться, лично я вряд ли решусь на сборку такого агрегата своими руками (хотя теоретически, безусловно, хотелось бы; однако повседневная текучка однозначно не даст возможности). Но простое осознание факта, что еще остались на свете люди, способные на такие свершения, поднимает настроение.

Полагаю, материалы могут пригодиться преподавателям-энтузиастам схемотехники и программного обеспечения управляющих вычислительных систем. Они (материалы) могут стать превосходной основой для учебных стендов и лабораторных работ.

[Dale]

Jack Ganssle.

Coders Vs Programmers.

URL: http://www.ganssle.com/tem/tem166.htm (p.p. 3-4).

Название очерка невольно навеяло избитую цитату: "Ты, Каштанка, насекомое существо и больше ничего.  Супротив  человека ты все равно, что плотник супротив столяра...". А действительно, быть кодером - хорошо или плохо? Может ли кодер гордиться делом своих рук, или его удел - быть мальчиком на побегушках у всемогущего архитектора и расходным материалом для менеджера проекта? В конце концов, тварь он дрожащая или право имеет?

Если вам интересно мнение мэтра по данному вопросу - добро пожаловать по ссылке.

[Dale]

Jack Ganssle.

The Failure of Reuse.

URL: http://www.ganssle.com/tem/tem167.htm (p.p. 3-4)

Эссе посвящено старой, но недоброй проблеме повторного использования кода. Автор делится своими соображениями по поводу трудностей, которые поджидают программиста на пути создания пригодного к повторному использованию кода.

Любопытно сравнение создания таких модулей с накоплением средств на банковском счете. И в том, и в другом случае вы сразу теряете часть средств, а ощутимый результат получаете гораздо позже. Нужна определенная дальновидность и даже мудрость, чтобы осознать необходимость чем-то жертвовать сейчас ради отдаленной выгоды.

Для разработчиков уровня advanced, которые достаточно созрели для понимания предмета.

[Dale]

Mike Barr.

Job Descriptions.

URL: http://www.ganssle.com/tem/tem168.htm (p.p. 9-10)

В прошлом номере журнала некто Harold Teague попросил осведомленных читателей привести перечень знаний и умений, необходимых инженерам-раработчикам встроенных систем. Майк Барр в своей ответной заметке любезно предоставил список требований, которые он предъявляет к претендентам при приеме на работу.

Заметка пригодится тем, кто склоняется к выбору карьеры в данном направлении, но еще плохо представляет себе, что именно для этого необходимо изучить.

[Dale]

Steve Christey (MITRE).

2011 CWE/SANS Top 25 Most Dangerous Software Errors.

URL: http://cwe.mitre.org/top25/

MITRE провела большую работу по выявлению наиболее типичных ошибок в программных продуктах, оценке их распространенности, степени опасности, сложности исправления и т.п. Статья подводит итоги этой работы, представляя 25 ошибок, возглавляющих своеобразный хит-парад.

Цель, поставленная MITRE, сформулирована таким образом:

Список Top 25 - это средство предупредить программистов об уязвимостях, которые отравляют программную индустрию, и научить их избегать этих уязвимостей, распознавая и устраняя наиболее типичные ошибки еще до поставки продукта. Потребители могут использовать этот список, чтобы требовать более безопасные продукты. Исследователи безопасности ПО могут фокусировать внимание на более узком, но самом важном подмножестве всех известных уязвимостей. Наконец, администрация может использовать список как показатель прогресса в повышении степени безопасности своих продуктов.

Каждый элемент списка детально проработан: описан характер проблемы и ее причина (порой довольно красочными метафорами), приведены примеры уязвимого кода, способы обнаружения уязвимости, возможные пути устранения ошибки и т.д. Возможно, если работа в данном направлении продолжится, вскоре мы увидим классификацию паттернов ошибок, признаки "запахов", рефакторинг и т.п.

Понимание статьи требует наличия некоторой профессиональной зрелости, поэтому отношу ее к категории обязательного чтения для профессионалов.

[Dale]

Bryan O'Sullivan.

Making Sense of Revision-control Systems.

URL: http://queue.acm.org/detail.cfm?id=1595636

Небольшой, но содержательный обзор различных систем управления версиями. Автор рассматривает как централизованные, так и распределенные VCS, отмечая недостатки и достоинства каждого варианта. Особенное внимание уделено проблемам, свойственным распределенным VCS, и способам их решения.

Статья может представлять интерес для тех, кто намерен влиться в географически рассредоточенную команду разработчиков или организовать подобный проект самостоятельно. С развитием аутсорсинга ее предмет становится все более актуальным.

[Dale]

Robert N. Charette.

This Car Runs on Code.

URL: http://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code/0

Любопытная статья о все возрастающей роли микропроцессоров в управлении современным автомобилем. Люди, находящиеся "в теме", приводят массу интереснейших данных, о которых лично я имел до сих пор самое смутное представление: сколько микропроцессоров нынче ставят в автомобиль и сколько кода для них требуется, какую часть общей стоимости авто составляет встроенная в него электроника и ее программное обеспечение, какие преимущества она обеспечивает (когда работает, разумеется) и чем чреваты ее отказы, в какую сумму обходится производителю дефект в программе и как обеспечить квалифицированную диагностику и ремонт продвинутого девайса, на который гаражный механик в замасленном комбинезоне смотрит с благоговейным ужасом...

Статью можно проглядеть для общего развития, но еще лучше, если она заставит задуматься: адекватны ли наши сегодняшние навыки, инструменты и методики современным требованиям к качеству firmware? Если появились сомнения, их может стать меньше после ознакомления с соответствующей литературой и инструментальными средствами.

[Dale]

 Brian Santo.

25 Microchips That Shook the World.

URL: http://spectrum.ieee.org/semiconductors/processors/25-microchips-that-shook-the-world

Собственно, все сказано в названии. Эссе содержит 25 мини-глав, в каждой из которых представлена краткая история микрочипа, который, по мнению автора и его коллег, оказал наибольшее влияние на нынешнее состояние электроники.

Это мнение, бесспорно, субъективно, и каждый читатель наверняка сможет с негодованием назвать десяток-другой блестящих, по его мнению, чипов, которые были бы достойны занять место в данном хит-параде, но оказались незаслуженно забыты. Например, один из моих коллег, которому я показал статью, предложил добавил трехвыводный стабилизатор. Впрочем, это тема для отдельного разговора (или, точнее, разговор для отдельной темы).

[Dale]

Richard Banks.

Personal Time Management and Agile.

URL: http://www.richard-banks.org/2010/03/personal-time-management-and-agile.html

Небольшая заметка посвящена преимуществам использования "помидорного" планирования времени в гибких технологиях разработки.

Рекомендую тем, кто ищет пути повышения продуктивности собственного труда.

[Dale]

Martin Fowler.

Mocks Aren't Stubs.

URL: http://martinfowler.com/articles/mocksArentStubs.html

Статья посвящена достаточно детальному анализу использования заглушек и мок-объектов в процессе TDD.

Особое внимание автор уделяет не столько разнице между заглушками и моками, как можно ожидать из названия, сколько принципиальным различиям между двумя основными парадигмами модульного тестирования: тестированием состояния и тестированием поведения. Анализируются плюсы и минусы каждого подхода. Приведены небольшие, но достаточно выразительные примеры тестового кода.

Те, кто имел возможность проштудировать классическую монографию Месароша, возможно, не найдут для себя в данной статье ничего принципиально нового. Тем, у кого эти открытия еще впереди, но кто уже реально заинтересован в качестве кода (т.е. не ограничивается пустыми лозунгами, а намерен предпринимать усилия для достижения этой цели), настоятельно рекомендую. Ответов на все вопросы вы, конечно же, в столь небольшой статье не найдете, но направление дальнейшего движения она укажет верное.

[Dale]

Robert Martin.

The Three Laws of TDD.

URL: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

В этой небольшой по объему статье Мастера в максимально сжатой форме представлены основы TDD (фактически они сведены к трем законам, сформулированных одной строчкой каждый). Тем, для кого TDD - обычная каждодневная практика, эти законы уже давно хорошо знакомы (пусть и не в таких блестящих формулировках); тем же, кто понял пользу TDD и предпринимает попытки применить ее в своих проектах, но сталкивается с техническими трудностями, статья может пролить свет на непонятные аспекты.

Представляет интерес также обсуждение статьи читателями, которое следует сразу же за основным текстом.

[Dale]

Robert Martin.

The Truth about BDD.

URL: https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd

Дядюшка Боб излагает свой весьма любопытный взгляд на BDD через призму конечных автоматов. В частности, рассматривается аналогия между функциональным описанием спецификаций (наподобие Gherkin etc.) и традиционным табличным определением КА.

Такой подход может принести реальную пользу, поскольку конечные автоматы не только хорошо проработаны теоретически в рамках одноименной дисциплины, но и имеют солидную инструментальную подержку реализации, чем пока не может похвастать BDD. Кроме того, сам факт конечности переходов автомата может быть использован при анализе полноты спецификаций, что гораздо сложнее при другой форме их представления.

Справедливости ради следовало бы отметить, что сама идея представления спецификаций системы в виде КА не нова, но в применении к BDD лично мне ранее не встречалась.

Статья представляет безусловный интерес для команд, практикующих подход BDD и активно использующих исполняемые спецификации для контроля качества своих продуктов (не только чисто программных).

[Dale]

Chris Adamson.

Punk Rock Languages.

URL: http://pragprog.com/magazines/2011-03/punk-rock-languages

Забавная полемическая статья о сходстве корней и философии языка программирования C и панк-рока. Действительно, оба они аскетически просты (но при этом не проще, чем необходимо), политически и экономически независимы, не умирают уже многие годы, наконец, стали основой для множества других жанров и направлений, которые, тем не менее, так и не отодвинули их окончательно в сторону... Особый шарм статье придают тщательно подобранные цитаты ветеранов рока и программирования, которые говорят практически об одних явлениях разными словами.

Единственно, с чем лично я бы не согласился, - это с включением в программистскую панк-культуру JavaScript'а; если уж продолжать музыкальные аналогии, я бы скорее сравнил его с бардовской песней: популярно, но уныло и чересчур простовато (той самой простотой, которая хуже воровства). Но это мое личное IMHO.

[Dale]

Gojko Adzic.

Effective user interface testing.

URL: http://gojko.net/2007/09/25/effective-user-interface-testing/

Автор статьи Gojko Adzic - известный эксперт в области функционального и приемочного тестирования программного обеспечения, автор книг, ставших классикой этого жанра (их обзоры появятся в соответствующей теме в ближайшем будущем). В данной статье он дает советы в весьма непростой проблемной области: как организовать приемочное тестирование продуктов, использующих графический интерфейс пользователя.

Конечно, в столь небольшом объеме трудно вместить достаточно подробные ответы на многочисленные непростые вопросы, аозникающие при попытке приемочного тестирования приложений GUI. Эти ответы, конечно же, целесообразнее искать в монографияъ автора, в статье же они лишь намечены. Впрочем, правильная постановка задачи - хорошее начало пути к ее решению.

К недостаткам статьи следует отнести полное молчание о возможности отделения GUI от проблемной области посредством соответствующих архитектурных паттернов (например, MVP). Такое решение в сочетании с подходом к тестированию "presentation first" делает многие проблемы гораздо менее острыми. Впрочем, не исключено, что автор считает это настолько очевидным, что не считает нужным упоиинать явно.

Статья представляет особый интерес для тех, кто внедряет и использует процессы управления качеством программного обеспечения, а также базирующиеся на них технологии, например, разработку, управляемую поведением (BDD).

У инженеров "от сохи паяльника" может возникнуть закономерный вопрос: какое отношение данная статья имеет к embedded разработкам? Самое непосредственное. Неоднократно рассмотренный на нашем форуме паттерн MCH (Model-Controller-Hardware) практически идентичен MVP, поэтому практически все вышесказанное может быть успешно применено при разработки качественного встроенного ПО.

[Dale]

Gojko Adzic.

How to implement UI testing without shooting yourself in the foot.

URL: http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

Продолжение темы предыдущей публикации.

Данная статья более сфокусирована на основной проблеме Функционального тестирования приложений с GUI: что именно и каким образом тестировать. Автор, исследоваавший практику нескольких продуктивных групп разработчиков на реальных, коммерчески успешных проектах, наглядно показал, что простая автоматизация приемов, традиционных для ручного тестирования, приводит в тупик: результирующие автоматические тесты оказываются слишком хрупкими, невыразительными, медленными и дорогими в обслуживании, что изрядно компрометирует саму идею широкого применения автоматизированных тестов.

Что весьма ценно, помимо критики неудачных практик, в статье присутствует и конструктивный момент. Автор предлагает производить функциональное тестирование приложений на трех уровнях: бизнес-правил, последовательности действий и техническом. Если разместить тест на правильном уровне, можно добиться от него максимальной выразительности и информативности.

Как и предыдущую, рекомендую данную статью "тест-инфицированным" разработчикам, которые считают, что полагаться на код, протестированный в лучшем случае поверхностно методом тыка, наивно и безответственно (а если код создается на средства стороннего заказчика, то еще и не слишком порядочно), независимо от предметной области.

[Dale]

Martin Fowler.

AssertionFreeTesting.

URL: http://martinfowler.com/bliki/AssertionFreeTesting.html

Очень маленькая по объему, но весьма поучительная заметка о том, к чему порой приводит чрезмерное увлечение показателями на базе формальных метрик (в частности, оценки степени покрытия кода тестами). Собственно, ничего принципиально нового, проявления культа карго в программировании - вполне привычная вещь.

[Dale]

Alberto Savoia (автор перевода).

The Way of Testivus.

URL: http://www.agitar.com/downloads/TheWayOfTestivus.pdf

Перевод древней восточной рукописи, найденной в гималайской пещере. В чрезвычайно компактной форме представлены наиболее важные сведения, какими должны быть модульные тесты (а также какими они быть не должны ни в коем случае).