Почему американцы полетели на Марс, а мы — не полетели

fritzmorgen — 13.10.2012

Работавший над МКС программист прислал весьма печальный отчёт о состоянии дел в нашем космосе. Как вы помните, мне довелось какое-то время проработать программистом в одном бюджетном учреждении. Поэтому я склонен написанному в отчёте верить: выглядит он весьма правдоподобно.

Сейчас наш космос находится в довольно хорошем положении. У нас остался огромный советский задел, мы являемся по разным оценкам первой или второй космической державой мира. Финансовое положение России, опять-таки, позволяет тратить на космос любые разумные деньги.

Однако ужасающий бардак, который творится в нашей космонавтике, ещё только ждёт того Геракла, который будет его разбирать.

Я уверен, что проблемы с менеджментом, о которых пишет программист — только небольшая часть айсберга. Главная же проблема нашей космической отрасли — это… отсутствие понимания: зачем, вообще, она России нужна.

Вот американцы молодцы. Они приняли решение: космос им нужен для имиджа и для денег. Поэтому они зарезали у себя почти все проекты, не относящиеся к этим двум категориям.

Сейчас в Штатах развивается при поддержке государства частная космонавтика, и если всё сложится удачно, то через десять-двадцать лет благодаря бизнесу космические программы могут подешеветь в десятки и сотни раз. Америка таким образом сможет стать родоначальницей целой зарождающейся индустрии что однозначно интересно для этой супердержавы.

Также к «денежному космосу» следует отнести проект GPS, который уже сейчас приносит вполне понятные выгоды.

С другой стороны, в Штатах охотно реализуют пиар-проекты — дешёвые, но очень зрелищные шоу типа запуска марсохода Курьёзити на Марс. Уверен, что те два с половиной миллиарда долларов, которые Америка потратила на Курьёзити уже себя окупили. Так как подавляющее большинство жителей планеты банально не понимает, что МКС — которая обошлась миру примерно в сто раз дороже, чем Курьёзити — куда как более серьёзный и важный для человечества проект.

Я считаю, что сейчас Россия должна принять важное решение на самом высоком уровне. На уровне президента страны. О том, какой именно космос нам нужен, и о том, какие конкретно пафосные и амбициозные проекты Россия сделает приоритетными.

Пока такого решения принято не будет, Роскосмос, скорее всего, так и останется болотом, в котором 5% талантливых инженеров и управленцев будут тянуть на себе балласт из 95% случайно присосавшихся к космосу паразитов.

Итак, вот, собственно, рассказ о «космическом программировании» в России:

http://metadeus.wordpress.com/2012/09/18/как-у-нас-пишут-по-для-космических-аппа/

Для начала немного о себе: я работал в этой отрасли несколько лет и занимался непосредственно созданием бортового ПО и наземного обслуживающего ПО. В круг моих задач входили системы из контура управления и контроля аппарата, системной частью я не занимался, но взаимодействовать приходилось с ней достаточно плотно, т.к. реализуемые задачи были наиболее ответственными и ресурсоёмкими.

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

Все мои наблюдения оформлю в виде небольших тезисов.

1. Большая часть ПО написана не профессиональными программистами.
В основном функциональные системы написаны либо людьми имеющими инженерное образование связанное с летательными и космическими аппаратами, либо физиками и математиками, которым в силу необходимости пришлось научиться перекладывать свои знания на абстракции низкоуровневых языков программирования (типа C).

На результаты такого написания кода без слёз смотреть сложно.

2. При написании бортовой части ПО используются технологии двадцати- тридцатилетней давности.

Это и устаревшие морально операционные системы, и подходы к проектированию, реализации и тестированию программных продуктов. До сих пор можно найти документацию в виде подготовленных для печати на матричном принтере страниц, которая в цифровом виде хранится у какого-нибудь дядечки на персональном компьютере под управлением MS-DOS, в одному ему известном месте.

3. Для управления версионностью ПО не используются соответствующие программные продукты (Subversion, Git и т.п.).

Даже если они и используются, то находится один (а чаще несколько) уникумов, которые не в состоянии их освоить, но в то же время являющиеся незаменимыми людьми, поэтому половина проекта находится под контролем системы управления версиями, а половина нет, что в итоге приводит к тому, что система начинает больше мешать, чем помогать в разработке.

4. “Незаменимые” люди существуют.

Существуют люди без которых разработка встает на месте. Чаще всего это связано с тем, что такой “незаменимый” держит в голове некие тайные знания на протяжении десятков лет и активно сопротивляется их формализации и оформлению в виде документации.

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

5. Отсутствие систем документооборота.

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

В некоторых случаях система документооборота используется только для внешних по отношению к организации документов, для внутренней же документации используется переписка по e-mail, совещания и т.п.

6. Бесконечные как по времени, так и по количеству совещания.

Любое, даже самое мелкое действие для своей реализации может потребовать сбора совещания из 10-20 человек на срок 1,5-2 часа. Таких совещаний проводится 1-2 в день.

На каждом таком совещании обсуждается сразу все вопросы, причем обсуждаются они по группам, т.к. эти вопросы редко касаются всех присутствующих. В это время все остальные разговаривают между собой, играют или даже спят.

7. Отсутствуют методология и системы модульного тестирования.

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

8. Слабо развиты методология и системы интеграционного тестирования.

Чаще всего процесс слабо формализован и не поддается изменению. То есть, существуют формальные методики и люди занимающиеся тестированием, но получить что-то вменяемое от них практически невозможно.

Из-за в отсутствие системы учета багов ошибки могут заноситься в бумажные журналы, которые сам разработчик должен отслеживать и после этого бежать к тестировщику для выяснения обстоятельств возникновения ошибки.

9. Единственное, что спасает (далеко не всегда) ПО от багов это длительная многостадийная отработка.

Зачастую при поступлении ПО на заключительную стадию тестирования в первые же несколько дней находят сотни ошибок.

Иными словами, удивительно не то, что некоторые космические аппараты у нас не летают, удивительно то, что другие летают.

10. Бессбойность работы не является приоритетом при проектировании и реализации.

Многие предложения по повышению надежности ПО требующие лишь некоторого времени на реализацию отклоняются на том основании, что менеджер не видит или не понимает проблемы.

Даже простейшие системы контроля параметров попадающих на борт внедрялись с большим трудом под предлогами “оптимизации” или недопустимости изменения интерфейса существующих функций используемых десятком разработчиков.

11. Преждевременные псевдооптимизации при явной пессимизации.

В программах почти всех инженеров ставших программистами по необходимости можно увидеть псевдомикрооптимизации, которые делают код нечитаемым (например: использование операций сдвига вместо умножения, использование битовых операций для ускорения исполнения программы, отказ от выделения функций для экономии на вызовах и т.д. и т.п.).

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

Вместе с тем при компилировании релизной бортовой версии могут быть сознательно выключены все оптимизации компилятора и линковщика для обеспечения какой-нибудь редкоиспользуемой низкоуровневой функции (например: реализации бинарных патчей). Что в конечном счете приводит к тому, что бортовой код становится медленным как черепаха и выходит за такт жесткого реалтайма, и в свою очередь вызывает новую волну дебильных микрооптимизаций по включению тела функций в места их вызова и замены нормальных вычислений сдвигами и т.п.

12. Системная текучка кадров. Текучка кадров встроена в систему — такого слоя специалистов как грамотные опытные разработчики непредпенсионноговозраста практически нет. Есть два лагеря: профессионалы старой школы сопротивляющиеся всему новому и держащиеся за свои рабочие места (про них говорят: “Эти люди не читают книг — они их пишут”), и бывшие студенты ещё ничему не научившиеся и зачастую просто “отсиживающиеся” от призыва в армию.

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

Повторю на всякий случай ещё раз своё мнение о нашем космосе. Бардак, который обрисован в этих двенадцати тезисах, надо разгребать. И начать следует не с увольнения некомпетентных менеджеров и даже не с повышения зарплат неумелым программистам.

Наведение порядка надо начать с волевого решения — постановки больших и понятных целей, которых должна будет в обозримом будущем достичь российская космонавтика.

Оставить комментарий

Популярные посты:

• Ранее
• Архив