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

[Dale]

Brian Marick.

How to Misuse Code Coverage.

URL: http://www.exampler.com/testing-com/writings/coverage.pdf

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

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

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

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

[Dale]

Dan North.

Whose domain is it anyway?

URL: http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/

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

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

Рекомендую системным аналитикам и специалистам в области качества ПО.

[Dale]

Dan North.

Let your examples flow.

URL: http://dannorth.net/2008/06/30/let-your-examples-flow/

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

В комментариях читателей можно также найти интересные мысли по этой теме.

Рекомендую приверженцам идей BDD и SBE.

[Dale]

Jonathan M. Smith.

Fighting Physics: A Tough Battle.

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

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

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

Годится в качестве легкого чтения на досуге (при всем уважении к авторитетности источника, из которого она взята).

[Dale]

Julio Diez Ruiz.

Overcoming the embedded CPU performance wall.

URL: http://www.embedded.com/design/mcus-processors-and-socs/4405280/1/Overcoming-the-embedded-CPU-performance-wall-

И снова немного физики. На этот раз речь пойдет о естественных преградах, не позволяющих непрерывно наращивать тактовые частоты цифровых схем.

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

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

[Dale]

Jacob Beningo.

10 Software Tips for Hardware Engineers.

URL: http://beningo.com/index.php/design-cycle/135-10-software-tips-for-hardware-engineers.html

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

[Dale]

Steve Losh.

Teach, Don’t Tell.

URL: http://stevelosh.com/blog/2013/09/teach-dont-tell/

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

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

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

[Dale]

Scott Whitney.

Engineering Curricula.

URL: http://www.ganssle.com/tem/tem241.html#article2

Не секрет, что стать квалифицированным инженером в области встроенных систем весьма непросто, ведь эта инженерная дисциплина находится на стыке электроники и программирования, освоение которых даже порознь - непростая задача, а совместно тем более требует немалых усилий. Любая однобокость эмбеддера пагубно сказывается на результате его работы. Те, кого не испугали эти трудности, задаются естественными вопросами: какие дисциплины следует освоить и какими источниками для этого воспользоваться?

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

Автор заметки предпринял попытку предложить некий минимум знаний, необходимых эмбеддеру (некое подобие SWEBOK в нано-исполнении), в сочетании со ссылками на источники информации для получения этого минимума. Безусловно, перечень этот далеко не полон (говоря языком математики, "необходим, но не достаточен"), но заслуживает внимания хотя бы в качестве отправной точки.

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

[Dale]

Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, M. Frans Kaashoek.

Undefined Behavior: What Happened to My Code?

URL: http://pdos.csail.mit.edu/papers/ub:apsys12.pdf

Очередное напоминание о том, как важно досконально знать детали стандарта языка C для его эффективного использования в низкоуровневом программировании.

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

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

[Dale]

Jack Ganssle.

Certification.

URL: http://www.ganssle.com/tem/tem249.html#article3

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

Приведу небольшую цитату автора:

Лицензия? Сертификация? Ничего подобного. Если вы способны выговорить "C", вы получите работу. Не нужно иметь понятие об анализе причин сбоев, сертификации DOD-178C или требованиях к программному обеспечению FDA.
Нужно ли вам понимать методики разработки ПО, инженерию процессов, CMM, PSP, гибкие методики разработки или метрики сложности? Отнюдь. Просто научитесь побыстрее набрасывать код левой задней ногой.

Невольно вспомнился собственный печальный опыт отбора претендентов на должность разработчика ПО, стекленеющий взгляд, как только разговор заходит о паттернах GoF либо GRASP, о проектировании и тестировании, валидации и верификации... Словом, обо всем, что не упомянуто в руководстве "Язык пограммирования X для чайников".

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

[Dale]

Jack Ganssle

Toyota’s Expensive Software

URL: http://www.embedded.com/electronics-blogs/break-points/4429601/Toyota-s-Expensive-Software

До недавних пор рекорд стоимости встроенного программного обеспечения долге время держал Space Shuttle (порядка 1000$ за строку исходного кода). Автоконцерну Toyota удалось побить этот рекорд (хотя это событие вряд ли порадовало их руководство).

Toyota вынуждена была выплатить 1.200.000.000$ по требованию суда после того, как экспертиза доказала, что именно ошибки ПО, встроенного в автомобили Toyota и Lexus, приводили к внезапному резкому ускорению автомобиля, что становилось причиной увечий и смерти водителей и пассажиров. Объём кода оценивается примерно в 1 млн. строк, что задаёт новую планку стоимости - 1.200$ за строку.

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

[Dale]

Phil Koopman

Rules for Using Interrupts

URL: http://betterembsw.blogspot.ru/2013/03/rules-for-using-interrupts.html

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

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

[Dale]

Phil Koopman

Do Not Re-Enable Interrupts In An ISR

URL: http://betterembsw.blogspot.ru/2014/01/do-not-re-enable-interrupts-in-isr.html

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

Рекомендую разработчикам систем реального времени

.

[Dale]

Phil Koopman

Embedded Software Costs $15-$40 per line of code

URL: http://betterembsw.blogspot.ru/2010/10/embedded-software-costs-15-40-per-line.html

Собственно, в заголовке заметки все сказано: речь в ней идёт о стоимости встроенного ПО. Вынужден сразу же разочаровать оптимистов: это общая стоимость проекта, а не сумма, которую программист кладет в карман.

Рекомендую тем, кто интересуется оценкой стоимости проекта.

[Dale]

Steve Leibson.

Unexplained memory errors in your DDR3 design? Maybe it’s “Row Hammer.” Yet another thing to worry about.

URL: http://forums.xilinx.com/t5/Xcell-Daily-Blog/Unexplained-memory-errors-in-your-DDR3-design-Maybe-it-s-Row/ba-p/497600

DDR3 -широко распространённый тип динамической памяти, используемый и в качестве ОЗУ, и как видеопамять, и для буферизации больших объёмов данных... К сожалению, надёжность этих устройств оставляет желать лучшего по причине так называемого эффекта “Row Hammer”. Вкратце суть явления такова: если слишком часто обращаться к одной и той же маленькой области адресов, данные в соседних строках разрушаются, как если бы отсутствовала регенерация.

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

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

[Dale]

Jack Ganssle

Flash Schedules

URL: http://www.ganssle.com/tem/tem267.html#article3

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

Во времена, когда firmware записывалось в ПЗУ, его замена была не такой уж простой задачей для потребителя и порой требовала вмешательства производителя. Поэтому разработчики подходили к программированию с максимальной ответственностью.
 
Сейчас, когда все гаджеты оснащены флеш-накопителями, скачать с сайта поддержки и залить новую прошивку можно быстро, и справится с этим даже школьник. С одной стороны, это значительный прогресс. С другой - это поощряет производителя выбрасывать на рынок продукты с сырой прошивкой как можно быстрее с расчётом выиграть время и исправить ошибки позже. Нередки случаи, когда свежекупленный гаджет из коробки оказывается вовсе неработоспособным без перепрошивки.

Хорошо это или плохо - вопрос довольно спорный.

[Dale]

Jack Ganssle

On Margin

URL: http://www.ganssle.com/tem/tem268.html#article1

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

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

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

Для всех разработчиков - рекомендую, для разработчиков embedded - обязательно, для заинтересованных в качестве - суперобязательно.

[Dale]

Jack Ganssle

More on Hiring New Graduates

URL: http://www.ganssle.com/tem/tem279.html#article1

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

Почти во всех объявлениях о приёме на работу на инженерные специальности, которые мне доводилось видеть, обязательным условием является наличие опыта работы, хотя бы 2-3 года. Получается порочный круг: эти несколько лет стажа должны непостижимым образом возникнуть из ничего. Некое подобие известной "Уловки-22"...

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

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

[Dale]

Michael Barr, Salomon Singer.

Mutexes and Semaphores Demystified.

URL: http://www.barrgroup.com/Embedded-Systems/Webinars/Mutexes-vs-Semaphores

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

Вебинар проводит Barr Group, он состоится 13 мая 2015 г. Предупреждают, что количество участников ограничено до 1000, поэтому заинтересованным рекомендую регистрироваться заблаговременно.

[Dale]

Martin Fowler.

Inversion of Control.

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

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

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

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

[Dale]

Tim Wescott.

PID without a PhD.

URL: http://www.embedded.com/design/prototyping-and-development/4211211/PID-without-a-PhD

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

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

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

[Dale]

Nigel Jones.

Computing your stack size.

URL: http://embeddedgurus.com/stack-overflow/2009/03/computing-your-stack-size/

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

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

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

[Dale]

Ross N. Williams.

A Painless Guide to CRC Error Detection Algorithms.

URL: http://www.zlib.net/crc_v3.txt

Статья, ставшая классикой, на не менее классическую тему: вычисление CRC.

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

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

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

Рекомендую начинающим инженерам, которые накапливают багаж знаний.

[Dale]

Peter D. Hiscocks.

Oscilloscope Development, 1943-57.

URL: http://www.syscompdesign.com/assets/Images/AppNotes/scope-history.pdf

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

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

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

Рекомендую всем, кто интересуется историей электроники.

[Dale]

Jack Ganssle.

Software By The Numbers.

URL: http://www.ganssle.com/tem/tem287.html#article3

В чём состоит главное отличие инженера от шамана?

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

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

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

[Dale]

James Newman.

Mega-processor.

URL: http://megaprocessor.com/index.html

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

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

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

Простота - это хорошо; однако, как говорят в народе, она бывает хуже воровства. Монолитным компьютером довольно легко пользоваться. Его очень трудно чувствовать. Конечно, это нужно далеко не всем, но когда это реально нужно, это становится проблемой. Именно поэтому периодически то там, то сям находится энтузиаст, готовый потратить избыток сил и времени на построение собственного компьютера из самых базовых блоков, например, на транзисторах. Один из подобных проектов расположен по ссылке. Энтузиаст по имени Джеймс Ньюман решился на подобную авантюру в стенах Кембриджа.

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

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

[Dale]

James W. Grenning.

Planning Poker, or How to avoid analysis paralysis while release planning.

URL: http://renaissancesoftware.net/papers/14-papers/44-planing-poker.html

Обычно имя Джеймса Греннинга ассоциируется с фундаментальными работами о применении методики TDD в области разработки embedded. Однако на его счету имеется также одна замечательная идея, нашедшая гораздо более обширное применение практически во всех областях программирования, где применяется подход agile (в частности, в командах SCRUM).

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

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

Рекомендую всем приверженцам agile, особенно начинающим тимлидам.

[Dale]

???

JTN002 - MinUnit -- a minimal unit testing framework for C.

URL: http://www.jera.com/techinfo/jtns/jtn002.html

Автор заметки по каким-то причинам пожелал остаться неизвестным, и напрасно: многие сказали бы ему спасибо.

Прочитав заголовок, я в принципе был готов увидеть некий компактный инструмент для модульного тестирования; но не настолько же компактный! Полный его исходный текст занимает 3(!) строчки на C: два макроса и объявление глобальной переменной. Тем не менее этот инструмент позволяет провести в принципе полноценное модульное тестирование C-программы.

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

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

Обсуждение здесь: https://forum.shelek.ru/index.php/topic,30354.0.html

[Dale]

James O Coplien.

Why Most Unit Testing is Waste.

URL: http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

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

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

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

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

[Dale]

David S. Janzen, Hossein Saiedian.

Does Test-Driven Development Really Improve Software Design Quality?

URL: http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1027&context=csse_fac

Довольно детальное исследование влияния TDD на качество разработки программных продуктов, опубликованное в журнале IEEE Software. На мой взгляд, даже излишне детальное; статья ничего не потеряла бы в моих глазах, если бы результаты были более обобщены.

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

Рекомендуется тем, кто в данный момент стоит на распутье между TDD и подходом "сначала пишем, потом тестируем".