Comments 22
Описали бы кратко какие-то интересные моменты и тонкости.
Или хотябы просто список ключевых слов что используется.
Сейчас совершенно нет времени смотреть доклад, а потом могу вовсе забыть.
Или хотябы просто список ключевых слов что используется.
Сейчас совершенно нет времени смотреть доклад, а потом могу вовсе забыть.
Посмотрел. В целом, ничего экстроординарного:
— Стандарт кодирования с проверкой по коммиту: 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 демонстрируются на весь офис. Никто не хочет быть в топе :).
— Стандарт кодирования с проверкой по коммиту: 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 демонстрируются на весь офис. Никто не хочет быть в топе :).
В видео эти вопросы затрагиваются, так например для написания 3.8 миллиона строк кода было задействовано 40 девелоперов, в течении 5 лет и они в среднем писали 10 строк полностью тестируемого кода в час. А написано это всё на VxWorks.
40 х $100k/year x 5year = 20 лямов зелени стоил код. И тут не учтены тимлиды, архитекторы и прочие нужные товарищи.
Вспомнилось из «Сто правил руководителей проектов NASA»
Правило 5. Руководителями проектов могут быть порочные, презренные и совершенно неприятные люди. Бездушные, нерешительные копуши или болтуны – нет.
Правило 61. Большая часть оборудования изготавливается не так, как планировал конструктор. Это связано с размещением оборудования, плохим пониманием конструктивных решений или с плохим пониманием спецификации оборудования.
Правило 63. Программное обеспечение не перекрывает всех параметров аппаратной части (меняются требования, высок процент стоимости полётов, требуются процедуры подтверждения и т.д.). Дополнительная особенность заключается в необходимости поиска возможных ошибок. То есть необходимо, чтобы сначала отработала основная система, после чего могут начаться звонки и свистки. Никогда не отказывайтесь от уже работающей версии программного обеспечения, даже если весь остальной мир будет утверждать, что более новая версия программного обеспечения работает. Это совершенно необходимо, чтобы иметь планы на случай непредвиденных обстоятельств.
Правило 79. Следующий год – это всегда год с нормальным финансированием и графиком работ. Такой следующий год наступит на пятидесятом году вашей карьеры.
Sign up to leave a comment.
Марсианский код: лекция о том, как программировали Curiosity