четверг, декабря 31, 2009

Лучшее за 2009 год

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

Самый популярный пост этого года - видео, перепост с другого блога - Про технологии и чудеса.

Следом за ним следует наше с Джимом творение - Карта языка С++. Популярное не только у нас, но и за рубежом :-).

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

Также в уходящем году пост про delete this вызвал некоторый интерес, а Задача про зеркало породила немеряно комментариев.

Все еще очень популярны посты прошлых лет: Хорошие книги по С++ для начинающих и Нарисовать граф красиво

Всем спасибо за внимание, всех с Новым Годом :-)



Ссылки по теме:
Лучшее за 2008 год
Лучшее за 2007 год
Лучшее за 2006 год
Лучшее за 2005 год

вторник, декабря 29, 2009

Статья They Write the Right Stuff

В комментариях к посту Искусство отладки Евгений Охотников дал ссылку на статью про то как разрабатывается софт в NASA: They Write the Right Stuff. Статья полезная, но очень пафосная и занудная, нужная информация начинается на четвертой странице, первые три страницы о том, какие замечательные люди там работают. Я убрала всю воду и получился перессказ на полстраницы.

Интересная статистика: В последних 11 версиях их продукта всего было 17 ошибок, в обычной софтверной компании в программе сравнимого объема было бы 5000 ошибок.

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

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

3.Ведется база данных найденных багов.
Как нашли, как починили.

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


В самом конце говорится, что это самая дорогая софтверная организация одна из самых дорогих софтверных групп (on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations), они тратят 35 миллионов долларов в год. Автор статьи был на встрече группы, там было 22 человека. Ну и небыстро там все происходит, я подозреваю.

четверг, декабря 17, 2009

Своя Компания

У программистов часто встречается большая и светлая мечта - открыть Свою Компанию по производству софта. К сожалению, для этого надо Много Денег, потому мечта неосуществима. На самом деле эта светлая мечта неосуществима по другим причинам.

Два вопроса, которые позволяют быстро оценить серьезность намерений.
1. Что именно будет делать эта компания?
2. Сколько конкретно нужно денег?

Ответы на первый вопрос обычно туманный: "ну.. игры...?". Народ любит делать игры, ага :-).
Ответ на второй вопрос тоже вызывает затруднения. Ответ обычно получается в миллионах долларов. "ну... миллион. Или два".

Откуда берутся эти миллионы никто толком сказать не может. "Надо снять офис и нанять людей". Детальный счет из этих миллионов никто составить не может. Правда, все уверены, что счет идет на миллионы. Прикольно. Но если сесть и посчитать, то получаются другие цифры. Я знаю, я считала. Это был 2006 год, расчет делался для компании по производству shareware игр, для Москвы. Получилось ~20000 долларов. Ден Шергин, гендиректор Unigine тоже считал. У него получилось $10-20k. Забавно, да? Сильно меньше миллиона...

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

У нас тут скоро Новый Год, пора сбычи мечт. Сделайте хоть что-нибудь. Ответьте на заданные мною вопросы. Если у вас есть идея, которая кажется вам ценной, расскажите о ней. Хотя красиво выглядящая идея далеко не самое главное. "У меня есть грандиозная идея и если бы только были деньги на ее реализацию...". Людей постоянно прет от идей, вы не поверите. Одна бредовее другой. Напишите прототип. Возможно, в процессе его написания вы поймете, что придумали фигню. Потом, поучаствуйте в Imagine CUP, попробуйте найдите финансирование.

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

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

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

Истории неудач
... которые зачастую интереснее историй успеха. Обе из области разработки игр.

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

История номер два.
Папа дал сыну денег :-).
Сын сделал компанию по производству игр. Сделали одну игру, она не зажгла, хотя неплохая вроде игра. Компанию пришлось закрыть, людей распустить.

Краткий словарик:
PoC (Proof of concept) - в нашем случае некий прототип, доказывающий, что идея рабочая
Венчурный капиталист - человек или компания, которые инвестируют деньги. Я знаю только одну такую компанию, это Y Combinator. Поищите, их много.
Ангел - человек, который готов дать вам денег либо просто так, либо на каких-то очень приятных условиях
Стартап - свежесозданная компания. Обычно этот термин применяется к компаниям в сфере IT.

Ссылки:
Будет ли работать бизнес-модель Y Combinator в России?

Книги:
Founders at work
Берись и делай
7 навыков высокоэффективных людей

воскресенье, декабря 06, 2009

Искусство отладки: технологии будущего

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

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

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

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

2. Статический анализ кода.
Выглядит уже более реалистично. Натравливаем на проект программу, которая анализирует код и пытается найти ошибки. Я не видела, чтобы эта метода была официально одобрена и использовалась в каких-нибудь компаниях серьезно. Однако, существуют статические анализаторы, которые стоят хороших денег с большим количеством нулей. Наверное их кто-то покупает. Я же встречала только ситуации, когда программисты из любопытства запускали какой-нибудь из таких анализаторов на своем проекте и просматривали результаты.
Народ говорит, что такие анализаторы много шумят не по делу, какие-то ошибки пропускают, но в целом выглядят интересно.
Тут много ссылок:
Static code analysis
Статический анализ кода C++ - обсуждение на Хабрахабре
Best tools noone uses: PREfast - статья на русском, немного про программы-анализаторы вообще, в основном про PREfast
dtjurev: Статический анализ С++ кода

среда, декабря 02, 2009

Искусство отладки: как починить баги

Мы подобрались к Злу вплотную. Вот они, баги - порождения человеческого разума и несчастного стечения обстоятельств. Они бывают разные. Забавные ( Алён, у нас по уровню ходят глаза, это нормально? ) и не очень ( CRASH BUG on the first level! FIX ASAP...).


Что меня всегда огорчало в вопросах починки багов - это многочисленные советы. Причем большинство из них, они как из страны эльфов. "Запустите дебаггер и в пошаговой отладке вы увидите что происходит". ОК, запустили. Под дебаггером у меня все хорошо. У меня вообще многопоточное приложение, его бессмысленно дебажить пошагово. Или я работаю со звуком, иногда проскакивает треск. Как такое пошагово отлаживать?
Вот еще совет. "Если у вас не работает релизная версия, запустите дебагную и посмотрите там". Запустили. В дебаге все нормально. И чего делать-то?
И это не такая уж и редкая ситуация, когда дебаг с релизом вот так кардинально различаются. Обычно здесь смотрять чем отличаются дебагная и релизная версия и что из этих различий оказалось причиной бага. Рассказ про такой баг.
Еще в различных форумах можно полчить мудрые советы, начинающиеся со слов "надо было". Крайне полезно, ага.

Поэтому тут реальные советы по поводу реальных багов. Не на все случаи жизни советы, но на многие.

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

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

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

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

Трудновоспроизводимые баги заслуживают самого пристального внимания. Здесь спасает анализ ситуации и придирчивое чтение кода. Когда, при каких условиях бага проявлялась? Почему именно тогда? Как повысить воспроизводимость? Если повезет, то через какое-то время у вас будет не один, а несколько случаев проявления баги, их можно сравнивать, искать закономерности.

Выводы могут оказаться неожиданными. Пример: Open Office не печатал по вторникам. Бага оказалась не в Open Office, а в утилите file, которая определяла тип файла. По вторникам она определяла файл, отправленный на печать, не как PostScript файл и получалось, что напечатать его нельзя. Дело в том, что в начало файла записывалась дата. Начиная с четвертого байта по вторникам там лежало Tue, от Tuesday. Для утилиты это было знаком того, что это файл Erlang JAM.

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

Одним из видов трудновоспроизводимых багов являются ошибки по памяти. Работа с "мусором", произвольная порча памяти и подобные. Тут можно смотреть чем именно была затерта память, на что это похоже. Отладка ошибок по памяти подробно проанализирована тут: Debugging Memory Corruption in Game Development.

Еще один вид трудновоспроизводимых багов - так называемые гейзенбаги, названные так в честь принципа неопределенности Гейзенберга. Они пропадают как только пытаешься их отладить. Тут можно анализировать проявления багов, пытаться поэкспериментировать с кодом, поизменять его, что может помочь найти причину возникновения гейзенбага. Подробная статья про гейзенбаги: Debugging Heisenbugs.

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

Процесс починки багов любят объяснять, разбивая его на шаги. Давайте я тоже шаги напишу что ли...
Итак, хорошая последовательность действий при починке багов:
1. Понять в чем именно состоит проблема. Воспроизвести.
2. Прикинуть как ее можно решить, выбрать наилучший способ.
3. Имплементировать.
4. Проверить что проблема решена и что новых не возникло. (!не надо пропускать этот пункт)
5. Подумать над тем, что к проблеме привело, чтобы исключить подобные проявления в дальнейшем.

Классическая плохая последовательность действий:
Вот, кажется тут! Да, починил. А, не, не тут и не починил, отдел тестирования опять поймал это... ОК, смотрю опять, опять чиню.
И так по кругу. Процесс и не думает сходиться. Старый код починки остается, он бессмысленно замусоривает проект и служит источником новых багов. Багов остается столько же или их количество растет.

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

if( value == 6 ) value = 5;
Ну или что-то такое же мерзкое, что решит проблему, хотя бы частично.
Хинт: иногда надо делать поиск в коде по FIXME. Сокрушаться над количеством найденного не надо. Надо чинить.

Байки:
Байка про стену
Байка про return в пустоту
Описание одного бага, другого наведённого бага, и одной отладки

Ссылки:
Дядя Дима - Рецепты отладки. 3 типа нестабильностей.
Дядя Дима - Теория ошибок. Нестабильности первого рода.
Дядя Дима - Теория ошибок. Нестабильности второго рода.
Дядя Дима - Теория ошибок. Нестабильности третьего и четвертого рода.