Почему написать программу и построить программу — не одно и то же

Почему написать программу и построить программу — не одно и то же

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

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

Момент, когда код стал дороже железа

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

А что случилось именно в те годы? Произошла тихая, но важная перемена. Раньше главные деньги уходили на «железо» — на сами вычислительные машины. Но постепенно затраты на создание программ выросли настолько, что сравнялись со стоимостью оборудования. Написание кода перестало быть дешёвым приложением к дорогой технике и само превратилось в статью расходов, которую нельзя игнорировать.

Любитель и мастер: в чём пропасть

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

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

Чтобы разговор был точным, дадим определения.

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

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

А теперь главное определение, ради которого всё и затевалось.

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

Обратите внимание на слово «путь». Речь не о разовом действии, а о целом маршруте — от первой идеи до поддержки готового продукта.

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

Четыре кирпича, на которых всё держится

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

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

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

Третий кирпич — код: свой и чужой. Инженер решает, что можно взять из готовых процедур, а что придётся написать заново под созданную архитектуру на выбранном языке программирования. Здесь и рождается сам код — частью новый, частью заимствованный.

Четвёртый кирпич — тестирование и сборка. Продукт проверяют, вылавливают ошибки и собирают в готовое изделие. Финальный аккорд, без которого стройка не считается завершённой.

Три набора вопросов, которые задаёт себе профессионал

Самое интересное в работе инженера — не команды, которые он пишет, а вопросы, которые он себе задаёт. На каждом этапе эти вопросы совершенно разные. Пройдёмся по трём главным наборам.

На старте: а нужна ли вообще новая программа

Перед тем как что-то создавать, при знакомстве с задачей инженер спрашивает себя:

• Можно ли решить обнаруженные проблемы сложной системы в рамках одной программы — написанной или уже существующей?
• Какие конкретные задачи будут по отдельности решать все созданные или используемые программы?
• Как облегчить и ускорить решение — за счёт сторонних разработок, нового кода или их сочетания?

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

На чертёжной доске: как всё соединить

Когда решается вопрос о том, писать ли продукт целиком или использовать готовые процедуры с добором недостающего кода, вопросы меняются:

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

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

На испытательном стенде: выдержит ли продукт жизнь

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

• Работоспособность. Держится ли продукт в разных условиях — при других ресурсах техники, начальных настройках, операционных средах и программном окружении?
• Эффективность. Экономит ли он ресурсы, надёжен ли, аккуратен ли в исполнении, устойчив ли в работе, удобен ли в установке и сопровождении?
• Удобство. Комфортно ли пользователю с ним работать?
• Стойкость. Не рассыпается ли продукт при некорректном вводе начальных данных и ненадёжном взаимодействии частей системы?
• Безопасность. Есть ли защита от внешних воздействий и нет ли скрытых, не заявленных разработчиком возможностей или дефектов?
• Понятность сбоев. Сопровождаются ли изменения и ошибки сообщением, ясным любому пользователю?
• Журнал событий. Правильно ли работает системный журнал, фиксирующий все ошибки — так, чтобы их мог разобрать сторонний программист, а не только автор кода?
• Инструменты разработки. Применяются ли самые современные средства и языки, сокращающие циклы обратной связи при написании продукта?

Каждый из этих вопросов — как проверка моста нагрузкой перед тем, как пустить по нему движение. Пропустишь один — и трещина проявится в самый неподходящий момент.

Ради чего всё это: цель и процессы

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

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

Есть у дисциплины и своё сердце — процесс программной инженерии (Software Engineering Process, SEP). За этим термином стоит обсуждение, поиск и воплощение на практике верных последовательностей действий — тех способов выполнения задач, которые действительно работают правильно и эффективно.

Эти процессы тесно вплетены во весь жизненный цикл программного обеспечения. А цикл этот включает четыре крупные стадии:

• разработку или приобретение — продукт либо создают, либо покупают готовый;
• сопровождение — его поддерживают в рабочем состоянии;
• вывод из эксплуатации — со временем аккуратно снимают с дистанции.

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

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

Коротко о главном

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

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