Журнал «Компьютерра» № 29 от 15 августа 2006 года
Шрифт:
Хороший инструмент должен гарантировать и среднюю производительность сотрудника, и среднее количество ошибок, и даже «средний» способ реализации идей.
Для того чтобы обеспечить взаимозаменяемость сотрудников, надо выдать всем одни и те же, или хотя бы родственные, инструменты — и тогда, коль скоро инструмент контролирует общность стиля, одна «офисная крыса» легко продолжит работу с того места, где другая сошла с дистанции.
Нарисованная картинка может показаться слишком циничной; тем не менее никакая крупная корпорация просто не сможет выжить, не обеспечив маломальскую заменяемость (а значит — стандартизацию) своих работников. Да, ограничение средств выражения мыслей несколько снижает эффективность процесса — зато повышает его предсказуемость. Крупная корпорация не может полагаться
Идеальное (по крайней мере, с точки зрения Корпорации) решение задачи «однообразных работников» зовется Платформа. Платформа — набор решений, охватывающих все области деятельности Корпорации; Платформа — контролируемый набор взаимоинтегрируемых инструментов; Платформа — Единый Набор Кнопок с Самого Верха до Самого Низа.
Будь то Платформа Java, Платформа .Net, Платформа 1С, Axapta, Oracle — цель и смысл один.
Технологии такого уровня создаются и развиваются, естественно, крупными-серьезными корпорациями (никому меньшему задачу такого уровня, растянутую на несколько лет, просто не осилить — как и не выдержать последствий возможного провала). И в отличие от технологий эффективной работы, рассмотренных ранее, прогресс в области технологий-платформ течет не то чтобы совсем стабильно и предсказуемо, но, скажем так, с постоянной скоростью — подпитываемый армией маркетологов, заранее окруженный уже-лояльными-клиентами, «носорог плохо видит — но при его весе это не его проблема».
Другое дело, что «прогресс» такого рода многие и за прогресс-то не считают. Достаточно вспомнить последнюю (в смысле — самую свежую) крупную и громкую платформу, сделанную с нуля, — Microsoft .Net, которую задолго до, во время и еще долго после выхода в свет (да и до сих пор) окружали недоуменные статьи на тему «что-же-здесь-нового-и-зачем-об-этом-так-кричать» [Одну из наиболее характерных статей такого рода, к тому же неплохо написанную и сносно переведенную на русский, можно найти у Джоэля Спольски:russian.joelonsoftware.com/articles/MicrosoftGoesBonkers.html]. Действительно, ни один из компонентов .Net, будучи рассмотрен сам по себе, не был чем-то «новым и особенным»; инновацией была целеустремленность и последовательность, с которой Microsoft охватил весь процесс разработки ПО — для любых условий, на любом языке, с интеграцией (и дифференциацией) всего и вся. Набор не самых передовых технологий, объединенных не самым изящным образом, за несколько прошедших лет изменил индустрию весьма существенно — и кто скажет, что это не прогресс, тот прогресса не видел.
Как ни странно, мало достичь результата: он должен еще оказаться корректным (приемлемым, точным, соответствующим и т. п.). Как бы забавно это ни звучало, но это обстоятельство многие творцы игнорируют (ща-допишем-начнем-продавать, с-багами-потом-разберемся); и технологический прогресс в области верификации результата сегодня скорее стоит на месте, чем куда-то прогрессирует.
Пользователю (заказчику, потребителю результата) по-прежнему предлагается либо довериться репутации производителя («фирма веников не вяжет уже сорок лет»), либо опробовать его перед покупкой/оплатой — и при «опробовании» приходится ориентироваться в основном на собственный опыт, интуицию, вкус и тому подобные неформализуемые способности. В любом случае, предполагается, что корректность произведенного уже обеспечена производителем (внутри его головы или его фирмы) и является полностью его болью и заботой.
У самого производителя сегодня не намного больше средств обеспечения этой корректности, чем 10-20-30 лет назад, — автоматически проверить что можно (например, орфографию), тестировать автоматически или вручную [Разницу между проверкой и тестированием можно сформулировать так: проверка напрямую сверяет результат с «правильным» (что возможно далеко не всегда), а тестирование рассматривает его как «черный ящик»: на вход подали А — на выходе должно получиться Б] и опять же — полагаться на свой опыт-вкус-интуицию. Прогресс в стане производителей идет в основном не технологический, а методологический: скажем, все в той же разработке ПО — от когдатошнего максимально-формального процесса (определяем требования до начала работы, пишем кучу документации до начала кодирования, ни на йоту не отклоняемся от плана) — к сегодняшним гибким (agile) методологиям (требования могут меняться в процессе разработки, вся функциональность охвачена тестами, код, спецификации, требования непрерывно перерабатываются).
Впрочем, один из аспектов сегодняшнего прогресса софтверных технологий связан с вопросом «корректности результата» достаточно сильно: при использовании гибких методологий разработки софта одним из важных требований является то, что заказчик должен видеть «полуготовый, но уже полезный» результат разработки; в идеале представитель заказчика постоянно присутствует при процессе разработки: это дает команде разработчиков жизненно необходимый своевременный ответ на вопрос «а то ли мы вообще делаем?». Такие «тепличные» условия легко обеспечить, когда есть конкретный, единичный заказчик — но не в условиях массовой разработки, где по-прежнему приходится действовать по принципу «сделать нечто, послушать отклики пользователей, выпустить следующую версию и так ad infinitum».
В качестве альтернативы, приобретающей все большую популярность, можно ткнуть пальцем в веб-приложения (те, которые установлены на единственном сайте — а весь Интернет пользуется) как идеальную среду для получения отклика от пользователей — здесь и новую версию можно «выпускать» хоть каждый день безболезненно для пользователей; и пользователи «на виду» (можно собрать детальную статистику, кто из них как использует приложение); и пользователи эти больше расположены к общению с командой разработчиков (нет ощущения «программа у меня на компьютере, а разработчики где-то далеко»). Тот же Google Spreadsheet, на сегодня имеющий смешные по сравнению с Excel возможности, опережает последнюю только в одном: новая функция может появиться ПРЯМО СЕЙЧАС, а не «через пару лет, когда наконец-то будет выпущена следующая версия».
То есть, возвращаясь к нашим пулям, результат, возможно, и не станет заведомо корректным, но всегда может быть оперативно скорректирован — и все благодаря магическим словам «веб» и «онлайн».
Не нужно думать, что все эти рассуждения применимы только к разработке ПО. Например, в деле написания текста (которым и я сейчас занимаюсь) блоги как квази-СМИ опережают традиционные СМИ ровно постольку, поскольку последние продолжают работать по «офлайновой» модели «текст опубликован, а там хоть трава не расти», — тогда как в блоге автор статьи обычно активно участвует в обсуждении и зачастую пишет по его результатам новые статьи (или корректирует старые) [Здесь, кстати, можно бы попенять «Компьютерре» за «старообрядческую» модель ее интернет-образа: к статьям хоть и «цепляются» обсуждения в форуме, но никакой связи ни с авторами, ни с последующими статьями форум не имеет]. Сюда же можно записать и Википедию, которая методом непрерывной и всеобщей коррекции накопила объем человеческого знания, несравнимый ни с одной когда-либо созданной людьми энциклопедией.
То есть главный вывод из всех этих рассуждений таков: сегодняшний вектор развития технологий, связанных с обеспечением корректности результатов деятельности в софтверном окружении, — «быстро исправленное не считается ошибочным». А возможность быстрого исправления неотрывно (на сегодня, по крайней мере) связана с «онлайновостью» исправляемого. Веб-все-что-угодно — это не «странная мода» или «идиотская прихоть маркетологов», а, напротив, еще один шаг к серебряной пуле.
Привыкайте.
...вроде нет пока. То есть все движется куда-то, и бытие в софтовом мире становится существенно легче и, кажется, даже немножко более предсказуемым. И все же по самому крупному счету — ее нет; по-прежнему эффективность работы непредсказуема, а результаты неясны. Одна из крупнейших проблем во всех попытках решения — в рекурсивной самоприменимости «проблемы серебряной пули» к технологиям, эту проблему решающим: разрабатывая новый инструмент разработки новых инструментов (скажем, новый суперэффективный язык программирования), мы точно так же не можем быть уверены, удастся ли его разработать, и если да — правда ли он окажется таким вот суперэффективным.