Греф и рост IT-экспорта

Навеяно постом в IT Blogs.

Согласно статье в CNews, рост IT экспорта прогнозируется в 76 раз за 10 лет. Очевидно, однако, то, что иначе как с потолка этот прогноз взять неоткуда, тем более с точностью до единиц.

Во-первых, у правительства нет данных о реальных объемах айти экспорта. Потому что большая его часть не отражается в отчетности. Сколько такого IT экспорта, о котором наше правительство даже не догадывается, и никогда не узнает? (если конечно не станет читать форум rsdn) Однако, сам процент отражения в отчетности, очевидно, растет. Отсюда может возникнуть ощущение мнимого роста экспорта, когда реально растет лишь объем его отражения в отчетности предприятий.

Во-вторых, откуда возьмутся ресурсы для роста (в 76 раз больше, чем сейчас)? Аксиома экономической теории утверждает, что ресурсы - вещь ограниченная. А основной ресурс IT компаний - это кадры. Между прочим, - больной вопрос наших IT компаний. Агенства по трудоустройству говорят, что у нас в IT – "рынок кандидата", и что рынок труда IT специальностей "перегрет". Даже у компаний, готовых вкладывать деньги и платить "белые зарплаты", есть проблемы с наймом персонала. Утечку мозгов за границу также никто не отменял. Зато недостаток хорошего образования в IT и демографические проблемы - налицо. А утечке мозгов подверженны именно специалисты, работающие на экспорт и обладающие высокой квалификацией. Кто же будет производить IT продукцию на экспорт? Может, безумно раздутая армия чиновников активно начнет писать программы?

В-третьих, чтобы рос экспорт, нужно что-то продавать: продукцию либо услуги. Продавать на западных рынках, - а значит придется столкнуться с сильной конкуренцией. На мой взгляд, текущая коньюнтктура айти рынка такова, что накопленные изменения технологий переходят в качественное изменение айти экономики. Это сопровождается вытеснением либо поглощением мелких айти компаний. (да что мелких... этот процесс кардинально затронул такую крупную компанию как Borland) Пробиться на рынки новым и небольшим компаниям сейчас сложнее, чем лет 10-20 назад. Проще тем, у кого есть ноу-хау и инновации, но они не поддаются прогнозам. Пока не ясен механизм увеличения продаж, любые радужные прогнозы не имеют под собой серьезных оснований.

Немалую часть нашего айти экспорта составляет аутсорсинг. Фундаметом аутсорсинга является способность делать качественную работу за небольшие деньги. Об образовании уже сказано выше. Что до цен, то Москва (как один из центров концентрации айти производителей в России) – ныне лидирует в списке самых дорогих городов мира. Рейтинг, конечно, не вполне адекватный, но то, что дорожает жизнь - налицо. А значит те, кто рассматривает Россию как потенциальное место для аутсорсинга, могут предпочесть Украину, Молдавию.

На что же рассчитывает правительство? Читаем статью:

«В России скоро будет создано Федеральное агентство по экспорту высоких технологий. По мнению Германа Грефа, это ведомство сыграет важную роль в повышении конкурентоспособности российских товаров в сфере ИТ на мировом рынке»

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

«штат сотрудников агентства будет сформирован преимущественно из числа специалистов Мининформсвязи»

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

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

Это уже что-то безусловно положительное. Но для изменения налога не требуется целое ведомство. Пора уже нашему правительству придумать что-нибудь новое, помимо налоговых льгот (о которых говорят уже лет 10).

Ведь есть масса проблем, которые нужно решать. Это касается и образования, и поддержки малого бизнеса, и повышения уровня жизни, и борьбы с коррумпированностью чиновников. Для айти бизнеса (=для людей) нужно создавать среду, в которой он сможет работать и процветать.

И государству давно пора всерьез озаботиться созданием такой среды. Ведь айти индустрия уже сейчас - стратегический ресурс. Без программной начинки уже нельзя произвести ни одной современной машины, самолета, средства свзязи, вооружения.

Тестирование как средство проектирования

На мой взгляд, принцип test first - отличная техника проектирования. По крайней мере, опыт использования такого подхода при разработке библиотеки классов для финансовых приложений - крайне положительный. Энтузиазм по поводу TDD, или Test-Driven-Development, при котором тест пишется до самого класса, основан, возможно, как раз на том, что такая техника восполняет недостаток / исправляет на раннем этапе недочеты дизайна. Дополнительное преимущество: когда класс написан, уже готовы тесты чтобы его протестировать. Если тесты писать после классов, то шансы велики, что тесты не будут написаны вообще.

Недостаток пропаганды TDD, на мой взгляд, - в утрировании принципа test first, его аксиоматизации и возведении на пъедестал, где он приобретает абсурдный вид. По крайней мере, так его часто подают в статьях. Такой подход совершенно естественно вызывает скептицизм практикующего программиста, поскольку написание теста сначала имеет свои неудобства - например, невозможность пользоваться IntelliSense при вызове методов класса. (Кстати, Resharper решает эту проблему.) Поэтому понять прелесть подхода часто можно только попробовав его на практике. Принцип "test first" нужно использовать не как догму, а как мощный инструмент, который качественно меняет подход к разработке ПО, но имеет свою область применения, если смотреть на него в контексте полного цикла разработки.

Отражение взгляда на тесты как на нечто очень важное я нашел в статье о тестировании в Microsoft. О значении, которое там придается тестам, говорят следующие факты:

• позиция тестировщика называется Software Design Engineer in Test
• число тестеров на 40% больше, чем число разработчиков
• планы тестирования внушительны (отрывок)
• тесты изначально автоматизированы

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

Калькулятор паев

Мое небольшое произведение - Калькулятор паев. Программа предназначена для держателей паев паевых инвестиционных фондов (ПИФ). Скачивает стоимость паев из Интернет, рассчитывает данные портфеля.

Листая Software Development Magazine...

Две занимательные цитаты. Первая – проницательное наблюдение о метриках производительности, проиллюстрированное примером. Речь в статье идет о программе для управления проектом (точнее - bug-tracking):

Say they’d like to be able to keep track of which programmers create the most bugs, which fix the most, and which write the most code. These reports would be very easy to create from the data that we have, but as soon as you create a disincentive to put bugs in the system, people will stop putting them in the system. I’ve learned that any time you try to measure people in the workplace to make them better, they’ll begin to work toward the measurement, which is what you think you want, but they’ll do it in a way that isn’t what you want.
-- Joel Spolsky, SD Magazine February 2005

Вторая – интересный способ взглянуть на продукт глазами покупателя / пользователя:

Ask your customers to imagine that they’re selling your product at a trade show or an electronics store. Give them a few card-board boxes and ask them to design a product box that they’d buy. The boxes should display the key marketing slogans that they find interesting.
-- Luke Hohmann, из того же номера SD Magazine.

Думаю, можно не раздавать коробки, а просто представить; а вместо слоганов подумать о ключевых фичах; и вопрос этот задать не только клиентам, но и себе самому. :)

VS 2005 – первые впечатления

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

Удобства

Заметно, что уделено много внимания кастомизации среды. Для этого появилось множество настроек. О разработчике позаботились (на этот раз ;) ) – не зря все эти комьюнити, фидбэк и привью. Масса мелких улучшений касается юзабилити IDE (например, докинг окон или свойства проекта). Наконец-то появились шаблоны (code snippets). На мой взгляд, удобства - это важно, так как они увеличивают не только комфорт, но и производительность разработчика.

Нововведения

Хотя о нововведениях написано было много, все же не удержусь упомянуть некоторые, поскольку они бросаются в глаза. Анализ кода, рефакторинг, и автоматизированные тесты – в общем, они есть. Раньше приходилось пользоваться дополнительными утилитами, теперь все интегрированно в студию.

Открываем старый проект...

Для проверки совместимости я открыл небольшой (всего нескольких проектов), но насыщенный разнообразными техниками (например, Managed C++ и COM-серверы) solution, созданный в 2003-й студии. Визард предложил сконвертировать проект, а в конце работы отобразил отчет: 0 ошибок, 0 предупреждений. Отличный результат. Компиляция и запуск старой программы на Framework 2.0 также прошли успешно.

Отладчик работает быстрее. Основные окна отладки изменений на первый взгляд не претерпели. Отладчик стал более "хитрый" – например, при нажатии trace into при десериализации он заходит в конструктор десериализумого класса, чего раньше не происходило. Однако, эта "хитрость" связана с меньшей надежностью: при попытке протрассировать (trace into) ничем не примечательное присвоение переменной, что отладчик по идее должен игнорировать и переходить на следующую строку, отладчик выдал сообщение об ошибке ContextSwitchDeadlock. Данная ошибка воспроизводилась постоянно в нескольких сессиях отладки, однако, исчезла после перезагрузки компьютера. В общем, по традиции, сразу после релиза начинаем ждать сервис пак.

Ложка дегтя

Хотя удобству IDE в новой студии уделено немало внимания, не везде выдержан единый стиль. Некоторые закладки в свойствах проекта не подстраиваются автоматически при изменении размеров окна. Например, окно Build events не растягивается вместе с окном настроек; если нужно больше места, то необходимо нажать на кнопку открытия отдельного окна Build Events (зачем?). Мелочь, но из таких мелочей складывается впечатление о качестве продукта. Помню, на докладе по SQL Server 2005 на конференции Platform 2006 зал аплодировал просто тому, что диалоги настроек имеют нефиксированный размер. И молча слушал, когда речь шла, например, о поддержке xml запросов на уровне SQL. :)


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



Во-вторых, сама вставка снипета. Шоткат для вызова списка снипетов Ctrl-K, X. (Не самый удобный, так что лучше сразу сменить.) Однако, всплывающее окошко снипетов отображает еще не сами снипеты, а их категории; необходимо сместить курсор на нужную категорию, войти в нее, нажав Enter, после чего можно выбрать снипет!!! Это похоже на плохую шутку: смысл снипетов – минимизировать нажатия клавиш, а не наоборот. Такое впечатление, что IDE других производителей (IDEA, Delphi) пишутся разработчиками и для разработчиков - в отличие от студии.

Серьезный недостаток - невозможность в новой студии создавать проекты для фрэймворка 1.

[Update]Вот еще (далеко не полный) список недоработок студии: VS 2005 Annoyances

Выводы

Переход на новую студию и фрэймворк должны быть достаточно простыми, и преимущества серьезные. Улучшилась юзабилити среды и появились фичи для "серьезных" разработчиков - рефакторинг, автоматические сборка и тестирование, статический анализ кода (только в Team Suite?). Такое смещение акцентов закономерно, так как сложность процесса разработки растет. В то же время, есть проблемы с надежностью и удобством продукта.

Replacer

При разработке на C# COM-серверов для использования в MS Office встает проблема экспорта интерфейсов таким образом, чтобы обеспечить их совместимость с VBA. В C# / .Net имеется довольно небольшой набор средств, позволяющих управлять видом COM-интерфейсов и маршаллингом типов: атрибуты, кастомизированные маршаллеры и собственно синтаксис C# в сочетании с маршаллером по умолчанию. Однако этих средств недостаточно для того, чтобы реализовать некоторые типичные для VBA конструкции. Например, параметры-массивы или функции с необязательными параметрами.

Выход - не использовать Type Library, генерируемую средствами фрэймворк (.tlb файл), а писать свои определения интерфейсов на IDL. При помощи IDL можно описать любой интерфейс, поддерживаемый COM. Недостаток подохда в том, что написанный вручную IDL нужно синхронизировать с описанием интерфейса на C#. (В отличие от tlb, генерируемого по умолчанию, который синхронизируется с кодом автоматически во время сборки проекта.) Синхронизация IDL вручную чревата ошибками и требует много рутинной работы, объем которой растет вместе с ростом разрабатывамой библиотеки компонентов. Поэтому необходима утилита для генерации IDL на основе кода. Эту утилиту можно запускать при сборке, в том числе автоматической.

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

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

В итоге получилась утилита командной строки - Replacer, - которая используется следующим образом:

Replacer.exe macros.xml

То есть набор параметров (входной и выходной файлы) и макросов поиска и замены (регулярных выражений) описывается в XML файле.

[Update]На данный момент подход уже используется продолжительное время, и позволил практически забыть о проблеме совместимости COM интерфейсов между C# и VBA.

Открытие блога!

Добро пожаловать в мой блог!

Здесь я планирую писать о том, что меня интересует, а значит, надо немного рассказать о своих интересах. Интересуют меня следующие темы:

- финансовые рынки, инвестиционный банкинг, трэйдинг
- информационные технологии, проектирование ПО, процесс разработки
- программирование финансовых приложений