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

вторник, декабря 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 человека. Ну и небыстро там все происходит, я подозреваю.

16 коммент.:

Yuri комментирует...

А есть такие конторы, в котрых чмырят за баги? ...

Алёна комментирует...

2Yuri:

А есть такие конторы, в котрых чмырят за баги? ...

Да :-(
Я часто встречала такой подход: тестеров не нанимаем, потому что денег жалко, вместо этого глумимся над программистами. Получается дорого и неэффективно.

1master комментирует...

NASA очень круты. Но основная проблема - скорость разработки.

the_chiffa комментирует...

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

nvy комментирует...

>первые три страницы о том, какие замечательные люди там работают.<
А может именно это - самая важная информация, а не всякие там технические детали?

Алёна комментирует...

2nvy:

А может именно это - самая важная информация, а не всякие там технические детали?

Не, там только пространное изложение, никакой информации.

Max комментирует...

Кажется, очевидно, что эти правила работать не могут (ну откуда знать заранее все подробности ТЗ? И что за детский лепет про то, что надо искать, почему ещё может останавливаться рука?) -- но ведь именно в NASA, в JPL, писали программы для Mars Rovers! А их нельзя не уважать после того, как они перезалили прошивку с Земли, когда компьютер не мог загрузиться;) Плюс к этому система, расчитанная на три месяца жизни и работающая уже почти шесть лет, это ого-го!

Sergej комментирует...

Я знаю, что я не прав, но разве первым комментарием не должно было быть "вот пе....сы"?
За эти деньги и это время можно было бы написать робота, который "всё" проверяет. Работа о том, как написать такого робота была бы в сто раз интересней и полезней.

Gregory Liokumovich комментирует...

А не про NASA ли была сказка про две группы программистов, одна из которых считала в метрах, а вторая в дюймах, после чего упал спутник?

Очень часто подобные идеалистические описания не соотсветсвют внутренним реалиям.

Евгений Охотников комментирует...

2Max & Gregory Liokumovich:

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

А из ярких провалов еще можно вспомнить катастрофу Ариан 5, когда в его бортовом ПО использовали фрагмент кода из Ариан 4 без дополнительной проверки.

Max комментирует...

Ну, Ariane 5 это Европа, а не NASA :) Я писал про JPL, как раз подозревая, что в NASA более одной группы программистов ;-)

Alex Che комментирует...

Данный пример описывает скорее крайнюю ситуацию - практическая неограниченность в средствах, неизменные требования к проекту. Это не то, чем может похвастаться среднестатистическая группа разработчиков. Соотвественно, не стоит ожидать что подобные практики подойдут и для нее, по крайей мере без какой-либо адаптации.
Хотя 3 и 4 - довольно интересно, не раз читал, но применить на практике пока не довелось.
2 - это что-то типа code review?

Алёна комментирует...

2Alex Che:
2 - это что-то типа code review?

угу, суровый code review

Max комментирует...

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

dtjurev комментирует...

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

nvy комментирует...

>Ну у нас как обычно - ТЗ пишется в процессе разработки.<Большинство контор работают по реакции (стимул-реакция) и по принципу "Главное - в драку влезть,а там видно будет..."