четверг, 26 мая 2011 г.
Синдром рефакторинга
среда, 18 мая 2011 г.
Технический долг
Будь вы простым программистом, матерым лидом, архитектором или даже ПМ-ом, вы наверняка в своей нелегкой работе сталкивались с проблемой выбора при добавлении в систему новой возможности. Одно решение гораздо проще реализовать в сжатые сроки и успеть к очередному очень важному релизу, однако оно будет более затратное в сопровождении, менее расширяемое или менее надежное. Другое решение может не обладать всеми этими недостатками, однако обладать другим, в некоторых случаях более важным недостатком – на его реализацию потребуется значительно больше времени.
При этом самым сложным при выборе того или иного решения является «коммуникация» своего выбора непосредственному руководителю, чтобы он смог принять взвешенное решение. А поскольку с точки зрения большинства руководителей «взвешивание» заканчивается сразу же после того, как он услышит сроки реализации, то «коммуникация» заканчиваются примерно через 37 секунд после ее начала (обычно именно столько времени нужно руководителю, чтобы узнать ответ на очень простой вопрос, выражаемый одним словом: «Когда?»)
Не удивительно, что многие простые программисты, матерые лиды и архитекторы, а иногда даже ПМ-ы, которые понимают, что им самим придется расхлебывать проблемы «близоруких» решений, с таким подходом не согласны. И совершенно не удивительно, что с подобной проблемой сталкивались и другие известные и не очень люди, которые придумали типовые «паттерны», описывающие подобную ситуацию. Одним из таких паттернов, является метафора технического долга, впервые описанная Вардом Каннингемом (Ward Cunningham) (*) без малого двадцать лет назад.
пятница, 13 мая 2011 г.
О книге Марка Руссиновича “Zero Day: A Novel”
В прошлом обзоре новинок компьютерной литературы помимо чисто компьютерных книг была и одна художественная. Это было связано с тем, что автором этой книги является небезызвестный товарищ в компьютерном мире по имени Марк Руссинович (Mark Russinovich), Microsoft Technical Fellow, основатель компании Sysinternals, автор нескольких книг, множества статей по WinAPI и компьютерной безопасности, да и вообще известный парень в не таких уж и узких кругах.
За время, прошедшее с той публикации, я познакомился с творением Марка поближе, так что теперь я могу рассказать о его кибер-триллере более подробно.
вторник, 10 мая 2011 г.
DynamicXml: “динамическая” оболочка для работы с XML данными
Я уже однажды писал о том, что, несмотря на мою любовь к статической типизации, в некоторых сценариях преимущества от той свободы, которую дает динамическая типизация, может превосходить связанные с ней недостатки. В прошлый раз шла речь о Dynamic LINQ, а в этот раз речь пойдет об использовании новой возможности C# 4.0 под названием dynamic, для работы с такими исходно слаботипизированными данными, как XML.
ПРИМЕЧАНИЕ
Исходный код библиотеки DynamicXml, рассматриваемой в данной статье, доступен на github.
Введение
Начиная с версии 4.0, в языке C# появилась поддержка динамического программирования, благодаря новому статическому типу под названием dynamic. По сути, применение этого ключевого слова говорит компилятору сгенерировать весь необходимый код, чтобы процесс привязки (binding) и диспетчеризации вызовов (dispatch operations) производился во время выполнения, вместо определения всех этих характеристик во время компиляции. При этом компилятор генерирует весь необходимый код с помощью библиотеки DLR – Dynamic Language Runtime (*), которая была изначально создана при проектировании языка программирования Iron Python и впоследствии вошла в состав .Net Framework 4.0, как основа для реализации динамических языков программирования, а также для взаимодействия между ними.
четверг, 28 апреля 2011 г.
Дизайн ревью
Совсем недавно один из читателей моего блога спросил моего мнения о применении приемов функционального программирования в таких изначально объектно-ориентированных языках как C#, а также попросил прокомментировать два варианта дизайна кода: одного – чисто объектно-ориентированного, а второго – по его мнению, с уклоном в функциональное программирование. Но поскольку один лишь анализ дизайна потянул на небольшую статейку, то обсуждение интереснейшей темы мультипарадигменного программирования в языке C# мы отложим на следующий раз, а сейчас сосредоточимся исключительно на дизайне.
Постановка задачи
Итак, можно представить, что мы с вами проводим что-то вроде дизайн ревью, входными данными которого является не подробная спецификация с кучей диаграмм, а всего лишь несколько фрагментов кода, по которому нам с вами нужно принять решение, каким путем идти. Основная суть задачи, о которой идет здесь речь, заключается в проектировании иерархии команд (паттерн «Команда»), при этом каждое действие команды состоит из двух составляющей: непосредственной бизнес-логики команды и некоторого завершающего действия. При этом известно, что для одного конкретного вида бизнес-логики может существовать несколько разных завершающих действий.
Команда разработчиков представила два варианта дизайна: первое решение сводится к тому, что завершающее действие в виде делегата передается классу конкретной команды через конструктор, а во втором решении для этого создается соответствующий подкласс. При этом сторонники второго подхода придерживаются мнения, что использование делегатов не является чистым подходом с точки зрения ООП, сторонники же первого подхода считают такое поведение нормальным. Теперь давайте посмотрим на предоставленные нам фрагменты кода.
воскресенье, 17 апреля 2011 г.
С юбилеем, RSDN!
Я до сих пор помню один интересный случай, который произошел со мной, еще во время учебы в универе. Я тогда совсем недавно пошел работать в одну небольшую Донецкую компанию, в которой начал заниматься разработкой охранных систем, и, как-то после пар мы с моим другом заговорили за мою работу. И когда я с жаром начал рассказывать о каких-то новых вещах, которые узнал за несколько месяцев разработки встроенных систем на С++, Витя, который пошел работать на пару лет раньше меня, сказал:
- Ничего, Серега, еще годик-другой поработаешь, и отношение к работе у тебя изменится.
С того памятного разговора прошло уже без малого восемь лет, а мое отношение к работе, к изучению чего-то интересного и нового осталось таким же самым.
четверг, 14 апреля 2011 г.
Классические книги по C#/.NET
Однажды я задался целью собрать в одном месте наиболее влиятельные книги по программированию с точки зрения компьютерной общественности. Конечно же, выполнить эту задачу практически невозможно по нескольким простым причинам: во-первых, понятия у «компьютерной общественности» настолько широки и настолько сильно отличаются от индивида к индивиду, что говорить о каком-то списке, подходящем всем и каждому очень сложно. Кроме того, хотя и старался быть непредвзятым, в список все же попали книги, которые, прежде всего, произвели на меня лично сильное впечатление. Вторая проблема того списка заключалась в том, что понятие «книги по программированию» также слишком широко. Как правильно заметил старина Брукс в своем «человеко-месяце», количество направлений компьютерной науки сейчас столь огромно, что одному человеку достаточно глубоко охватить все, Бог ты мой, даже основные темы, связанные с программированием практически невозможно. Ну, и последним недостатком предыдущей статьи является достаточно поверхностный охват каждой из тем; многие жаловались на то, что в списке по той или иной теме не хватает слишком многих хороших книг.
Покумекав немного обо всем об этом я решил сделать несколько отдельных сообщений, в каждом из которых можно было бы поглубже сосредоточиться лишь на одной теме. И поскольку я занимаюсь именно языком C# и платформой .Net, то начну я именно с этой темы.