пять заблуждений, связанных с .NET

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

введение

За несколько лет переписки с людьми, начинающими осваивать технологии .NET, у меня накопился небольшой архив основных заблуждений, связанных с новой платформой. Большая часть из них достаточно смешна и достойна пополнить собой репертуар эстрадных комиков, но, так или иначе, это настоящие причины, останавливающие реальных людей от перехода на .NET. Поэтому, я полагаю, эту статью стоит прочитать тем, кто планирует вводить .NET в своем отделе или всей организации. Я постараюсь показать, как переубедить людей, "одержимых" подобными заблуждениями.

"шпиономания" или заблуждение первое

Управляемый код создан корпорацией Майкрософт для того, чтобы управлять компьютером конечного пользователя, собирать и хранить конфиденциальные данные и вмешиваться в работу (бороться с людьми, использующими нелицензионное программное обеспечение).
Такая точка зрения, несмотря на всю свою смехотворность, достаточно распространена среди далеких от программирования людей (секретарш, бухгалтеров, не ИТ-специалистов, руководителей организаций, не связанных с программированием). И эту точку зрения достаточно сложно победить. Многие люди считают, что Майкрософт и так "качает" персональные и конфиденциальные данные с компьютеров рядовых пользователей.
Но, будучи администратором UNIX-маршрутизатора достаточно долгое время, я собрал некоторые статистические данные по входящему и, главное, исходящему трафику с Windows-машин. Да, действительно, трафик на IP-адреса, принадлежащие Майкрософт, имел место быть, но практически все это - трафик Windows Update. При этом мною был обнаружен также неисследованный (неопознанный) мною трафик, но объемы передаваемых данных были ничтожны (в рассмотрении на всю подсеть). Рискну предположить, что это служебный трафик, но оставлю эту проблему на исследование коллегам.
Люди, более или менее знакомые с .NET, понимают преимущества управляемого кода. Но вашему начальнику (либо человеку, влияющему на решение о введение новой технологии), достаточно знать следующее.
Управляемый код позволяет среде выполнения (CLR) контролировать выполнение непосредственно приложения в рамках установленной политики безопасности.
Перед выполнением, управляемый код проходит специальную проверку (verification) на наличие контроля типов данных (в принципе, возможно установить такую политику безопасности, при которой будет разрешен запуск кода без проверки, но я не рекомендую этого делать). Контроль типов обеспечивает дополнительную защиту данных, устойчивую работу и корректное взаимодействие с другими приложениями.
Управляемые данные, связанные с управляемым кодом - это данные, память под которые выделяется средой. При этом среда отслеживает освобождение ресурсов и самостоятельно проводит сборку мусора (garbage collection).
Пользуясь случаем, отправляю программистов к книге Майкл Ховард, Дэвид Лебланк, "Защищенный код", Русская редакция, 2004. Я настоятельно рекомендую эту книгу всем, независимо от языка или платформы на котором вы пишите свои программы.

заблуждение второе: ASP .NET не позволяет контролировать HTML-код

Как известно почти каждому, кто хотя бы раз пробовал "поиграть" с ASP.NET, для серверных элементов управления код генерируется на лету средой выполнения. При этом разработчик не может никак повлиять на то, что будет отправлено в браузер клиенту.
Да, возможно в этом есть некоторый минус. Но стоит взглянуть с другой стороны - разработчик избавлен от необходимости руками прописывать десятки или даже сотни строк рутинного HTML-кода. Обратите внимание, вряд ли вам захочется когда-нибудь изменять сгенерированный код, тем более, что он вполне соответствует стандарту и не нарушает кросс-браузерной совместимости.
Некоторых программистов, привыкших видеть в браузере именно то, что они написали в программе, несколько оскорбляет тот факт, что ASP.NET имеет несколько иное "представление" кода во время разработки, нежели во время выполнения. Рассмотрим пример:

<asp:hyperlink id="HyperLink1">runat="server" navigateurl="http://localhost" height="16px" width="64px">HyperLink</asp:hyperlink>

Преобразуется в:

<a id="HyperLink1" href="http://localhost"
>HyperLink</a>

Но это уже проблема, связанная с личным вкусом разработчика. Дело в том, что ASP.NET позволяет упростить и ускорить разработку программ для веба, при этом приходится использовать собственное "обозначение" контролов, позволяющее среде определить, чего же именно хочет программист.

заблуждение третье: ASP.NET генерирует код, не соответствующий спецификации

Человека, посетившего сайт консорциума W3C (www.w3c.org), начинает терзать смутное желание проверить свой сайт на "совместимость" со спецификацией HTML. Вот после таких опытов использования HTML Validator и появилось ошибочное мнение, что ASP.NET злостно нарушает спецификацию.
Да, опять нельзя спорить с фактом - странички действительно не пройдут проверку, а Validator выдаст гору ошибок. Но на это у меня есть три ответа.
1. Во многом код страницы зависит от разработчика (многое все-таки можно поменять, даже НУЖНО менять, если вы создаете действительно профессиональный сайт.
2. Попробуйте в сети проверить несколько общепризнанных профессиональных сайтов и найти среди них полностью соответствующие спецификации. Даже больше - много ли сайтов пройдут проверку? Попробуйте на досуге найти хотя бы десяток (чур не пользоваться специальным каталогом!) Несмотря на то, что Perl и PHP позволяют контролировать каждый символ текста страницы. Но кто этим пользуется... /* Черт возьми, пользуемся, и вовсю! :) – прим. ред. */
3. И, главное, покажите мне популярный браузер, который полностью следует спецификации? (Не особо я верю в Opera. Хотя, если кто-то докажет мне обратное - я буду только рад и благодарен за образование.)
Таким образом, следование "букве спецификации" похвально, но не обязательно (в разумных пределах), да и придерживаясь рамок, легко оказаться в клетке. Поэтому незначительное отступление от предлагаемых W3C правил оформления страниц не смертельно.

"проект готов, ну и?" или заблуждение номер четыре

Наконец-то проект готов. Отлажен и протестирован. Программа настолько замечательная, что ее просто обязан иметь каждый пользователь персонального компьютера. Но, вот незадача, на компьютере пользователя не установлены необходимые библиотеки, а программа не работает без них (странно, не правда ли?). Приходится создавать дистрибутив, включая все компоненты в инсталляционный пакет.
Вот тут-то и кроется очередная проблема с пониманием ситуации конечным пользователем. Почему-то пользователь предпочитает установить несколько десятков сомнительных библиотек для разных программ, чем один .NET Framework (который, кстати, включен во все ОС нового поколения) для большого числа программ. А разработчик ломает голову над тем, как заставить пользователя установить 20 Мб "ненужных" ему библиотек. Однако, при достаточно больших размерах дистрибутивов (обычно распространяемых на компакт дисках или по высокоскоростным каналам Интернет), лишние 20 Мб не такая уж и проблема. Сейчас не те времена, когда приходилось неделями писать функцию, реализованную в сторонней библиотеке, чтобы не таскать за собой лишние 300-400Кб "ненужностей".

«опять ООП?» или заблуждение пятое

Последнее заблуждение (из встречаемых настолько часто, чтобы включить в статью) уже точно вызовет улыбку у любого более или менее профессионального программиста (если он уже не скатился под стол, представляя серьезность людей убежденных в первых четырех пунктах).
Заключается оно в неприятии концепции объектно-ориентированного программирования, в том виде, в котором оно представлено в .NET. Версию того, что ООП - абсолютное вселенское зло, предлагают программисты на Visual Basic 6 и более ранних версий. При этом они строго убеждены, что возможности наследования, переопределения свойств и методов родителя - это шаг назад и излишнее (ненужное) усложнение (лично я не понимаю этой точки зрения и не приемлю). Основной аргумент - ядро практически любой ОС пишутся на практически полностью на C, не поддерживающем объектов. При этом С - один из самых мощных языков высокого уровня позволяющий делать то, что не позволяет делать для C++ (согласен с этим, но это не всегда хорошо - иметь возможность сделать что-то extra, например - вызвать ошибку переполнения).
Я не представляю себе ответа на этот вопрос, если вы говорите с профессионалом процедурного программирования, либо с программистом на VB6, убежденным, что он не работал с объектами и они ему не нужны. А С используется потому, что лень (да и накладно) переписывать на C++ (это не единственная причина, но, согласитесь, что-то от правды в этом есть).

заключение

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

Гайдар Магдануров.
Написать данную статью предложил Александр Ложечкин, за что я не могу не выразить ему отдельное спасибо.

обсуждение статьи