вторник, декабря 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 комментариев:

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

    ОтветитьУдалить
  2. 2Yuri:

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

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

    ОтветитьУдалить
  3. Анонимный29/12/09 14:33

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

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

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

    ОтветитьУдалить
  6. 2nvy:

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

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

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

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

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

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

    ОтветитьУдалить
  10. 2Max & Gregory Liokumovich:

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

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

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

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

    ОтветитьУдалить
  13. 2Alex Che:
    2 - это что-то типа code review?

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

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

    ОтветитьУдалить
  15. Анонимный4/1/10 14:48

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

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

    ОтветитьУдалить