Хотелось бы рассказать вам немного о разработке ПО для космических аппаратов «у нас», в отличие о того, что мы наблюдаем «у них».
http://kholeg.wordpress.com/2006/11/20/они-пишут-правильную-вещь/
Для начала немного о себе: я работал в этой отрасли несколько лет и занимался непосредственно созданием бортового ПО и наземного обслуживающего ПО. В круг мои задач входили системы из контура управления и контроля аппарата, системной частью я не занимался, но взаимодействовать приходилось с ней достаточно плотно, т.к. реализуемые задачи были наиболее ответственными и ресурсоёмкими.
В общем, мой код уже летает в составе 2 модулей МКС, ещё один готовится улететь, а так же в составе нескольких спутников. Я не являюсь профессиональным инженером космических систем, но являюсь профессиональным программистом, поэтому и оценивать могу только часть касающуюся разработки ПО.
Все мои наблюдения оформлю в виде небольших тезисов.
1. Большая часть ПО написана не профессиональными программистами. В основном функциональные системы написаны либо людьми имеющими инженерное образование связанное с летательными и космическими аппаратами, либо физиками и математиками, которым в силу необходимости пришлось научиться перекладывать свои знания на абстракции низкоуровневых языков программирования (типа C). Соответственно и на результаты такого написания кода без слёз взглянуть сложно.
2. При написании бортовой части ПО используются технологии 20-30 летней давности. Это и устаревшие морально операционные системы, подходы к проектированию, реализации и тестированию программных продуктов. До сих пор можно найти документацию в виде страниц напечатанных на матричном принтере, которая в цифровом виде хранится у какого-нибудь дядечки на персональном компьютере под управлением 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 года работы понимают, что никаких перспектив и возможностей не предвидится и уходят на большие зарплаты. Но на их место уже готов новый набор из студентов.
источник
Комментарии
1 mid (Вчера 20:08)
Дочитал статью до фразы «низкоуровневых языков программирования типа «C». Дальше изучать сей креатиф нет смысла.
Аффтар дебил.
Но любой тезис нуждается в доказательствах. По пунктам:
1.Самый распрофессиональный програмер без знания инженерных тонкостей изделия наваяет такого, что легче его сразу расстрелять. Поэтому таких немытых, патлатых, шизанутых горе программеров, как аффтар в оборонке нет. Патронов на них жалко.
2. Аффтар видать не догадывается, что его творчество сначала надо скомпилировать в машинный код. Ему подавай только visual среду.
3. Используется, когда это надо.
4. Слава богу, такой дури, как тупой супервайзер, поставленный над светлыми головами разработчиков, у нас в оборонке почти нет. А как аффтару хотелось бы...
5. Название «Teamcenter» аффтару видимо ничего не говорит, если он пеарит устаревшие технологии.
6. Аффтар, блеат, пиндосских и ивропейских бесконечных совещаний не видел?
7. Присутствуют. Это основа основ.
8. Аффтар сам-то понял, что сказал?
9. Я на него, на дебила посмотрю, как он будет запускать продукт без отработки.
10. Аффтар типичный «перманентный улучшайзер». Таких надо давить рублем и сроками.
11. Аффтар никогда не программировал напрямую в машинных кодах
12. Надеюсь, аффтар сдриснул из оборонки и больше туда не вернется. Такая текучка кадров только на пользу.
Кто сомневается в моих выводах, может зайти на главную страницу блога аффтара. Полный ахтунг: Читатель «Сноба» и «Слон.ру», халявщик (любитель краудфандинга), оголтелый атеист, и т.д.
Наверняка «еврей и гей».
2 scccyn (Вчера 21:02)
Как бы не было обидно товарищу mid, автор исходной статьи хоть наивен и молод, но в главном прав. Все перечисленные проблемы действительно были (и наверняка никуда не делись). Знаю об этом не по наслышке, так как сам много (а именно - 7) лет проработал программистом в оборонке.
Когда толковый человек приходит в такую фирму, он сначала пытается что-то улучшить в этом болоте, а потом увольняется. Благо в коммерческих фирмах и зарплата больше, и ригидных до окостенения мозга руководителей меньше. Занимает этот процесс осознания безнадежности болота обычно от одного года до трех.
Ну а что касается людей из оборонки, то среди них очень много тех, кто истово верит, что эффективно работает. Возможно mid из их числа. Это грустно и смешно, у меня ощущение что эти люди даже близко не имеют понятия, что значит эффективно работать; насколько несовершенен их подход к работе по сравнению с тем, что считается естественным даже в средненьких коммерческих фирмах.
5 mid (Вчера 21:27)
Г-н scccyn, а не поделитесь ли примерами своей эффективной работы?
Со своей стороны приведу примеры:
Я сейчас делаю МиГи и с программированием непосредственно не связан. Но мой родной брат (работаем вместе) в своё время клепал мозги (т.е писал код) таким комплексам, как А-135, «Club» (он же «Калибр»), стратегические КР «Гранат».
По его мнению, аффтар бредит.
Не скажу за средненькие коммерческие фирмы (вам виднее), но об эффективности этих систем можете много почерпнуть даже из открытых источников.
3 NightWolfM (Вчера 21:02)
Опять же очень странно, что автор не упомянул про плачевную ситуацию с производством полимерной продукции в России. И не закончил статью постановкой в пример читателям некого поросёнка(борова), укравшего трактор и сбежавшего за границу.
4 scccyn (Вчера 21:11)
А на самом-то деле все не так.
Вот товарищ NightWolfM точно знает, что лучшие программисты работают именно в оборонке. А в коммерческих фирмах работают те, кого не взяли на хорошее оборонное предприятие.
6 mid (Вчера 21:40)
Понятно, что вас, г-н scccyn, интересует в программировании в основном финансовая сторона вопроса.
Вам просто не понять, как может профессионал в NX8 от Сименса прозябать в какой-то там российской оборонке, хотя всякие игроделы, Боинги и Эрбасы платят в разы больше.
Для справки:
1. Есть такая профессия - Родину защищать.
2. Владимир Путин подписал указ о материальном стимулировании лучших работников ОПК:
http://file-rf.ru/ne
источник