Журнал Компьютерра - Журнал «Компьютерра» N 29 от 15 августа 2006 года

Идеальное (по крайней мере, с точки зрения Корпорации) решение задачи «однообразных работников» зовется Платформа. Платформа - набор решений, охватывающих все области деятельности Корпорации; Платформа - контролируемый набор взаимоинтегрируемых инструментов; Платформа - Единый Набор Кнопок с Самого Верха до Самого Низа.

Будь то Платформа Java, Платформа .Net, Платформа 1С, Axapta, Oracle - цель и смысл один.

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

Другое дело, что «прогресс» такого рода многие и за прогресс-то не считают. Достаточно вспомнить последнюю (в смысле - самую свежую) крупную и громкую платформу, сделанную с нуля, - Microsoft .Net, которую задолго до, во время и еще долго после выхода в свет (да и до сих пор) окружали недоуменные статьи на тему «что-же-здесь-нового-и-зачем-об-этом-так-кричать» [Одну из наиболее характерных статей такого рода, к тому же неплохо написанную и сносно переведенную на русский, можно найти у Джоэля Спольски: russian.joelonsoftware.com/articles/MicrosoftGoesBonkers.html]. Действительно, ни один из компонентов .Net, будучи рассмотрен сам по себе, не был чем-то «новым и особенным»; инновацией была целеустремленность и последовательность, с которой Microsoft охватил весь процесс разработки ПО - для любых условий, на любом языке, с интеграцией (и дифференциацией) всего и вся. Набор не самых передовых технологий, объединенных не самым изящным образом, за несколько прошедших лет изменил индустрию весьма существенно - и кто скажет, что это не прогресс, тот прогресса не видел.

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

Пользователю (заказчику, потребителю результата) по-прежнему предлагается либо довериться репутации производителя («фирма веников не вяжет уже сорок лет»), либо опробовать его перед покупкой/оплатой - и при «опробовании» приходится ориентироваться в основном на собственный опыт, интуицию, вкус и тому подобные неформализуемые способности. В любом случае, предполагается, что корректность произведенного уже обеспечена производителем (внутри его головы или его фирмы) и является полностью его болью и заботой.

У самого производителя сегодня не намного больше средств обеспечения этой корректности, чем 10-20-30 лет назад, - автоматически проверить что можно (например, орфографию), тестировать автоматически или вручную [Разницу между проверкой и тестированием можно сформулировать так: проверка напрямую сверяет результат с «правильным» (что возможно далеко не всегда), а тестирование рассматривает его как «черный ящик»: на вход подали А - на выходе должно получиться Б] и опять же - полагаться на свой опыт-вкус-интуицию. Прогресс в стане производителей идет в основном не технологический, а методологический: скажем, все в той же разработке ПО - от когдатошнего максимально-формального процесса (определяем требования до начала работы, пишем кучу документации до начала кодирования, ни на йоту не отклоняемся от плана) - к сегодняшним гибким (agile) методологиям (требования могут меняться в процессе разработки, вся функциональность охвачена тестами, код, спецификации, требования непрерывно перерабатываются).

Впрочем, один из аспектов сегодняшнего прогресса софтверных технологий связан с вопросом «корректности результата» достаточно сильно: при использовании гибких методологий разработки софта одним из важных требований является то, что заказчик должен видеть «полуготовый, но уже полезный» результат разработки; в идеале представитель заказчика постоянно присутствует при процессе разработки: это дает команде разработчиков жизненно необходимый своевременный ответ на вопрос «а то ли мы вообще делаем?». Такие «тепличные» условия легко обеспечить, когда есть конкретный, единичный заказчик - но не в условиях массовой разработки, где по-прежнему приходится действовать по принципу «сделать нечто, послушать отклики пользователей, выпустить следующую версию и так ad infinitum».