Фобос-Грунт - полёт на свалку

Balancer> Это в ту же тему, что и предложения наказания лётчикам за разбитый самолёт в виде выплаты его стоимости и прочее. Обсуждали уже.

Не, Ром, есть вариант — платить такую ЗП, на которую можно купить самолёт и КА. Ну или такую, с которой можно вычитать.

S.I.> Видишь ли половина вменяемых людей именно на таких условиях и работает. Начиная от водителя-профессионала и кончая прорабом на стройке, главным инженером завода, капитаном корабля и т.п.

И как же волей случая прораб огребает проблем на ярды? А водитель?

Mishka> И как же волей случая прораб огребает проблем на ярды? А водитель?

Ну, водитель может волей случая свалить в жерло вулкана фуру с бриллиантами

au> Система на примере: Если ты честно ошибёшься (это проверяемо аудитом), то ты её не получишь. Если же ты нахалтурил или скрыл дефекты, поставив свою визу на недоделку, а потом оно как-то вылезло, тогда суши сухари, даже если аппарат долетел.
А что значит проверяемое аудитом?
У меня тут свой Фобос приключился на днях.Есть некое устройство достаточно сложное и работоспособное.Вношу механические изменения и прошу программиста внести изменения в программу,заливаем новую и наблюдаем выгорание половины электроники,причем до тла
Я на него "мать,мать,мать....",а он мне "да я туда внес пару изменений всего,вот смотрите сами,они не могли так вылезти" и приводит свои доводы,я с ним соглашаюсь.Один косяк аппаратный лично мой на лицо,я не предусмотрел защиту для таких случаев,дополнительный предохранитель спас бы мой "фобос".Ну ладно, прошу его все проверить,он мне; "-я угробил кучу времени,все проверил,все правильно,я не понимаю -все должно работать". Я частично восстанавливаю схему,опять ему "ну не работает же!",он мне "не может быть!Хммм,а вот закомментируйте вот эту строчку и давайте посмотрим"...млять,надо ли говорить что все заработало.На что мне было сказано примерное так,это было внесено для улучшения правильности расчетов и прочее бла бла бла. Спрашивается какой аудит обнаружит вот такой компот,я же с ним согласился что ход его рассуждений был верный,но он говорит что возможно не учли уже ошибки на уровне программного обеспечения самого микроконтроллера,скажем баг или косяк разработчиков микросхемы...
Похоже что только полномасштабная модель и может вскрыть возможный косяк и программистов и аппаратчиков.

AndreySE> А что значит проверяемое аудитом?

Best Kept Secrets of Peer Code Review

11 Best Practices for Peer Code Review

AndreySE> он мне "не может быть!Хммм,а вот закомментируйте вот эту строчку и давайте посмотрим"

Вот таких экспериментаторов надо заворачивать ещё на стадии интервью, самое позднее — на испытательном сроке.

AndreySE> Спрашивается какой аудит обнаружит вот такой компот,я же с ним согласился что ход его рассуждений был верный

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

AndreySE> Похоже что только полномасштабная модель и может вскрыть возможный косяк и программистов и аппаратчиков.

Почитайте Ganssle. И выставьте счёт программисту за его "agile" творчество

au> Вот таких экспериментаторов надо заворачивать ещё на стадии интервью, самое позднее — на испытательном сроке.
Да нет,программист он реально хороший,работает на серьезную компанию,опыта вагон,просто моя работа вроде как хобби для него,но периодически на косяки я с ним налетаю.
Так вот по первой же ссылке фактически предлагается методология,багов может и не найдем,но класс игрока определим.А тут реально класс очень высокий,человек выдает гораздо больше чем я прошу и значительнее шире,причем зачастую охватывая что я упустил.Так что его работу проверять нужен не менее высочайший игрок и то боюсь такая же фигня будет.Может лучше штук пять прототипов и все отработать до полета?Летают же обитаемые,контроль качества выше?

AndreySE> Да нет,программист он реально хороший,работает на серьезную компанию,опыта вагон,просто моя работа вроде как хобби для него,но периодически на косяки я с ним налетаю.

Хороший программист пишет хороший код — это единственный критерий оценки. Если он спалил ваше железо в ходе эксперимента в стиле "а попробуй закоментить", значит он либо сделал это нарочно, либо он плохой программист (для вас). Ничего личного, сугубо объективная оценка.

AndreySE> Так вот по первой же ссылке фактически предлагается методология,багов может и не найдем,но класс игрока определим.

Баги найдутся неизбежно, потому что они всегда есть.

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

Не-не-не. Я понял суть этой системы, она проста. Собираются несколько пиров, и идут по коду: а что это делает? а почему это так? а что будет если? — за что их глаз зацепится. Это вдобавок к автоматическим контроллерам и прочим благотворным средствам. Всё в целом радикально снижает количество дефектов.

> Может лучше штук пять прототипов и все отработать до полета?Летают же обитаемые,контроль качества выше?

Если все пять будут дефектные — чем лучше? У него есть ещё материал по количеству дефектов в коде. Я не помню точные цифры, но вроде в среднем коммерческом коде один дефект на 20 строчек. Запомнил что в ядре настольной оси при такой статистике порядка 50000 дефектов, что объясняет многое. Так вот, сочетание правильных инструментов, методов и людей позволяет делать код, которому можно доверить управляемые объекты из списка выше. Почему Ф-Г делался не так — вопрос для следствия, если оно будет. Это нормальная практика, а не подвиг какой-то, или достижение.

Bredonosec> это?

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

В принципе, можно перепутать никелевое покрытие ВЫВОДОВ, сиречь ножек, с алюминием, поскольку они у этих транзисторов бывали и матированными, внешне похоже. Но вот беда, оба варианта, и никель, и золото, выпускались параллельно еще с 60-х годов. То есть речи о том, что сменили технологию, быть не может, она уже была задолго до того.

И вообще я не верю в версию с транзисторами. Ибо они в таком виде выпускались до 90-х годов. Если б тогда действительно вылезли такие косяки, то от такого варианта явно бы отказались. Однако - нет...

au> Хороший программист пишет хороший код... Баги найдутся неизбежно, потому что они всегда есть.

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

au> Хороший программист пишет хороший код — это единственный критерий оценки.

Именно так. А вот критерий «хорошего кода» уже далеко не однозначен (не путать с «идеальным кодом»). Ну, как хороший писатель не обязан быть хорошим редактором.

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

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

И так далее, и тому подобное.

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

И в итоге программист зевнёт дедлок при редком сочетании параметров, тестировщики не предусмотрят один из выходов за пределы оптимальных параметров, разработчики железа не предусмотрят аппаратного ограничения, а корабль запустят с небольшими отклонениями от заданных параметров. И система навернётся. Кого потом винить в этом? Программиста, что не предусмотрел особой ситуации? Тестировщиков, что не сделали проверок за рамками узкого ТЗ? Составителей ТЗ, которые не подумали, что по этому параметру можно получить такие значения? Разработчиков аппаратуры, которые подумали, что софт всё переварит? И так далее…

Ckona> Если нечто подобное уже существует, изучается ли в современных ВУЗах ?

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

Забавно, что среди моих личных знакомых, как в России, так и за рубежом, я не могу навскидку вспомнить хороших программистов, оканчивавших специализированный программистский ВУЗ. Ну, ладно, когда я сам в середине 1990-х «почти в космической отрасли» работал, тогда соответствующих ВУЗов вообще не было, народ программировал кто с АСУП, кто с матфаков, кто с радиоэлектроники, кто вообще с никаким боком не соотносящихся специальностей (помню программиста, который закончил пищевой институт ). Но и сейчас ситуация мало поменялась, как я могу судить.

Ckona> Что является аналогом тех приемов, которыми исключается подавляющая часть "машиностроительных багов" ? Если нечто подобное (типа, культура составления техзаданий, с методиками проверки) уже существует, изучается ли в современных ВУЗах ?

Наверно где-то есть ВУЗы, где будущих программистов учат чему-то хорошему. Я таких не видел. Слышал что есть такие, там неутомимые оптимисты даже вводят курс Ады в надежде научить молодёжь чему-то хорошему. Но обычно в ВУЗе программирование преподают очень плохие программисты, которые вовсе не зарабатывают на жизнь программированием. Никаких намёков на культуру или методики, отличные от моды (типа agile), я не заметил. По сути это находится на уровне хакерства. Ничего даже отдалённо напоминающего дисциплинированный умный computer/software engineering из прошлого я там не заметил.

Ckona> Возможно, я недостаточно осведомлен, но в обозримых рамках вижу некую дыру, или скорее разрыв - между бесконечными вариантами софтверного продукта и общепринятыми запретами "так нельзя", которые и составляют основу стандартов/документирования, то есть культуры разработок.

Есть очень небольшая (остальные считают её вымершей) группа людей, которые делают качественные программы. У них свои методы, жёсткая дисциплина при разработке, культура и прочее. Результаты соответствующие — их изделия летают в небе, в космосе, управляют всякими ответственными объектами. Список был выше — это один пример, одна контора. Когда в космос улетает С++ из рук хакеров, природа настойчиво возвращает их на землю

Вот кстати, почему авторы фаерфокса так и не научились освобождать память, и оно регулярно валится, и иногда валит с собой винду? Они сто раз поменяли интерфейс и добавили сто тысяч фишек, из которых 99995 не нужны, но не исправили столь грубые ошибки? Просто им эти ошибки ничего не стоят, им всё равно, природа тут не угрожает ничем, а программа предоставляется на условиях "as is" бесплатно. И всегда будет, потому что дырявое корыто большего не стоит, каким бы красивым оно ни было. Считайте это иллюстрацией к ответу выше.

Balancer> Lenta.ru: Прогресс: Названа окончательная версия потери "Фобос-Грунта"

Глава Роскосмоса признал, что подобный сбой стал возможен в результате недоработки - электроника аппарата не была рассчитана на воздействие космического излучения, а этого

 

Или некоторые работники НПО Лавочкина не знают о существовании космического излучения, или всем было настолько пох, что даже в питерский Actel позвонить было впадлу, не говоря уже о том, чтобы своё заказывать

au>> Хороший программист пишет хороший код — это единственный критерий оценки.
Balancer> Именно так. А вот критерий «хорошего кода» уже далеко не однозначен (не путать с «идеальным кодом»).

Однозначен Хороший код — это код, который удовлетворил заказчика кода. Для АМС это надёжность. Для игры-однодневки это что-то совсем другое. Но в любом случае заказчик говорит "хорошо" или нецензурно — это момент однозначности. С заказчиком тоже не всё просто, он обычно не знает чего вообще хочет, но зафиксировать требования — вопрос контрактных отношений, а не программирования или любой другой работы. Никто из разработчиков не примет требования "сделать мост на 30% длиннее", когда он уже строится. У программистов с этим трудно, особенно трудно с этим у дебилов из отделов продаж, маркетинга и прочих передовиков дэволюции.

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

В такой форме утверждение справедливо. Но почему он должен быть красивым внутри и быстро пишущимся? Я вот ставил требования, мне сказали что сделают за пять недель. Сделали за пять месяцев, причём ТЗ менялось только в сторону упрощения (блоками работы) и до того как эти части начинали разрабатываться. И всё равно вот так получилось. Что с ними делать? Спрос превышает предложение, так что никакого стимула и дисциплины у них нет.

А насчёт интерфейса, во-первых он нужен далеко не везде, но его везде зачем-то впихивают. Помнишь типичный интерфейс поисковика? Куча всевозможной фигни, от которой глаз уворачивается. А потом дизайнер всея руси сделал ya.ru. А теперь я вообще пишу в строку броузера "g ищу тот-то", и не хожу ни на какие страницы поисковиков. Вот она, красота.

Balancer> — Пишем высоко надёжный код и он оказывается недостаточно эффективен в рамках имеющейся аппаратуры.

Добавить цилиндров, но не в последний день, а в самом начале. Заложить запас 100% по основным параметрам: скорости, памяти, портам, чему угодно. На тупые вопросы ответ один: нужно столько.

Balancer> — Делаем высокую оптимизация и получаем плохо расширяемый код, на котором при последующей модификации зевнём хитрую ошибку

Замораживать дизайн. Расширять только блоками расширения, пока не достигнут предел. То что написано и работает, не трогать уже никогда.

Balancer> — Пишем наглядный документированный код и не укладываемся в сроки разработки

Заложить запас 100% по срокам.

Balancer> И так далее, и тому подобное.

И так далее Разве это трудно?

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

До определённого предела это так. Но если программист делает одни лишь ошибки, так что целая группа их за ним ловит и исправляет, программиста надо просто заменить, он дефектный. Если ошибок одна на 100 линий кода, тогда по-твоему, и будет хорошо. Примерно такая цифра достигается через Ravenscar и его методы — на порядок меньше ошибок, меряли.

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

Всех перечисленных без разбора. Это результат их коллективного труда.

x000> Или некоторые работники НПО Лавочкина не знают о существовании космического излучения

Могли не знать. Я видел таких спутникостроителей своими глазами. Про излучения они узнали от меня, когда проект уже шёл несколько лет

Mishka> И как же волей случая прораб огребает проблем на ярды? А водитель?
Поработай - узнаешь. Какая тебе разница сколько ярдов-неярдов если светит небо в клеточку или "внесудебное решение"? Это только программы продают "как есть" и ни за что не отвечают по законам штата Калифорния

Balancer> По-моему, нормального обучения качественному программированию сегодня в ВУЗах вообще нет. Уровень кодера — это, вообще, уровень техникумов. И кодить в ВУЗах не учат. Хорошая качественная теория, которую преподают в ВУЗах инженерно-программистской специальности, помогает качественному программировнию как помогает, скажем, термодинамика в разработке какого-нибудь теплообменника. Вроде, и нужно, но и практическая польза редкой бывает.

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

S.I.> Поработай - узнаешь. Какая тебе разница сколько ярдов-неярдов если светит небо в клеточку или "внесудебное решение"? Это только программы продают "как есть" и ни за что не отвечают по законам штата Калифорния

Ты сказал, тебе и приводить. Не надо прятаться за общие фразы. Ещё раз — какие?

Kuznets> нам именно программирование два первых года давали - бейсик, паскаль, си, ассемблер.
Нашёл чем пугать, братан...
А про алгол - слыхал, надеюсь?
А про PL/2 или PL/M?
А про (не к ночи будь помянут) APL?
В общем, "ты меня своей шпаной не пугай"

Anika> А про алгол - слыхал, надеюсь?
Anika> А про PL/2 или PL/M?
Anika> А про (не к ночи будь помянут) APL?
Anika> В общем, "ты меня своей шпаной не пугай"

По моему ты что то перепутал. Братан я на программиста не учился. А об этой фигне конечно же слышал. Это все детали, совсем не главные.

Anika> А про алгол - слыхал, надеюсь?

А про который? А то их много. Algol 60, Algol W, Algol 68, Algol 68 Revised or Algol 74. Да и в 78 году добавили moduleи, nestы, eggы.

Anika> А про PL/2 или PL/M?

PL/I и PL/M — да.

Anika> А про (не к ночи будь помянут) APL?

Не трожь хороший язык. Один из первых с ленивыми вычислениями.

Anika> В общем, "ты меня своей шпаной не пугай"
Да запросто.

x000>> Или некоторые работники НПО Лавочкина не знают о существовании космического излучения
au> Могли не знать. Я видел таких спутникостроителей своими глазами. Про излучения они узнали от меня, когда проект уже шёл несколько лет
Вот-вот. Кинулись искать проблемы с софтом. Может он тоже приключился, но распутывать "клубок" отказов, ИМХО, надо со связи. Была ли предусмотрена ближняя связь? Похоже, нет, если не прав -поправьте. Даже если использовали дальнюю - можно было сразу предусмотреть снижения мощности в сотни раз? Видимо, можно. Ну и в итоге, должна получится ситуация - запрос с Земли - "Кто там?" - ответ - "Это я, Фобос". И так в любой момент связи. Если этого нет - все разговоры о софте носят только предположительный характер. Вот если бы после установления линка с КА он не реагировал бы на команды - тогда поиск в софте и контрофакте. Хотя контрофакт мог быть и в приемнике

serg14> Была ли предусмотрена ближняя связь? Похоже, нет, если не прав -поправьте.

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