Боронин Сергей

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

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

Существуют и другие причины, но сложность программ считается настолько самодостаточным оправданием, что вроде как нет никакой надобности смотреть на что-то иное и пытаться как-то влиять на ситуацию.

Такой ли вселенский масштаб имеет проблема роста сложности ПО?

Чтобы выявить иные причины изобилия индийского кода и терпимости к нему, вернемся в 70-е, когда появилась профессия «инженер-программист». Изначально разработка велась на ассемблере, постепенно мигрируя на язык С. Разработчик досконально знал аппаратную часть ПК, архитектуру и специфику используемой им ОС. Программы тогда занимали от пары килобайт до нескольких их десятков, и весь исходный код программист мог держать в голове, поэтому при проектировании хватало блок-схем. По мере усложнения программ сформировалась парадигма процедурного программирования, и большинство разработчиков стали активнее использовать отладчики, применение которых было не столь актуально на более ранних этапах. Программы в то время тщательно оптимизировали как по размеру, так и по скорости исполнения. Большинство программистов считали позором выпускать в свет программу с ошибками, что положительно сказывалось на качестве ПО.

К концу 80-х сформировалось второе поколение программистов, которые в основной своей массе программировали под персоналки, а не под мейнфреймы, как их предшественники. Были сформированы концепции ООП и создан C++. Методы проектирования были дополнены диаграммой классов, что повысило уровень абстракции логики программ от специфики операционной системы. Выросли и масштабы проектов, что потребовало коллективной разработки. Существующие методологии плохо справлялись с новыми проблемами, что хорошо изложено в «Мифическом человеко-месяце» (Ф. Брукс). Начались проблемы с качеством. Как ответ на них появился итерационный подход к ведению проектов.

Середина 90-х принесла с собой третье поколение программистов, которым уже не надо было экономить память и оптимизировать производительность своих программ. Ими охотно и всерьез стала применяться как оправдание «Теория ошибок», ставшая фольклором и «обросшая» разными вариациями и дополнениями наподобие «Законов Мерфи»: «Аксиома. В любой программе есть ошибки. Закон пропорциональности. Чем более программа необходима, тем больше в ней ошибок. Следствие. Ошибок не содержит лишь совершенно ненужная программа».

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

Спрос рождает предложение, но рынок выкинул злой фортель, и к концу 90-х вместо выпуска квалифицированных инженеров рынок был наводнен поколением ремесленников. Их отличает отсутствие профессионального интереса к отрасли, вследствие чего они изучают и принципы и инструментальные средства ровно настолько, насколько это достаточно для того, чтобы трудоустроиться и не вылететь с работы — они пришли в IT из конъюнктурных соображений. Этим людям, как правило, не свойственен инженерный подход, они подменили архитектуру дизайном системы, а систематизированный набор требований — карточками, описывающими те или иные аспекты ее функционирования.

Стоит ли говорить о том, что, как правило, IT-специалисты известны своим разгильдяйством и отнюдь не являются самым «лояльным» персоналом. Многие из них не очень-то терпят над собой какой-либо менеджмент. И если учесть это, будет ли удивительным, что они не любят методологии разработки, подразумевающие жесткий менеджмент, отсюда — мало кто утруждает себя изучением RUP. Методологии, требующие инженерного подхода, симпатии последней волны программистов не завоевали. Это привело к популяризации Agile-методологий, в которых не только нет жесткого управления, там отсутствует систематизация требований и архитектура. В свою очередь, это подталкивает к тому, что можно садиться и писать, не задумываясь о будущем развитии проекта, а это приводит к практически полному переписыванию системы с каждой новой версией. Отсутствие тщательной проработки архитектуры систем привело к лавинообразному росту числа уязвимостей, который мы наблюдаем в настоящее время.

В принципе, такое положение дел закономерно, так как спрос на программистов в разы превышает количество специалистов с инженерным подходом, что открывает дорогу дилетантам.

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

Ведь нехватка квалифицированных программистов, обладающих глубокими базовыми знаниями, приводит к появлению широкой прослойки тех, кто быстро подучился востребованным на рынке технологиям. Уровень владения своим инструментарием у этих людей меньше, чем у слесарей автосервиса. Про уровень ответственности и говорить не приходится, особенно если вспомнить, что даже самые жуликоватые автослесари называют конечную цену работ, тогда как в Agile-методологиях она может оставаться открытой. Что это, как не полная безответственность за результаты своего труда? Фактически, Agile-методологии ведения проектов являются сильно упрощенными версиями традиционных. Изменилась и роль менеджера проектов, она полностью перенесена на ведущего разработчика, который вместо работы с рисками проекта зачастую просто вводит заказчика в раж мнимой легкостью добавления новых возможностей, что позволяет не фиксировать объем работ, оставляет открытой цену и сроки реализации. Роль тестировщика перенесена на разработчика (Unit-тесты), причем совершенно не учитывается тот факт, что программисты не бывают хорошими тестировщиками, так как цель программиста при тестировании — поскорее закончить все тесты и продолжить разработку, а не выявить все ошибки.

Так что помимо обучения требуются и новые методологии проектирования и разработки. Существующие в UML диаграммы не обеспечивают должного уровня взаимосвязи как между разными типами диаграмм, так и между диаграммами и проектной документацией. Чтобы в полной мере отражать требования к проекту, диаграммы становятся столь громоздкими, что на моей памяти на одном из проектов на их изучение разработчиками закладывали до 25% времени.

Нельзя давать программистам ТЗ построить Тадж Махал или пирамиду Хеопса, в качестве инструмента дав лишь каменный топор. Инструментарий должен соотноситься с масштабом и сложностью проекта. И если и есть что критиковать в разработчиках, то нельзя упускать из виду и то, что работать им приходится при отчаянной нехватке ресурсов, инструментов и знаний. Поэтому даже живой интерес, который человек мог иметь в начале карьеры, постепенно вырождается в фатализм и безразличие.

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

Ведь по мере того, как все больше проектов разрабатываются на аутсорсе, все в большей степени новые методологии отходят о того, чтобы соблюдать интересы заказчика и снижать его риски. Раньше, когда заказчик и исполнитель чаще всего жили под одной корпоративной крышей, их интересы совпадали, и это отражали подходы к разработке. Теперь методологиям, чтобы получить поддержку, нужно дружить с потребностями исполнителей-аутсорсеров — ведь их большинство. А это означает, что необходимо снижать в первую очередь их риски и усиливать разработку манипулятивных подходов в духе тех, что применяются при продажах менеджерами проектов, которые доступно «объяснят» клиенту, что он получил именно то, что хотел, в приемлемые сроки и за приемлемый бюджет. Дурных заказчиков, ничего не подозревающих и не умеющих вдаваться в технические детали, как предполагается, на их век хватит.

Хочется думать, что это не так.

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

«Серебряной пули» не существует? Или все-таки можно придушить разгильдяйство и ремесленничество по крайней мере в том радиусе, в котором хватает длины собственных рук?