Программная инженерия: как создают ПО?
Как научиться создавать идеальное ПО?
Информатик Сергей Зыков рекомендует, что читать о программной инженерии
Институт программной инженерии, являющийся, по сути дела, колыбелью программной инженерии, был создан сразу после исторической конференции НАТО 1968 года, когда было принято решение, что эта дисциплина необходима. Он разрабатывает стандарты программной инженерии не только для США, но и для всего мира. Поэтому книга Software Architecture in Practice является глобальным ответом на самые важные вопросы о том, как с систематической точки зрения следует разрабатывать программные комплексы.
Когда мы говорим об архитектуре программного обеспечения, речь идет о том, из каких частей — систем, подсистем, модулей и так далее — должны состоять программные комплексы. Все эти компоненты должны связываться и взаимодействовать между собой, чтобы обеспечить определенные критерии: отказоустойчивость, надежность, безопасность, эргономичность, доступность и, естественно, не проигрывать при этом в производительности. Это с учетом того, что при работе с такими большими и сложными системами у вас могут быть десятки тысяч одновременных пользователей, каждый из которых очень интенсивно проигрывает различные сценарии обращения к данным. Книга о том, как, учитывая все эти условия, создавать программное обеспечение.
Архитектура программного обеспечения
Программист Мэтью Басс об усложнении программного обеспечения, возникновении новой дисциплины и системах клиент-сервер
За последние 40 лет программное обеспечение усложнилось, и появились очень специализированные задачи. В то время как компании стали вкладывать все больше и больше в развитие программного обеспечения, организации в целом стали больше полагаться на компьютеры. Возникли ситуации, когда необходимо поддерживать работу с большим количеством одновременно подключенных пользователей или систем, доступных круглосуточно, возникла необходимость менять систему со временем для поддержки широкого спектра ожидаемых потребностей. Это та область, где архитектура программного обеспечения возникла как дисциплина.
Программное обеспечение обладает такими свойствами, как доступность, масштабируемость, производительность. Необходимо обращать внимание на общее строение, чтобы иметь возможность предсказывать свойства. «Святой Грааль» этой дисциплины очень похож на другие инженерные науки, когда есть набор структур, известные свойства, которые поддерживаются или подавляются данными структурами, и есть возможность все проанализировать до постройки системы. Это и есть задача, на которой пытаются сосредоточиться люди. Этим они занимаются в научно-исследовательской работе.
Критерии качества на ранней стадии развития ПО
Доцент Университета Иннополис Мохамад Кассаб о новых подходах к разработке программного обеспечения
Программные системы характеризуют функциональные требования (что система делает) и критерии качества — как система ведет себя в плане различных наблюдаемых свойств, например времени отклика, безопасности, надежности. Ее также характеризуют ограничения и то, как система вписывается в эти ограничения. На рынке ПО функционально идентичные товары бьются за внимание клиентов, поэтому критерии качества становятся важным отличительным свойством на фоне конкурентов. Тем не менее на ранних стадиях разработки критериям качества уделяется очень мало внимания по сравнению с функциональностью, особенно в промышленности. Это, в частности, связано с уникальной природой критериев качества. Они субъективны, относительны, они часто интерактивны в том смысле, что реализация одного критерия качества может упростить или усложнить реализацию другого.
Критерии качества можно внедрять с помощью своеобразных «тактик». Тактика — это связующее звено между разработкой требований и архитектурой ПО. Архитектурная тактика — это проектные решения, которые можно интегрировать в архитектуру ПО с целью выполнения определенных критериев качества. Продумывая архитектуру программного продукта, разработчик опирается на определенные решения. Обычно их называют архитектурными шаблонами. В то время как архитектурные шаблоны представляют собой абстракции или наборы проектных решений, архитектурная тактика — это конкретное проектное решение, задача которого — выполнить определенный критерий качества.
Компиляторы для языков программирования
Профессор Университета Иннополис Евгений Зуев о «святом Граале» компьютерных наук
Когда программист пишет некоторую программу, решающую определенную, необходимую ему задачу, он пишет эту программу на некотором языке программирования. В процессе этого он оперирует терминами, близкими к той предметной области, с которой он имеет дело. А компьютер не понимает понятий, которыми оперирует программист. Он знает только довольно простые вещи: переменные, числа, регистры, ячейки, оперативную память, жесткие диски. Поэтому задача компилятора заключается в том, чтобы перевести понятия, близкие к предметной области программиста, в понятия, которыми манипулирует компьютер. Компиляторы — один из краеугольных камней Computer Science, наряду с операционными системами и базами данных. Это базис информатики.
История, связанная с языками программирования и компиляторами, насчитывает уже больше шестидесяти лет. Несмотря на это, трудно сказать, что это направление в Computer Science является застывшим. С появлением новых задач, которые решают компьютеры, появляется потребность в создании новых языков программирования и, соответственно, в разработке компиляторов этих языков. Задача разработки компилятора представляет собой одновременно научную и инженерную задачу. И хотя структура многих компиляторов очень похожа, предпринимавшиеся еще 40 лет назад попытки создания универсального языка и, соответственно, универсального компилятора закончились неудачей по довольно простой причине: проблем, которые решает программное обеспечение, очень много, они различны различны по своей природе.
Интеграция компиляторов в среды программирования
Профессор Университета Иннополис Евгений Зуев о современных подходах к созданию компиляторов
Продвинутая архитектура компиляторов, состоящая из нескольких компонент, взаимодействующих друг с другом и способных взаимодействовать с другими элементами интегрированных сред, требует нового инженерного подхода при их разработке. В начале 2000-х годов в лаборатории факультета ВМК МГУ мы начали работать над новой архитектурой компилятора для языка C++. Этот компилятор задумывался как совокупность компонентов, доступ к которым мог бы быть организован независимо друг от друга. Компилятор не представлял собой единую монолитную программу, это была именно совокупность компонент, и эти компоненты были спроектированы таким образом, чтобы обеспечить легкое включение в интегрированную среду.
Разработчики, которые занимаются созданием интегрированных сред и компиляторов, сталкиваются с большим числом проблем. И чисто инженерные проблемы здесь составляют только часть. Дело в том, что наряду с очень динамичным развитием информатики достаточно большое количество решений в настоящее время остаются теми же, которые были приняты 20–30 лет назад. Очень многие программисты до сих пор используют обычные командные компиляторы, которые были созданы в то время. Эти компиляторы, будучи спроектированными по-старому, очень трудно интегрировать в современную среду, потому что они разрабатывались как большие, монолитные программы.
Моделирование интеграции веб-сервисов
Профессор Университета Иннополис Мануэль Маццара о пи-исчислениях и перспективах микросервисов
Пи-исчисление — это модель параллельных вычислений, у которой существуют десятки аналогов и постоянно появляются новые, но пальма первенства по-прежнему принадлежит ей. Создатель этой модели — всемирно известный ученый Робин Милнер, лауреат премии Тьюринга. Выбирая тему докторской диссертации, я решил изучать теорию параллелизма и, в частности, ее применение в веб-сервисах. В результате нашей работы с профессором Козимо Ланеве в Болонском университете мы спроецировали язык BPEL на модель пи-исчислений. Для каждого акта извлечения информации конструкция из одного языка должна быть переписана в аналогичную конструкцию другого языка. Более того, нужно доказать, что для внешнего наблюдателя результат такого перевода будет постоянным. То есть поведение первой программы должно быть внешне точно таким же, как поведение второй программы; обе они могут работать одновременно, выполняя абсолютно одинаковые задания, что означает единство алгоритмов их работы и исполняемых функций.
В литературе описано много подобных техник, мы воспользовались одной из них, предварительно адаптировав ее под нашу специфику. Результатом должно быть доказательство либо эквивалентности двух языков, либо ее отсутствия. В своем труде мы доказали, что взятые нами языки не полностью равноценны. Несмотря на некоторые сходства, не существует достаточно оснований, чтобы называть их эквивалентными. В общем, все дело в переводе с языка на язык. И машинные языки в этом плане намного легче в силу своего более ограниченного характера.
«“Интернет вещей” может повлиять на будущее программного обеспечения»
Интервью с профессором Университета Иннополис Алешем Живковичем об этапах разработки программ, проблемах IT-индустрии и трендах в области создания ПО
— Что входит в процесс разработки программного обеспечения? Какие у этого процесса стадии и какие специалисты в него обычно вовлечены?
— Ключевой проблемой в разработке программного обеспечения является определение того, какой продукт мы собираемся создать и кто за это будет ответственным. Например, для проверки какого-либо решения нам нужен план тестирований. Мы можем начать разрабатывать его после того, как требования к продукту становятся ясными. Завершить этот процесс нужно к концу реализации задачи, ответственным за это может быть тест-менеджер. Иногда в ходе разработки вам уже предоставляется структура программного обеспечения или даже шаблоны, которые вы можете использовать.
Обычно процесс разработки программного обеспечения включает в себя разработку требований, анализ, проектирование, реализацию, тестирование и внедрение. Однако нужно совмещать этот процесс с проект-менеджментом, согласно которому проект состоит из нескольких фаз со своими ключевыми этапами, результатами, ресурсами и стоимостью.
Для большинства проектов требуется несколько разных специалистов, хотя все зависит от конкретного проекта. Например, во время моей последней разработки мы пользовались услугами разработчиков программного обеспечения, графических дизайнеров, психологов, врачей, специалистов по фитнесу и других. В идеале нужны люди с хорошими коммуникативными навыками, которые понимают технологию, специалисты по архитектуре программного обеспечения, менеджеры проектов и тим-лидеры, программисты и хорошие тестировщики. Также требуется обслуживающий персонал, который возьмет на себя заботу об инфраструктуре и средствах разработки.
— Как наука повлияла на методы создания программного обеспечения?
— Университеты и исследовательские лаборатории, включая Университет Иннополис, проводят фундаментальные исследования разных методов разработки программного обеспечения, собирают данные в индустрии для проведения эмпирических изысканий, устраивают контролируемые эксперименты со студентами и анализируют результаты. Эти результаты становятся известны практикующим разработчикам на конференциях и семинарах, посредством публикуемых статей и индивидуальных консультаций с различными группами разработчиков. У компаний есть свои насущные проблемы, и они часто отклоняются от исходной идеи о том, как разрабатывать программное обеспечение по выбранному методу. С нашей помощью методы и подходы меняются, проверяются и улучшаются на благо индустрии.
О предмете изучения
Программная инженерия
Чем программирование отличается от программной инженерии? Тем, что первое является некоторой абстрактной деятельностью и может происходить во многих различных контекстах. Можно программировать для удовольствия, для того, чтобы научиться (например, на уроках, на семинарах в университете), можно программировать в рамках научных разработок. А можно заниматься промышленным программированием. Как правило, это происходит в команде, и совершенно точно – для заказчика, который платит за работу деньги. При этом необходимо точно понимать, что нужно заказчику, выполнить работу в определенные сроки и результат должен быть нужного качества – того, которое удовлетворит заказчика и за которое он заплатит. Чтобы удовлетворить этим дополнительным требованиям, программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.).
Требуются также специальные усилия по организации процесса разработки. В общем виде это итеративно-инкрементальная модель, когда требуемая функциональность создается порциями, которые менеджеры и заказчик могут оценить, и тем самым есть возможность управления ходом разработки. Однако эта общая модель имеет множество модификаций и вариантов.
Разработку системы также необходимо выполнять с учетом удобств ее дальнейшего сопровождения, повторного использования и интеграции с другими системами. Это значит, что система разбивается на компоненты, удобные в разработке, годные для повторного использования и интеграции. А также имеющие необходимые характеристики по быстродействию. Для этих компонент тщательно прорабатываются интерфейсы. Сама же система документируется на многих уровнях, создаются правила оформления программного кода – то есть оставляются многочисленные семантические следы, помогающие создать и сохранить, поддерживать единую, стройную архитектуру, единообразный стиль, порядок…
Информатика ( computer science ) – это свод теоретических наук, основанных на математике и посвященных формальным основам вычислимости. Сюда относят математическую логику, теорию грамматик, методы построения компиляторов, математические формальные методы, используемые в верификации и модельном тестировании и т.д. Трудно строго отделить программную инженерию от информатики, но в целом направленность этих дисциплин различна. Программная инженерия нацелена на решение проблем производства, информатика – на разработку формальных, математизированных подходов к программированию.
Системотехника ( system engineering ) объединяет различные инженерные дисциплины по разработке всевозможных искусственных систем – энергоустановок, телекоммуникационных систем, встроенных систем реального времени и т.д. Очень часто ПО оказывается частью таких систем, выполняя задачу управления соответствующего оборудования. Такие системы называются программно-аппаратными, и участвуя в их создании, программисты вынуждены глубоко разбираться в особенностях соответствующей аппаратуры.
Бизнес-реинжиниринг (business reengineering) – в широком смысле обозначает модернизацию бизнеса в определенной компании, внедрение новых практик, поддерживаемых соответствующими новыми информационными системами. При этом акцент может быть как на внутреннем переустройстве компании так и на разработке нового клиентского сервиса (как правило, эти вопросы взаимосвязаны). Бизнес-реинжиниринг часто предваряет разработку и внедрение информационных систем на предприятии, так как требуется сначала навести определенный порядок в делопроизводстве, а лишь потом закрепить его информационной системой.
Связь программной инженерии (как области практической деятельности) с информатикой, системотехникой и бизнес-реинжинирингом показана на рис. 1.1.
Программное обеспечение
Определение. Будем понимать под программным обеспечением ( ПО ) множество развивающихся во времени логических предписаний, с помощью которых некоторый коллектив людей управляет и использует многопроцессорную и распределенную систему вычислительных устройств.
Свойства. Таким образом, ПО является сложной динамической системой, включающей в себя технические, психологические и социальные аспекты. ПО заметно отличается от других видов систем, создаваемых (созданных) человеком – механических, социальных, научных и пр., и имеет следующие особенности, выделенные Фредериком Бруксом в его знаменитой статье «Серебряной пули нет».
H Программная инженерия отличается от программирования в черновиках Перевод
Некоторым людям не нравится термин «программный инженер» из-за метафоры с инженерным делом. Но эта статья не про термин. Если он вам не нравится, замените на Автора программ, Умельца по программному обеспечению или Программного художника!
Под «программным инженером» я подразумеваю человека, который считает своей профессией написание качественного ПО. Этот человек использует науку и статистику в своей профессии, и не относится к ней как к способу зарабатывания денег.
Умение программировать не делает вас программным инженером.
Научиться программированию может любой. Это просто. Кто угодно может создавать простые программы, которые будут работать для авторов и на их машинах, но совершенно не обязательно, что те же программы будут работать и для других людей.
Я люблю приводить такое сравнение: все могут развлекаться пением в душе, но приходя в гости, вряд ли кто-то включит записи своего «исполнения». Все предпочтут слушать профессионалов.
Нужны ещё примеры? Пожалуйста:
Простейшее определение программирования: дать компьютеру инструкции что-то сделать с какими-то входными данными, чтобы получились какие-то выходные данные.
Инженерия программного обеспечения — это проектирование, написание, тестирование и сопровождение компьютерных программ для решения пользовательских задач. Это создание устойчивых и безопасных решений, которые выдержат проверку временем и будут решать какие-то неизвестные задачи, связанные с задачами очевидными.
Программные инженеры всё знают о решаемых ими задачах и предоставляемых решениях, об ограничениях этих решений, об их влиянии на приватность и безопасность.
Если кто-то не понимает сути задачи, то его нельзя допускать к программированию решения.
Менталитет решения
Программные инженеры не воспринимают свою карьеру как просто написание программ. Они мыслят категориями удовлетворения потребностей и решения проблем. Это важно, поскольку не для всякой проблемы нужно писать программу. Какие-то задачи решаются с помощью уже имеющихся программ или их комбинации. Появление каких-то проблем вообще можно предотвратить, если действовать на упреждение. Проектирование хороших программ зачастую требует планирования, чтобы избежать проблем в будущем.
Интеллектуалы решают проблемы, гении их предотвращают.
Альберт Эйнштейн
Для решения сложных задач обычно требуется написать несколько программ. В каких-то случаях программы должны работать параллельно, в каких-то — последовательно. Некоторые проблемы можно решить, если обучить пользователей.
Прежде чем писать программу, инженер должен спросить себя:
Качество кода
Замечательные программы понятны и читабельны, их можно легко расширить, они прекрасно работают с другими программами, а сопровождение не превращается в кошмар. Качество кода — не предмет для обсуждения, корявые обходные решения из-за дедлайна или эмоций — неприемлемы.
Один из важнейших аспектов программной инженерии заключается в том, что при проектировании продукта с нуля в него закладывается возможность расширения. Приложения изменяются, это естественно. Пользователям понадобится больше возможностей, они захотят ещё большего удобства использования.
Сама по себе какая-то часть ПО не слишком полезна. По-настоящему полезные свойства программное обеспечение обретает, когда многочисленные компоненты взаимодействуют друг с другом, обмениваются данными и совместно предоставляют пользователям информацию и интерфейсы.
Всё это нужно учитывать при проектировании программ. Какие сообщения они должны принимать? Какие события отслеживать? Какие сообщения отправлять? Как будет устроена аутентификация и авторизация?
Ещё одна важная черта замечательных программ — это чистота кода, а не поголовье тестов или количество отчётов о покрытии. Простой вопрос: этот код читабелен для других? Или ещё лучше: я, автор этого кода, смогу понять его через несколько недель?
В информатике есть лишь две трудности: инвалидация кэша и присвоение имён.
Фил Карлтон
Читабельность кода гораздо важнее, чем вы думаете. К сожалению, пока ещё не придумали хороших метрик чистоты кода. Отчасти помогают хорошие шаблоны и методики проектирования, но зачастую этого мало. Грамотные программные инженеры просто развивают в себе чутьё на чистоту кода, полагаясь на свой опыт и интуицию. Здесь очень уместна метафора с писательством: знание огромного количества слов не поможет вам писать осмысленные и понятные тексты.
У меня нет времени писать короткое письмо, так что пишу длинное.
Марк Твен
С программами возникают трудности. Возможность легко решать их — неотъемлемый признак хорошего ПО. Возникающие в программах ошибки должны сопровождаться понятными сообщениями, должен вестись централизованный журнал ошибок для последующего анализа. Когда приходит отчёт о новой ошибке, ответственный за её исправление человек должен иметь возможность отладить. У него должна быть возможность влезть в потроха системы и прочитать информацию о контексте исполнения в любой момент времени. Должна быть возможность простой сверки ожиданий от любой части системы.
Среды и тестирование
Когда программные инженеры пишут программы, они проверяют, будут ли их детища работать в самых разных средах, на машинах с разными ресурсами, в разных часовых поясах. ПО должно работать на экранах всевозможных размеров, с любой ориентацией. Также программное обеспечение должно работать при ограниченном объеме памяти и вычислительной мощности.
К примеру, если вы создаёте браузерное приложение, то оно должно работать во всех основных браузерах. Если создаёте приложение настольное, то чаще всего он должно быть в версиях под Mac и Windows. Если создаёте приложение, зависящее от внешних данных, то оно должно работать даже при медленном или временно пропадающем подключении.
При создании ПО инженеры стараются предусмотреть все возможные сценарии и закладывают их в планы тестирования. Нужно проверять штатную работу приложения, когда не происходит ничего неожиданного (happy path), а также планировать тестирование всех возможных сбоев и проблем. Некоторые программные инженеры сначала пишут код для так называемых тестовых случаев, то есть симуляций всевозможных сценариев, а затем пишут желаемый код, который успешно выдерживает передряги тестовых ситуаций.
Программные инженеры понимают, что требования к ПО нередко размыты и неполны. Талантливый инженер понимает, не как написать решение, а что должно в него входить.
Стоимость и эффективность
В большинстве случаев программные инженеры могут решать проблемы быстро. Если вы считаете, что найм опытных программистов означает повышение расходов, то подумайте об этом ещё раз. Чем более опытного программиста вы берёте, тем быстрее он будет писать устойчивые, аккуратные, надёжные и простые в сопровождении решения. А это приведёт к снижению общих расходов в долгосрочной перспективе.
Не забывайте и о стоимости исполнения программ. Каждая программа использует компьютерные ресурсы, а они не достаются за «спасибо». Программные инженеры напишут эффективные программы, экономно расходующие ресурсы. Например, можно применить кэширование часто используемых данных, но это лишь один из тысяч возможных инструментов и способов ускорения программ и повышения их эффективности.
Начинающий программист может дать вам простое решение, но его использование может стоить вам и вашим клиентам гораздо дороже, чем использование более эффективного продукта опытного программиста.
Удобство использования
Хорошие программы проектируются с учётом удобства использования (UX). Есть множество исследований и открытий на тему взаимодействия человека с компьютером. И чем больше мы узнаём, тем лучше могут быть наши приложения.
Приведу несколько примеров, чтобы вы прочувствовали всю важность удобства использования:
Надёжность, защищённость и безопасность
Пожалуй, это важнейшие свойства приложений, по которым можно отличить профессионалов от любителей. Профессионалы понимают, что должны писать безопасные и защищённые решения.
Приложение должно быть устойчивым к плохому вводу данных, плохим состояниям и плохим способам взаимодействия. Этого ОЧЕНЬ трудно добиться, и поэтому мы слышим истории о том, как люди гибнут из-за программных ошибок.
Пользователи будут вносить в приложения плохие или ошибочные данные. Кто-то сделает это намеренно, стараясь сломать программу и проникнуть в представляемые ею ресурсы. Человек, якобы ответственный за недавнее фиаско Equifax, обвинил компанию в том, что она во всём публично доступном ПО не предусмотрела возможность ввода плохих и вредоносных данных.
Проблема защищённости связана с вводом не только плохих и вредоносных, но также и нормальных данных. Если пользователи забывают свои пароли, то сколько попыток даётся на ввод? Вы блокируете пользователей после определённого количества попыток? А если ещё кто-то пытается блокировать пользователей? Вы разрешаете вводить пароли при незашифрованном соединении? А если попытка входа совершается с необычного для этого пользователя IP-адреса, компьютера, системы? Что вы делаете, если действия пользователя выглядят автоматизированными?
Что вы делаете для защиты своих пользователей от межсайтового скриптинга и подложных запросов, от атак «человек посередине» и простого социального фишинга? У вас есть запасная стратегия на случай DDoS-атаки на ваши серверы? Всё это лишь малая часть проблем, которые вам нужно предусмотреть.
Защищённые программы не хранят важную информацию в виде обычного текста, а используют одностороннее шифрование с очень устойчивыми ко взлому алгоритмами. Это запасная стратегия на случай компрометации программы и данных. Чаще всего зашифрованные данные окажутся для хакеров бесполезны.
ПО переходит в плохое состояние, его нужно привести в порядок. Неожиданные проблемы могут возникать даже с лучшими программами. Если вас это не волнует и вы к этому не готовитесь, то вы не профессионал в создании ПО, вы просто пишете небезопасные программы.
Дефекты в программах невидимы. Возможности нашего разума спрогнозировать и предотвратить эти дефекты не безграничны. Поэтому программные инженеры осознают ценность хороших инструментов, помогающих писать корректное и безопасное ПО.
Инструменты
Несомненно, нам нужно более разнообразные и качественные инструменты. Они играют большую роль и часто недооцениваются.
Если бы нам сегодня ещё приходилось слать файлы по FTP для развёртывания приложений? Если бы нам приходилось отлаживать проблемы с сетью и производительностью без Chrome DevTools? Представьте, насколько неэффективно сегодня писать JavaScript без ESLint и Prettier!
Если вы JavaScript-разработчик и вынуждены выбирать какой-то один плагин для редактора кода, берите ESLint.
Нужно приветствовать любой инструмент, сокращающий цикл обратной связи при написании кода. Для меня стало откровением мнение Брета Витора об изобретении моментальных визуальных представлений для того, что мы создаём. Расширение спектра инструментов и их улучшение — один из путей в светлое будущее. Если вы ещё не смотрели выступление Брета, отложите все дела и немедленно посмотрите.
Когда я нахожу новый замечательный инструмент, то сожалею лишь о том, что не нашёл его раньше. Более совершенные инструменты помогут вам программировать лучше. Найдите их, используйте, цените и, если можете, улучшайте их.
Выбор языка имеет значение. Типобезопасность имеет значение. TypeScript (и Flow) — лучшее, что произошло с JavaScript. Статичный анализ кода важнее, чем вы думаете. Если вы им не пользуетесь, то ваш код остаётся уязвимее к будущим проблемам. Не пишите код без системы статичной типизации. Если ваш язык не имеет статичной типизации, то либо меняйте язык, либо найдите траспилятор. Сегодня транспиляторы достаточно сообразительны и работают, читая комментарии в коде. Я считаю, именно так в будущем будет выполняться проверка типов в языках, изначально её не поддерживающих.
Эволюция программной инженерии
Никто не может стать программным инженером за два месяца, или шесть, или даже за год. Вы не научитесь программной инженерии в летнем лагере. Я занимаюсь ею больше 20 лет, и до сих пор учусь. Я стал достаточно уверенно называть себя опытным программистом лишь после десятилетия обучения, а затем проектирования, создания и поддержки приложений, которыми пользуются тысячи людей.
Программная инженерия — занятие не для всех, но каждый должен учиться решать свои собственные проблемы с помощью компьютеров. Если вы можете научиться писать простые программы, то учитесь. Если можете научиться использовать распространённые программные сервисы, то делайте это. Если можете научиться использовать open-source ПО, то обретёте много возможностей.
Программная инженерия должна развиваться вместе с задачами. Будущее этой профессии в том, чтобы обычные пользователи могли использовать свои компьютеры без нескольких лет предварительного обучения. Чтобы пользователи могли сами решать простые задачи с помощью лёгких в применении инструментов. Затем программные инженеры перейдут к созданию более совершенных инструментов, к решению более сложных известных проблем, и будут всячески предотвращать появление неизвестных.