Два мира разработки ПО

16. January 2008, 19:32 Занимательное, Избранное, Компьютеры и ПО

Вот, на примере космического аппарата MESSENGER (почему на его примере – будет понятно в конце заметки), хочу поделиться таким наблюдением из мира разработки программного обеспечения.

Точнее, там есть два мира.

Первый – очень известен, с ним соприкасаются очень многие (в основном, на правах пользователей). Этот первый мир – разработка “офисного” ПО. “Офисное” – конечно, условное название. Тем не менее, большая часть этого ПО используется именно в офисной работе. Это ПО работает на настольных компьютерах, серверах. К этому же миру относится и типичное современное web-программирование. Здесь в ходу такие “типы” ПО: текстовый процессор, редактор изображений, бухгалтерская программа и др. И известны такие “характеристические” понятия: Windows, Visual Basic, Delphi и т.п.

Хорошо известно, что в мире “офисного” ПО можно смело выдать на рынок недоделанный, не отлаженный продукт с кучей ошибок (потому что главное – регулярно и быстро выпускать новую версию, опережая конкурентов; особенно рельефно эта тенденция видна в современных web-сервисах, которые теперь уже публикуют в неработающем виде, заявив, что это альфа-версия, ну или “бета” – особенной разницы на практике нет). Массовый клиент, понятно, уже приучен к ошибкам в программах и к тому, что нет никаких гарантий работоспособности. Это давно известная тенденция.

Вторая тенденция вот в чём: в связи с тем, что комплектующие для офисного (и, конечно, серверного) компьютерного оборудования всё дешевеют и дешевеют (в пересчёте на вычислительную мощность), то разработчики из “офисного” мира готовы напрочь забыть об оптимизации и алгоритмов, и кода. Эти разработчики говорят так: “Лучше взять побольше железа – это выйдет дешевле, чем год возиться с оптимизацией”, “Пока вы оптимизируете ваш код, память подешевеет ещё в два раза” и тому подобные вещи.

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

Это свой мир. Со своими ценностями.

А есть второй – совершенно другой: разработка специального ПО для встроенных систем. Здесь не только в ходу неизвестные в “офисном” мире понятия из теории сложности, но и совсем другие представления о надёжности. Потому что ошибка в “текстовом процессоре” грозит лишь секретарше (да и угроза лишь в том, что придётся набирать полэкрана текста заново). Ошибка в ПО управления спутником связи грозит многомиллионными убытками, а иногда – реальной катастрофой. Хуже того, в случае со спутником – его разработчикам придётся отвечать. (Понятно, что в “офисном” случае всякая ответственность с разработчиков заранее “списана” условиями лицензирования.)

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

В мире встроенного ПО совсем не работают методы типа “за год память подешевеет вдвое”. Почему? Вот тут-то мы и приходим к примеру с космическим аппаратом MESSENGER.

Внимание, пример: MESSENGER стартовал летом 2004-го года. На орбиту вокруг Меркурия аппарат должен встать весной 2011-го года. Понятно, что как бы ни подешевели за это время на Земле компьютерная память и процессоры – “проапгрейдить” аппарат в районе Меркурия вряд ли получится. А вот загрузить на борт новое ПО – можно, с Земли.

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

Кстати, в мире встроенного ПО, на “борту изделий”, Windows совсем не в ходу, как ни странно. Там свои операционные системы.

Так вот, к чему это длинное наблюдение: оказывается, многие и многие люди, связанные с разработкой ПО, нынче думают, что существует только первый, “офисный” мир и его законы универсальны. Про то, как делают управляющее ПО, скажем, для ракеты “воздух-воздух”, эти “офисные” разработчики даже и не задумываются. И это, наверное, правильно – зачем бы им?

Адрес записки: https://dxdt.ru/2008/01/16/1003/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 10

  • 1 <t> // 18th January 2008, 10:54 // Читатель fezzz написал:

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

  • 2 <t> // 18th January 2008, 12:42 // Читатель Kenzo написал:

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

  • 3 <t> // 19th January 2008, 10:08 // Читатель Sergey написал:

    Когда за разработку “офисного ПО” начнут платить как за разработку встраиваемого, тогда можно будет обсуждать.

  • 4 <t> // 20th January 2008, 14:33 // Читатель sbase написал:

    К сожалению в нашей стране разработкой встроенного ПО, для бортовых систем (те же спутники), занимаются только госпредприятия где зарплаты такие что лучше уйти оффшор и писать какую-нибудь лабуду. Так, как 90% аутсорса это разработка ПО без требований по надежности и устойчивости.
    Второй аспект это то что во встраиваемом ПО задачи настолько специфичные что разработчик, если не уходит через 2-3 года то, теряет навыки разработки ПО для настольных систем и продолжает “сидеть” в этой нише никому ничего не рассказывая.

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

  • 5 <t> // 20th January 2008, 18:38 // Читатель Laggi написал:

    Там не два мира, там намного больше. И в мире “встроенного по” тоже есть разнообразные “подмиры”. Как и в мире “офисного”. Хотя я бы не стал называть его “офисным”, это скорее мир “персональных компьютеров”.
    Скажем (для примера) в мире персональных компьютеров есть “интерфейсники” (это вот ближе всего к вашему определению “офисного по” – там главное сделать удобный интерфейс пусть и программа работает с ошибками), есть алгоритмисты (их правда в “офисном мире” всё меньше и меньше), есть по-архитекторы (визионарии так сказать)…
    Есть свой мир CAD’а, который в свою очередь делится на строительный, архитектурный, инженерный, “электронный” и т.д…
    Есть мир компьютерных игр, который близок по трехмерке к каду, но другой – алгоритмы и требования к программам совершенно другие, не считая художественной графики…
    Есть мир серверов – там тоже свои заморочки.
    Embedded программисты тоже неоднородные, и задачи у них разнообразные. Есть задачи “реального времени”, есть задачи программирования “бытовой техники”, есть задачи требующие максимальной надежности, есть разннообразные микропроцессоры с различной архитектурой.
    Частично все эти миры переплетаются – скажем программирование SONY PS3 очень схоже с embedded программированием – параллельные процессы, отдельная память на каждый чип, синхронизация потоков в реальном времени и т.д.
    А есть еще “ученая” область… Тут важнее всего алгоритмы. Биологи для примеру. Секвенсоры, специфические алгоритмы поиска, алгоритмы обработки больших массивов данных…

    В общем насчет “2х миров” – это вы пошутили видимо.
    Такие дела.

  • 6 <t> // 6th June 2008, 02:17 // Читатель Путин Андрей написал:

    Первые разработчики мыслят еще и так:

    можно делать более грамотный, красивый и “объектно-ориентированный”, детерминированный код.

    К примеру, “пустое” приложение C# + NET.Framework 1.1 может занимать около 20Мб памяти во время работы.

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

    Кстати, о поисковиках: это как ракеты “воздух-воздух”, реальная нагрузка бывает такой, что никакие расчеты не спасают (спростие у разработчиков Yandex).

  • 7 <t> // 22nd June 2008, 21:27 // Читатель TheBits написал:

    ПО с большим неоптимизированным кодом называется bloatware.

  • 8 <t> // 3rd August 2008, 04:09 // Читатель Макс Лапшин написал:

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

    Это, конечно же, упирается в главную проблему алгоритмики, суть которой в том, что полностью описанный алгоритм и есть 100% правильно работающая программа. Т.е. если описать в какой-то модели алгоритм, то дальше вопрос конвертации его в любой другой язык программирования ? вопрос техники. Конечно же, трудоёмкость такой работы совпадает с просто созданием программы с точностью до выразительности используемого языка программирования.

    Так, например, доказательство корректности алгоритма сортировки пузырьком, приводимое на этих лекциях на мехмате ? это просто полный вырвимозг!

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

    Но опять же, речь идет о сильном приближении количества ошибок к 0, но абсолютный ноль количества ошибок пока что остаётся абсолютным нулем.

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

  • 9 <t> // 3rd August 2008, 21:56 // Читатель arcman написал:

    > когда можно раз в 15 минут делать рестарт сервера?

    убивал бы за такой подход ]:->

  • 10 <t> // 22nd August 2008, 20:56 // Читатель Артур написал:

    Спасибо за статью, я вот всегда хотел хорошо научится программировать на языка C++, php, это ведь так интересно… Да только времени в нашей жизни просто катастрофически нехватает :(