«Программная инженерия — это приложение инженерных принципов к разработке программного обеспечения». В данной статье хочу выразить пару своих мыслей по поводу software engineering и свое видение этого предмета.
А как еще иначе разрабатывают программное обеспечение?
Например, программу можно разрабатывать «на лету», по мере надобности. Без всякого плана набросать скриптик, который делает какую-то рутинную задачу и на этом все. В таком процессе разработки нет никакого тщательного планирования, дизайна архитектуры, плана тестирования. Написали, работает, и ладно. Если понадобится улучшать, перепишем заново с нуля, проявятся баги — подлатаем на лету.
Обычно такой подход используется, когда надо написать небольшую программку, которая выполнит какое-то некритическое задание, без учёта затрат на поддержание этого кода в будущем. Например: прототип для проверки какой-то идеи, тестовое задание на интервью, лабораторная работа для сдачи в конце семестра, студенческий проект для выставки талантов, perl-скрипт для домашней библиотеки фотографий, pyhton скрипт при изучении основ машинного обучения, демо-программа для презентации.
Но в реальной жизни случается, что такой подход используется для написания и чего-то большего, чем утилитка, прототип или скрипт. Либо из-за дикой спешки, либо из-за неопытности программистов и их руководителей, а то и из-за полной безответственности абыкакеров. Такой стиль программирования называется «code and fix«, «ad hoc programming«. В результате такого «программирования» рождаются на свет «костыли», «заплатки», «подпорки». Слепленные на коленке уродцы выкатываются в PROD и держатся там «на честном слове», вызывая головную боль команды поддержки и нанося ущерб бизнесу.
Историческая перспектива
В начале 50-ых годов на заре появления первых компьютеров программы для них писались непрофессионалами. Тогда все компьютеры использовались для вычислений по научным проблемам, и программы писали сами учёные, которых программированию никто не учил, так как учить было некому. Путем проб и ошибок учёные писали программы как раз именно в стиле ad hoc и вырабатывали некоторые навыки и приёмы, которые потом вошли в практику создания программ как коммерческих так и правительственных проектов.
Чем больше компьютеры внедрялись в жизнь человека, тем дальше распространялась вот такая практика написания программ в стиле ad hoc.
Так как компьютеры были дорогими, позволить себе их могли только крупные корпорации или правительство. На Западе главным заказчиком компьютеров и программного обеспечения для них было Министерство обороны США. К концу 60-ых годов Министерство обороны США озаботилось назревающим кризисом, так называемым software crisis. Программы, написанные в стиле ad hoc, не выдерживали никакой критики: проекты по их созданию всегда опаздывали по срокам, перерасходовали бюджет и страдали низким качеством результата и требовали больших усилий по поддержке и исправлению ошибок. Нужно было что-то делать, и в 1968 году под эгидой НАТО на конференцию были собраны лучшие умы в области компьютерного программирования, которым было дано задание найти выход из этого «кризиса». Все эти лучшие умы признали, что больше писать программы на коленке по-любительски нельзя. Текущее состояние процесса разработки ПО они называли словом «tinkering» (дословно «латание») — т.е. ПО писалось путем проб и ошибок, бессистемным латанием на скорую руку найденных багов в спагетти-коде.
По мнению участников конференции, чтобы удовлетворить растущие требования в качественном ПО сам процесс разработки такого ПО должен быть поставлен на научную, инженерную основу. Процесс разработки в их представлении должен быть формализирован и регламентирован, чтобы гарантировать требуемое качество в требуемые сроки в рамках заданного бюджета.
Например, когда заказчик заказывает у строительной организации здание, он видит чертежи, расчеты, документацию, видит план строительства здания, видит прогресс его создания и понимает, когда здание будет закончено, сколько материалов на него уйдет, сколько денег он в конечном счете будет стоить. Заказчик видит, что архитектурой дома занимается архитектор, возведением стен — квалифицированные каменщики, прокладкой электропроводки — профессионал-электротехник.
Заказчикам ПО хотелось такого же. Особенно, когда заказчики — военные ведомства. Все, что они видели до этого, это кучка программистов-самоучек чешет голову, бегает вокруг компьютера с распечатками и перфокартами, отлавливает баги и в течение года отчитывается, что проект на 80% готов.
Так был придуман термин software engineering — программная инженерия — когда разработка ПО организовывается по тем же принципам, по которым создаются здания, плотины, турбины, самолеты, дороги, т.е. все инженерные проекты реальной жизни.
Программирование как профессия
В 1957 году Эдсгер Дейкстра хотел указать в свидетельстве о браке «программист» в качестве своей профессии. Ему отказали на том основании, что такой профессии не существует. 70-80е годы ушли на становление «программирования» как серьезной профессии. Превращения ее в инженерную профессию «де факто«.
Активным пропагандистом программной инженерии стал Стив Макконнелл, который работал в Microsoft. Он выпустил множество книг, одна из которых («Профессиональная разработка программного обеспечения«) стала своеобразной библией программной инженерии.
Его книга — это попытка превратить программирование из хобби, ремесла гениев-одиночек в массовую инженерную профессию со всеми присущими инженерной профессии атрибутами. По мнению автора, программная инженерия должна стать дисциплиной, которую преподают в университетах, предметом научных исследований и книг, конференций и диссертаций. Книга была написана в 1999 году и сейчас 20 лет спустя многое, о чем мечтал автор, было реализовано в жизни.
Обучение программированию как профессии
По мнению Макдоннелла, если программирование это инженерия, то как и у всех инженерных дисциплин у программирования должен быть некий свод знаний, который должен определять, что должен знать программист, чтобы называться программным инженером.
Эта сумма знаний представлена в документе SWEBOK, с которым может ознакомиться любой желающий.
А вот примерный учебный план, который рекомендует Ассоциация вычислительной техники для обучения студентов программной инженерии.
Сравните этот учебный план с учебным планом по компьютерным наукам. Обратите внимание, как отличаются они друг от друга. В учебном плане по инженерии больше упор делается на практику, а в учебном плане по компьютерным наукам — на науку и теоретические знания.
А на данной странице можно посмотреть на все учебные планы в историческом разрезе. Интересно проследить, чему было нужно по мнению Ассоциации учить в 2001 году, и чему — сейчас. Последний раз планы обновлялись в 2014 году, предполагается, что они будут обновляться каждые пять лет, чтобы успевать за эволюцией информационных технологий и новшествами.
Программист-профессионал
В своих стремлениях превратить программирование в солидную профессию Макконнелл дошел даже до требования профессиональной сертификации программистов как программных инженеров, так же как сертифицируют, например, инженеров-строителей, инженеров-электриков, гидов-переводчиков, адвокатов, медиков. Профессиональная сертификация позволила бы отсечь от программирования случайных людей, повысить порог вхождения в профессию, дать какие-то гарантии заказчику, что человек, называющий себя программистом, действительно является тем, кем за кого он себя выдает и владеет всеми требуемыми для этой профессии навыками.
Без сертификации программист не может считаться профессионалом и, следовательно, не может привлекаться к работе над серьезными программными проектами.
А не слишком ли это все сложно?
Инженерный подход стали требовать при создании заказного ПО для оборонных ведомств. Все оборонные подрядчики оборонных ведомств разрабатывают ПО по инженерных принципам, что все их разработчики сертифицированные программные инженеры. Потом это требование распространили на подрядчиков государственных органов. Так правительство могло отчитаться перед налогоплательщиками, что деньги тратятся с гарантией получения результата.
Время показало, что инженерный подход не оказался волшебной палочкой и не решил все проблемы с разработкой ПО. Несмотря на все эти ухищрения и требования правительственные проекты создания ПО регулярно терпят фиаско.
Выводы
Инженерный подход имеет право на жизнь, если:
- вы работаете в большом проекте
- проект жестко органичен по срокам и по бюджету
- проект правительственный или крупный сложный заказ на ПО
Не каждый программист в своей карьере попадет в такой проект. Тем не менее в жизни случается все, и знать о том, как работает инженерный подход, какие знания и умения требуются от программиста для участия в таком проекте, какие процессы используются и как они организовываются — не помешает.
Algo & DMA: технологии биржевой торговли 