разработчик
0,0
рейтинг
2 декабря 2012 в 18:29

Разработка → Марсианский код: лекция о том, как программировали Curiosity

На конференции HotDep 2012 Джерард Хольцман из Лаборатории реактивного движения НАСА прочёл лекцию о том, как обеспечивалась надёжность и корректность кода для марсохода Curiosity. Часовая лекция рассказывает, какие методики, стандарты кодирования и инструменты разработки применялись программистами НАСА, чтобы написать три с половиной миллиона строк сверхнадёжного кода, который в автономном режиме посадил Curiosity на поверхность Марса и обеспечивает работу всех его систем и приборов.

Лекцию можно посмотреть онлайн на сайте usenix.org, или скачать в формате .mp4 (228 Мб).

Илья Сименко @ilya42
карма
526,7
рейтинг 0,0
разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (22)

  • +49
    Описали бы кратко какие-то интересные моменты и тонкости.
    Или хотябы просто список ключевых слов что используется.
    Сейчас совершенно нет времени смотреть доклад, а потом могу вовсе забыть.
    • +68
      Посмотрел. В целом, ничего экстроординарного:

      — Стандарт кодирования с проверкой по коммиту: lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf (язык программирования С, 32 правила).
      — Ежедневная сборка со статическим анализом кода (5 разных анализаторов, пересисляются на 20:30, полный список всего что выполняется в рамках сборки на 36:00), warning считается ошибкой, штрафы за сломанный билд.
      — Code review с использованием Scrub (некая внутренняя тулза, наружу не отдают, судя по описанию и скриншотам — примитивный аналог phabricator / crucible с агрегатором ошибок и варнингов компиляции / анализаторов, подробнее тут: spinroot.com/gerard/).
      — Юнит тесты.
      — Ежедневные интеграционные тесты, штрафы за сломанный интеграционный тест.
      — Некая штука, которую они называют 'logic verification with model checker' для ключевых частей программы. Скорее всего, это математическая доказательство корректности на основании модели.
      — Wall of shame — доска почета по количеству ошибок/варнингов и прочего, герои TOP-3 демонстрируются на весь офис. Никто не хочет быть в топе :).
      • +5
        Штрафы, «герои» по ошибкам. Какое-то очень некрасивое отношение к программистам.
        • +34
          Вообще ужасное, мне кажется. С другой стороны — ответственность за миллиарды долларов, внимание всего человечества и право сказать «я программировал марсоход». Немало.
          • +2
            С другой стороны, «сломать билд» и «уронить марсоход в след за „фобосом“» — разные вещи.
            • +7
              Не снежинки на главную делают.
        • 0
          Красивое отношение к продукту.
      • +3
        Спасибо за выжимку!
  • НЛО прилетело и опубликовало эту надпись здесь
    • +5
      В видео эти вопросы затрагиваются, так например для написания 3.8 миллиона строк кода было задействовано 40 девелоперов, в течении 5 лет и они в среднем писали 10 строк полностью тестируемого кода в час. А написано это всё на VxWorks.
      • +15
        Написано это всё на чистом С, а работает под VxWorks.
        • 0
          Виноват. Я в этой теме очень поверхностно разбираюсь.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Вы видео посмотрите :) Там рассказывается что тестеров было несколько сотен и был очень жёсткий Code review.
        • +2
          Ну да, а как же отдел маркетинга и продаж? :)
    • +4
      40 х $100k/year x 5year = 20 лямов зелени стоил код. И тут не учтены тимлиды, архитекторы и прочие нужные товарищи.
      • +8
        Скорее всего намного больше, $100k/year как то очень мало для safety-critical.
        • –16
          8 штук в месяц это мало? Да они зажрались.
          • +5
            $100k/year это средняя зарплата разработчика в США. И это не так уж и много. Если посчитать сколько надо заплатить налогов, за страховку, за жилье, за детский садик и прочее, то останется сильно меньше половины.
          • 0
            Код должен быть невероятного качества
            • +1
              Вот такой бы код в виде модулей, да в open source.
  • +6
    Вспомнилось из «Сто правил руководителей проектов NASA»
    Правило 5. Руководителями проектов могут быть порочные, презренные и совершенно неприятные люди. Бездушные, нерешительные копуши или болтуны – нет.

    Правило 61. Большая часть оборудования изготавливается не так, как планировал конструктор. Это связано с размещением оборудования, плохим пониманием конструктивных решений или с плохим пониманием спецификации оборудования.

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

    Правило 79. Следующий год – это всегда год с нормальным финансированием и графиком работ. Такой следующий год наступит на пятидесятом году вашей карьеры.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.