В комментариях к посту Искусство отладки Евгений Охотников дал ссылку на статью про то как разрабатывается софт в 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 человека. Ну и небыстро там все происходит, я подозреваю.
Quaternions and spherical trigonometry
6 дней назад
16 коммент.:
А есть такие конторы, в котрых чмырят за баги? ...
2Yuri:
А есть такие конторы, в котрых чмырят за баги? ...
Да :-(
Я часто встречала такой подход: тестеров не нанимаем, потому что денег жалко, вместо этого глумимся над программистами. Получается дорого и неэффективно.
NASA очень круты. Но основная проблема - скорость разработки.
Треугольник "быстро-дешево-качественно". NASA близки к одной из вершин. Можно ли считать это успехом? В том смысле, что они успешно справляются с поставленной задачей - да. В том, что они утерли нос всем другим разработчикам - не уверен :)
>первые три страницы о том, какие замечательные люди там работают.<
А может именно это - самая важная информация, а не всякие там технические детали?
2nvy:
А может именно это - самая важная информация, а не всякие там технические детали?
Не, там только пространное изложение, никакой информации.
Кажется, очевидно, что эти правила работать не могут (ну откуда знать заранее все подробности ТЗ? И что за детский лепет про то, что надо искать, почему ещё может останавливаться рука?) -- но ведь именно в NASA, в JPL, писали программы для Mars Rovers! А их нельзя не уважать после того, как они перезалили прошивку с Земли, когда компьютер не мог загрузиться;) Плюс к этому система, расчитанная на три месяца жизни и работающая уже почти шесть лет, это ого-го!
Я знаю, что я не прав, но разве первым комментарием не должно было быть "вот пе....сы"?
За эти деньги и это время можно было бы написать робота, который "всё" проверяет. Работа о том, как написать такого робота была бы в сто раз интересней и полезней.
А не про NASA ли была сказка про две группы программистов, одна из которых считала в метрах, а вторая в дюймах, после чего упал спутник?
Очень часто подобные идеалистические описания не соотсветсвют внутренним реалиям.
2Max & Gregory Liokumovich:
эта статья не о всем NASA, насколько я помню. Там речь только об одном подразделении, которое занимается управлением стартовыми двигателями.
А из ярких провалов еще можно вспомнить катастрофу Ариан 5, когда в его бортовом ПО использовали фрагмент кода из Ариан 4 без дополнительной проверки.
Ну, Ariane 5 это Европа, а не NASA :) Я писал про JPL, как раз подозревая, что в NASA более одной группы программистов ;-)
Данный пример описывает скорее крайнюю ситуацию - практическая неограниченность в средствах, неизменные требования к проекту. Это не то, чем может похвастаться среднестатистическая группа разработчиков. Соотвественно, не стоит ожидать что подобные практики подойдут и для нее, по крайей мере без какой-либо адаптации.
Хотя 3 и 4 - довольно интересно, не раз читал, но применить на практике пока не довелось.
2 - это что-то типа code review?
2Alex Che:
2 - это что-то типа code review?
угу, суровый code review
На самом деле, если средств много, а точность нужна отменная, можно двум командам написать две реализации, а потом гонять тесты и сверять checkpoint'ы -- если есть расхождения, искать ошибку. Вот это суровый code review :)
Соглашусь с nvy. "Какие замечательные люди там работают" - это один из главных факторов успеха. Вторая команда программистов для проверки - тоже рулит. Особенно, когда разработчик сам подробно объясняет проверяющему то, как работает программа. При этом, во-первых, проверяющий находит неучтённые ньюансы, а во-вторых, сам разработчик в процессе объяснения часто вспоминает детали, о которые проморгал.
>Ну у нас как обычно - ТЗ пишется в процессе разработки.<Большинство контор работают по реакции (стимул-реакция) и по принципу "Главное - в драку влезть,а там видно будет..."
Отправить комментарий