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

При переходе от монолитных приложений для мэйнфреймов, где пользовательский интерфейс реализован в символьном режиме, к движимой событиями модели, лежащей в основе Windows, методы разработки приложений кардинально изменились. Эти изменения коснулись самых разных аспектов программ, и первым из них стал интерфейс пользователя. С Windows началась популярность развернутого графического пользовательского интерфейса, который предоставил массу новых возможностей, но, впрочем, породил и множество потенциальных источников ошибок в том, что касается удобства архитектуры. Клиент-серверная программная модель позволила связать между собой гетерогенные системы. А затем Internet-вычисления предложили нам исключительную гибкость в развертывании приложений, но при этом также дополнительно усложнив проектирование архитектуры программных систем.

Десять лет назад хорошему разработчику программного обеспечения достаточно было знать один язык (скажем, Кобол или Си); как правило, он не обязан был хорошо разбираться во всех тонкостях архитектуры мэйнфреймов. Пять лет назад тот же разработчик должен был изучить специальные языки программирования четвертого поколения (Visual Basic, PowerBuilder, Delphi...), иметь представление об SQL и знать определенные характеристики каждой СУБД (например, механизм хранимых процедур в Oracle PL/SQL и Sybase Transac SQL).

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

Теперь мы живем в мире Web-приложений, используемых как в Internet, так и во внутрикорпоративных сетях. Сейчас идеальный разработчик должен владеть специальными языками презентационного уровня (HTML, Cascaded Style Sheets, XML, XSL и JavaScript), уровня бизнес-объектов (Java или любой другой подобный язык программирования) и уровня данных (отображения между объектами и таблицами, долговременное хранение и — опять! — SQL). Кроме того, поскольку Web-приложения все больше и больше становятся неотъемлемой частью повседневной работы, они требуют интеграции с существующими системами заднего плана (системы планирования ресурсов предприятия, унаследованные приложения, основанные на обмене сообщениями программное обеспечение промежуточного слоя).

Из всего сказанного можно сделать вывод, что идеальный разработчик должен быть просто суперменом. Как ни грустно, но таких людей попросту не существует — или они крайне редки. Как правило, этими навыками по отдельности обладает целая группа людей, работающих с разными продуктами и технологиями. При проектировании программного обеспечения координация этих различных технологий становится довольно сложной задачей, так что в современном мире понятие «архитектора программного обеспечения» имеет вполне определенный смысл. Но какие инструментальные средства и методы можно использовать, чтобы упростить процесс создания программной архитектуры?

Решения для повышения качества и производительности

Платфомы

Наиболее общая стратегия, направленная на повышение качества и производительности при разработке приложений, предполагает создание платформы (framework) или ее расширение. Создание платформы может оказаться длительным и дорогостоящим процессом, который призван решить проблемы счет предоставления команде разработки простого интерфейса. Не менее важны документация и примеры.

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

Если после предыдущей фразы вы не отложили журнал в сторону и продолжаете читать эту статью, я готов дать вам еще несколько советов.

Организация команды

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

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

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

Инструменты

Инициативы, связанные с инструментальной поддержкой повторного использования, в отрасли программного обеспечения возникают регулярно. Компания Flashline предприняла уже вторую попытку, модернизировав службу Flashline Component Manger Enterprise Edition (CMEE).

Изначально, в первом своем варианте, Flashline предлагала доступ к услугам своей хостируемой службы, а теперь CMEE распространяется как продукт, предназначенный для установки в офисе заказчика. Flashline предлагает организации инфраструктуру и инструментарий конечного пользователя, необходимые для поддержки и измерения уровня повторного использования компонентов в рамках предприятия.

CMEE и соответствующие службы Flashline ориентированы на разработку Java-приложений. И хотя эта система позволяет работать с любыми другими компонентами, реальные ее преимущества проявляются именно в разработках, связанных с Java. Клиентская часть программной среды CMEE, представляющая собой Java-приложение, интегрируется с большинством популярных интегрированных сред разработки на Java (скажем, WebGain).

Хотя CMEE была создана совсем недавно и не имеет пока обоснованных свидетельств своей эффективности при измерении фактической степени повторного использования, она предлагает ряд очень интересных концепций. Во-первых, этот инструментарий представляет собой не просто статический продукт; он позволяет взаимодействовать с другими службами Flashline, такими как Code Testing/Profiling, Component Certification и Component Marketplace. Кстати, эта уникальная возможность объясняет высокую стоимость продукта, неограниченная серверная лицензия на который стоит 60 тыс. долл. плюс дополнительно по 150 долл. за каждого пользователя ежемесячно.

Более того, система позволяет отслеживать огромный объем информации, например, разыскиваемые ключевые слова, обеспечивая практическое применение компонентов (извлечение, тестирование, развертывание и отказ). Еще одна особенность CMEE состоит в том, что она призвана эффективно использовать возможности специалистов организации. Как отметил Чарлз Стек, президент компании Flashline, «одна из целей создания CMEE состоит в том, чтобы на новом уровне работать с «программистами-звездами». Этот инструментарий способствует созданию истинного сообщества разработчиков в рамках предприятия. И, наконец, архитектура продукта предусматривает бесконфликтную интеграцию с существующими инструментальными средствами и методами работы, принятыми в компании.

Заключение

Эпоха монолитных и независимых приложений завершается. Разработка должна оцениваться в терминах поддержки, масштабируемости и интероперабельности.

Разработка на основе платформ следует этой логике, а структура и опыт, реализованные в платформе, могут повторно использоваться в аналогичных проектах. Это просто первый шаг на пути перевода разработки приложений на промышленную основу.

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

Жан-Кристоф Циметье (jcc@techmetrix.com) — генеральный директор компании TeсhMetrix Research (www.techmetrix.com)

Jean-Christophe Cimetiere, A Few Words on Development Practices. TrendMarkers, Vol. 3, No. 2, 2001. Techmetrix Research. All rights reserved. Reprinted with permission.