Как угнаться за законом Мура разработчикам ПО?
На одной из проходивших в Москве минувшей осенью конференций для ИТ-специалистов мне довелось услышать замечательную фразу, сказанную представителем одного из ведущих мировых поставщиков ПО: "Наша корпорация, как и другие технологические компании, строит свой бизнес и разработку перспективных продуктов с учетом возможностей, описываемых законом Мура". Он конечно же имел в виду, что нужно закладывать в перспективные проекты функциональность, которая сегодняшней технике еще не под силу, но станет вполне доступна к моменту выхода готового продукта.
Тут нечего возразить, только так и нужно делать. Но проблема заключается в том, что разработчики ПО (особенно того, что относится к категории платформ) порой просто не поспевают за производителями железа и компенсируют отсутствие идей в отношении новых функций более легкими способами загрузки ресурсов компьютера.
Могу привести огромное количество примеров. Один из последних - создание простейшего вычислительного компонента (выполняющего "a+b") по новой технологии Web Services на локальном компьютере потребовало использования системного блока c Pentium III 800 МГц и памятью в 256 Мб, чтобы выполнение компиляции и регистрации вошло в приемлемые временные рамки 3-5 секунд.
Честно говоря, когда я сталкиваюсь с подобными примерами, то не могу решить для себя: искусственное снижение производительности программ - это сознательная стратегия поддержки своих коллег из сектора микроэлектроники или же оно отражает падение качества программирования?
Ну ладно, гиганты ИТ-индустрии должны думать о глобальных перспективах, а мы, в свою очередь, можем поиронизировать над прямолинейностью выбираемых ими решений. Но если присмотреться внимательнее, то можно увидеть примеры не очень оптимального программирования и у нас.
Зато мы поддерживаем XML
Сегодня фраза о том, что в продукте обеспечивается поддержка XML, является обязательной для описания любой программы. А в чем именно заключается такая поддержка, зачем она тут нужна и какой толк от нее пользователю - это уже неважно.
К сожалению, порой создается впечатление, что слово "XML" используется по той простой причине, что в качестве достоинств программы больше нечего привести.
На одном из известных российских Web-сайтов для программистов недавно был опубликован набор свободно распространяемых приложений довольно известного российского разработчика (не хотелось бы называть конкретные имена и адреса, чтобы не обижать другие сайты и фирмы). Одна из этих программ при запуске должна формировать список имен, который, что вполне естественно, вводится из внешнего файла.
Операция - совершенно обычная, тривиальная, ее дают в качестве задания на начальном этапе обучения программированию. Самый простой вариант - создать текстовый файл, занимающий при введении в массив шесть строк кода на VB 6.0.
Однако авторы программы предлагают формировать список с применением XML-формата, где каждое имя записано в виде тега.
Код ввода такого файла ненамного сложнее, чем вариант для простого текстового файла (9 операторов).
Но заметьте: кроме увеличения размера загружаемого файла в два раза приложение в этом случае использует достаточно ресурсоемкую библиотеку MS XML Parser 3.0. Тут самое время вспомнить об одной из проблем многокомпонентных приложений под названием DLL Hell (DLL-ад), когда после переноса программы на другой компьютер она отказывается работать из-за отсутствия необходимых компонентов.
Спрашивается: зачем разработчики искусственно заложили эту потенциальную проблему, используя компонент, без которого очень легко обойтись? При этом хотелось бы подчеркнуть, что модель XML DOM в данном приложении нужна только для ввода этого списка имен.
Что в сундучке лежит?
Но увлечение XML-форматом - это еще цветочки. В опубликованном пакете приведены также исходные тексты программных проектов, реализованных на VB 6.0. Весь этот набор должен, по замыслу авторов, демонстрировать не только возможности некоторой новой технологии, но и показывать, как ее могут применять независимые программисты.
В течение последних десяти лет я пишу статьи о программировании на Бейсике (www.visual.2000.ru/develop/vb).
И помимо обсуждения чисто технических приемов мне приходится довольно регулярно затрагивать вопросы "стиля программирования" и на примере присылаемых читателями вопросов показывать, что речь идет не о моде или абстрактных правилах хорошего тона, а о насущных проблемах повышения производительности работы программиста, увеличения надежности программ и снижения стоимости их сопровождения.
Правила же "хорошего стиля" на уровне кодирования отдельных программных процедур довольно просты: избегайте неявного преобразования типов данных, применяйте при прочих равных условиях раннее связывание компонентов, пишите комментарии, старайтесь, чтобы имена переменных отражали смысл их содержимого, используйте простые логические конструкции...
Так вот, обсуждаемый VB-проект - это просто великолепное учебное пособие на тему "как нельзя писать программный код". Ну, стиль-то ладно, дело хозяйское. Какие уж там комментарии и оптимизация логических конструкций, если автор формирует переменные и массивы, которые вообще никак не используются в программе, применяет многомерные массивы для хранения заведомо линейных списков и делает много других удивительных вещей.
Возможно, магическое "используется XML-формат" должно произвести соответствующее впечатление на пользователей, но вот только почему-то тривиальная процедура ввода XML-файла в данном случае заняла не 10, а целых 70 строк кода! Да и как может быть иначе, если число тегов в XML-файле (для резервирования массива нужной длины), которое можно определить простым обращением к свойству Lengh, в этой программе выполняется таким фантастическим способом.
On Error Resume Next
Dim j, z j = -1: z = "~"
Do While (z <> "")
j = j + 1
z = nodelist(j).nodename
If Err.Number > 0 Then Exit Do
Loop
ReDim Names(0 To j-1)
А чего стоит такой шедевр логической конструкции: index = 1
While (index > 0)
‘ тут что-то делаем, но index не меняется
index = 0
Wend которая совершенно эквивалентна строке
‘ тут что-то делаем
На этом я прерву разбор данного полета, так как в программе в 350 строк такие перлы встречаются на каждом шагу. Отмечу только, что для установки и регистрации DLL размером 55 Кб пользователю нужно скачать с Web-cайта инсталляционный модуль объемом 3 Мб.
"Не беда, что все пропало. Лишь бы не было войны!"
Когда я поделился своим удивлением по поводу этого набора программ со знакомым ИТ-менеджером, то услышал весьма характерный ответ: "Ну и что ж такого? Ведь главное, что программа правильно работает! А процессоры и память стремительно дешевеют".
Во-первых, программа не очень точно соответствует объявленным спецификациям (что совсем неудивительно при таком программировании). А во-вторых, дело вовсе не только в стоимости оборудования. Ведь так или иначе, но объем программного кода практически напрямую отражает трудозатраты на разработку, за которую платит заказчик. (Кстати, обсуждаемый программный пакет хотя и бесплатный, но выполнялся на заказ.) И в обосновании цены проекта характеристики "число строк кода" и "человеко-дни" присутствуют регулярно.
К тому же стоит вспомнить, что проблема повышения качества программирования стала активно обсуждаться еще в конце 60-х годов не только в плане повышения производительности труда разработчиков, но прежде всего из-за необходимости улучшения надежности приложений и снижения затрат на их сопровождение. Не говоря о том, что в данном случае речь идет о попытке демонстрации "как нужно писать программы".
Я ожидаю еще одной реакции на свои заметки: "Подумаешь, сколько шуму из-за программы, написанной, наверное, каким-то неуспевающим студентом. Мало ли таких самоделок валяется в Интернете". Я не знаком с автором программ, но дело-то в том, что на ней стоит Copyright компании-разработчика, позиционирующей себя в качестве одного из лидеров российского офшорного программирования.
И речь идет не об отдельной программке, а о довольно солидном наборе приложений (реализованных примерно в том же стиле, что показан выше), который был удостоен даже упоминания в пресс-релизах.
Это я к тому, что при обсуждении перспектив отечественного рынка офшорных разработок, как правило, говорят о проблемах менеджмента, взаимоотношениях с государством и пр., но почему-то изначально считается, что с самим программированием у нас все ОК. Однако после знакомства с приведенным здесь примером (он не единичен!) возникают сомнения в истинности последнего утверждения.
Что же касается данного программного проекта, то меня больше всего удивила смелость разработчика, решившего опубликовать исходный код. Неужели он не боится, что его увидят не только студенты и журналисты, но и потенциальные заказчики?