Профессия CIO скоро исчезнет, потому что ИТ-директор не понимает бизнес, а идеальной командой создателей софта сегодня представляется связка “инженер + предприниматель”. Данная тема прошла золотой нитью через весьма эмоциональное и экспрессивное выступление профессора Дэйва Томаса на CEE-SECR 2013 — российской конференции по разработке ПО. Этот человек за свою жизнь внёс в мир ИТ весьма существенный вклад: основал Agile Alliance, объединивший сторонников гибких методологий, участвовал в разработке технологий виртуальных машин и фреймворков IBM и Eclipse, получил звание ACM Distinguished Engineer за вклад в объектные технологии. Он выступал сразу следом за своим старым другом Иваром Якобсоном, поведавшем об универсальной платформе программной инженерии SEMAT, но доклад Томаса явился по концепции едва ли не полной противоположностью рассказу своего коллеги. Несмотря на то что Томас признанный гуру по agile-методологиям, он раскритиковал их в пух и прах, и предложил новую прикладную концепцию IT 4.0, впрочем, не позиционируя её как очередную “серебряную пулю”.
В сфере гибкой разработки продолжается непонятная возня, но где же инновации, вопрошал профессор. Десять лет мы видим всё тот же Scrum, который уже достиг 90% распространения по отношению к другим agile-подходам — но где эффект? Почему число багов в массовом софте не снижается? В методологическом плане Томас порекомендовал обратить внимание на бережливую (lean) разработку, которая в противовес другим подходам заставляет работать мозгами. В этой рекомендации можно увидеть некую ревность Томаса, возглавляющего сообщество Large Scale Lean and Agile Development, по отношению к массовым гибким подходам. Однако и Scrum, и экстремальное программирование, скорее, весьма специфичные прикладные методы, а бережливая разработка (применяемая, например, в производстве) относится, пожалуй, к более глубоким концепциям, нежели сам Agile. Lean — это, скорее, философия, рекомендующая, например, максимальную отсрочку принятия решений и одновременно максимально быструю поставку работающего функционала клиенту, а также исключение всего, что не относится напрямую к формируемой для заказчика ценности.
Именно lean помогает делать программный код “худым”, и сегодня это крайне актуально: софт продолжает усложняться, объёмы легаси-кода неумолимо растут. Современные КИС невозможно модифицировать, их функционал частично доступен только через API, в итоге дополнения для КИС работают очень медленно, а интегрировать эти системы с другими элементами ИТ-инфраструктуры весьма сложно. Сегодня не редкость система из 10 млн. строк кода на Java — и как в ней разбираться, как совершенствовать? Зачем нужны такие сложные комплексы? А рефакторинг, поддерживаемый всеми средами программирования, фактически означает “выбросить весь мусор и делать всё заново”. Но почему этот мусор появился изначально?
Прикладные технологии тоже движутся в сторону усложнения и наращивания своего потенциала механическим путём. Мы ежедневно слышим про облачные подходы — но что это, как оно работает? Нам доступны десятки тысяч сервисов SaaS, но мы совсем забыли о простоте. Сейчас разгорелся очередной ажиотаж вокруг подхода NoSQL — да, он эффективен, но каждую систему надо изучать с нуля, снова вручную программировать под конкретные программные интерфейсы, и снова плодить код.
У меня в кармане флэшка на 64 Гб, заявил Томас, на которую я могу записать огромные объёмы полезной информации. Но современный софт пока плохо использует потенциальные возможности нынешних аппаратных мощностей. По-хорошему, для создания такого софта нужны средства программирования, обеспечивающие прямой доступ к ресурсам аппаратуры. Для этих целей некогда создавался язык Си, однако в нынешнем мире он все же излишне минималистичен. С другой стороны, четыре тысячи классов Java — это тоже перебор. При этом сама Java развивается слишком медленно, если брать современные сроки жизни ИТ, и например, текущие реализации Java работу с большими данными откровенно не тянут.
Нынешним системам не хватает простоты, но как её достичь, мы пока не знаем. Возможно, умышленно, Томас ни разу не упоминал подходы Алана Кея, который с помощью декларативного и метапрограммирования уместил систему в 20 млн. строк кода в тысячекратно меньший объем. Вероятно, профессор специально делал акцент не столько на технологиях и практиках, сколько на том, что надо больше думать над тем, как писать меньше кода. Он дал простые советы: применяйте наиболее подходящий задаче и наиболее выразительный язык программирования, используйте не C# или Java, а скрипт-языки (это просто) и готовые облачные сервисы. Создавайте меньше классов, пишите меньше кода на стороне СУБД (триггеры, исполняемые процедуры), тщательнее проектируйте систему.
Под упомянутой концепцией IT 4.0 Томас предложил считать формулу “CRUD (создание, чтение, редактирование и удаление данных) + рабочий поток + данные, которые сами себя описывают = бизнес”. При этом надо стараться автоматизировать все, что можно — тестирование, сборку, развёртывание приложений, и в перспективе переходить к автоматическому конструированию программ. Реализовывать же IT 4.0 предложено в виде архитектуры микросервисов.
Отмечу, что ещё в конце 2012-го компания ThoughtWorks, отслеживающая ИТ-тренды, зафиксировала всплеск интереса к этой технике проектирования распределённых систем. Причина тому в зрелости инструментария (несложно найти фреймворки для создания масштабируемых RESTful-сервисов) и соответствующих практик (например, декларативного описания и генераторов DSL-языков). Эти подходы позволяют отказаться от монолитных систем в пользу лёгких распределённых решений, которые характеризуются невысокой стоимостью владения. Микросервисы особо актуальны для долгосрочных по меркам ИТ проектов с жизненным циклом 3—5 лет.
Верный своему стилю минимализма Томас эту концепцию упростил: микросервисы — это много маленьких независимых кусочков кода, которые легко расширять и разворачивать, для их эксплуатации не нужны API. Проектировщикам систем в этой связи надо учиться декомпозиции больших систем в микросервисы — фактически же вспомнить концепции каналов и фильтров Unix!
IT 4.0 — это также активное внедрение инноваций, которые сегодня приносят основную прибавочную стоимость, а зарождаются чаще всего в “плоских” организационных структурах. В лучших фирмах ведущий инженер работает без подчинённых, основное время он не стучит по клавишам, а думает. Поэтому Томас полагает, что сложные системы все чаще будут создаваться небольшими коллективами способных самоделкиных, активно использующих облачные сервисы. Сегодня подчас проще быстро закодировать некую функциональность с нуля и предоставить её клиенту в формате SaaS, нежели длительно внедрять КИС с высокими накладными расходами на сопровождение.
Бизнес — вот что важно. А ИТ-проекты с акцентом на ИТ — это ад. Как только вам говорят “проектная культура”, будьте готовы к тому, что у вас скоро появится куча проблем, отметил профессор. Связка разработчика с предпринимателем на сегодня оптимальна, и этого достаточно для автоматизации абсолютного большинства задач СМБ. Давайте посмотрим, как сегодня программируют сообразительные подростки. Они создают многопользовательские игры на миллионы пользователей, которые подчас архитектурно сложнее, чем крупнейшие КИС, не имея при этом никакого представления о программной инженерии.
По завершении столь эмоционального выступления Томасу задал вопрос один украинский ИТ-директор. “Я работаю CIO в одесской фирме, — заявил он, — и хотя вы говорите, что CIO в бизнесе не разбираются, я как раз знаю бизнес своей компании лучше всех! Топ-менеджеры постоянно со мной консультируются и обсуждают все важные вопросы”. К сожалению, ответил ему со смехом профессор, в США Одессы нет.
И в России, кстати, тоже.
