О менторах и менторстве

В некотором роде этот «капитанский» пост можно считать продолжением популярного прошлогоднего поста Увлеченный программист, в котором тема менторства уже поднималась.

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

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

Фильтры исключений в C# 6.0

Одной из новых возможностей языка C# 6.0 являются фильтры исключений.

Общая идея довольно простая: рядом с блоком catch появляется возможность задать некоторый предикат, который будет определять, будет ли вызван блок catch или нет.

Данный вариант синтаксиса доступен в публичной версии VS2015, но он будет изменен в финальной версии языка C#. Вместо if будет использоваться ключевое слово when.

Интерфейсы vs. Абстрактные классы

DISCLAIMER: ниже речь идет об интерфейсах и абстрактных классах на платформе .NET. Большая часть рассуждений применима и к другим языкам, с разделением понятий интерфейсов и классов.

Между интерфейсами и абстрактными классами нет особой разницы с точки зрения моделирования. И то, и другое определяет «абстрактный интерфейс» семейства объектов и разница есть лишь в том, существует ли поведение по умолчанию или нет.

Когда мы моделируем предметную область нет разницы между интерфейсом IPrecondition и абстрактным классом Precondition. Оба эти понятия моделируют семейство предусловий, но первый лишь декларирует открытый интерфейс этого семейства, а второй позволяет ограничить и использовать повторно часть реализации.

Разница появляется с точки зрения языка программирования, разработчики которого решили не морочить голову с полноценным множественным наследованием: «ромбовидным наследованием», конфликтами имен из разных базовых классов и т.п. вещами.

В языках с множественным наследованием, таких как С++ или Eiffel, понятие интерфейса отсутствует, в нем просто отпадает необходимость. Отсутствие полноценного множественного наследования влияет на то, как мы проектируем иерархию классов.

Для чего нужны интерфейсы?

В чем сила интерфейсов? Сила интерфейсов в правде слабости системы типов!

Принято считать, что интерфейсы предназначены для моделирования абстракций и обеспечения слабой связанности (loose coupling). Звучит умно, но что это значит?

Что дают интерфейсы?

Наследование моделирует семейство объектов с общим поведением. Интерфейс и абстрактный класс определяет «протокол» этого семейства, а наследники определяют конкретную реализацию. Разные виды предусловий можно спрятать за интерфейсом IPrecondition, разные виды стратегий сортировки – за ISorter, разные виды импортеров/экспортеров – за Importer/Exporter.

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

DI vs. DIP vs. IoC

Существует три схожих понятия, связанных передачей и управлением зависимостями, в каждом из которых есть слово “инверсия” (inversion) или “зависимость” (dependency):

• IoC – Inversion of Control (Инверсия управления)
• DI – Dependency Injection (Внедрение зависимостей)
• DIP – Dependency Inversion Principle (Принцип инверсии зависимостей)

Подливает масло в огонь рассогласованность использования этих терминов. Так, например, контейнеры иногда называют DI-контейнерами, а иногда IoC-контейнерами. Большинство разработчиков не различает DI и DIP, хотя за каждой из этих аббревиатур скрываются разные понятия.

Когда предусловия не являются предусловиями

UPDATE: библиотека Code Contract знает о тонкостях реализации таких возможностей как async/await и блоков итераторов. Поэтому описанные ранее проблемы касаются лишь старых (legacy) предусловий, основанных на if-throw. Если вы зашли сюда первый раз, то просто не обращайте внимания на этот абзац!

Что такое предусловие? Это некоторое утверждение, которое должно быть истинным во время вызова метода, причем за его истинность отвечает вызывающая сторона. Предусловия включают в себя проверку аргументов или внутреннего состояния объекта, а его нарушение проявляется в генерации вызываемым кодом исключений ArgumentException для невалидных аргументов, и InvalidOperationException для вызова метода в невалидном состоянии объекта.

Другими словами, предусловия гарантируют, что вызывающий код находится в нужном состоянии и ему передали все нужные данные для выполнения своей работы:

// class CustomStream
public Task<string> ReadString(int position)
{
    if (position < 0)
        throw new ArgumentOutOfRangeException("position");
    if (CanRead)
        throw new InvalidOperationException("Stream is not readable");
 
    return Task.FromResult("42");
}

О логировании исключений и Exception.ToString

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

Очень неприятно, когда тебе приходится разбираться с проблемой на боевом сервере в час ночи, когда все, что ты видишь в логе – загадочную строку “Exception has been thrown by the target of an invocation” или “The type initializer for ‘YourBestTypeInTheWorld’ threw an exception”. А все потому, что кто-то умудрился сохранять в лог не все исключение, а лишь его сообщение.

О книге “Writing High-Performance .NET Code”

Как-то давно не было рецензий умных книжек, так что пришло время это исправить. Недавно, уважаемый Sinix на rsdn.ru упомянул о книге, с любопытным названием “Writing High-Performance .NET Code”. Я вообще не собирался переключаться пока на литературу по .NET-у, но поскольку по работе мне нужно было пообщаться поближе с виндовыми счетчиками производительности (a.k.a. performance counters), а они были описаны в одной из глав этой книги, то меня как-то зацепило.

Ну, ок. Давайте поговорим о высокопроизводительном .NET коде. Что это такое и бывает ли вообще? Тут сказать сложно. Когда речь заходит о действительно высокой производительности, то практика показывает, что с управляемыми языками, несмотря на все заявления, добиться высокой производительности не всегда возможно. Мы можем создать эффективное управляемое приложение, но если наша цель – эффективно использовать каждый такт процессора, то неуправляемый код все равно будет впереди планеты всей. Достаточно вспомнить, что ядро виндофона ушло от управляемого кода на неуправлямый, да и Windows Runtime сложно назвать полностью «управляемой платформой».

Майкрософт. Часть 1

Со 2-го сентября этого года я перешел работать в Майкрософт. Позиция SDE 2, Developer Division, Visual Studio Online, проект – Application Insights.

Шпаргалка по SOLID принципам

S – The Single Responsibility Principle

Название: Принцип единственной ответственности.

Определение: У класса/модуля должна быть лишь одна причина для изменения.

Смысл принципа: Борьба со сложностью, важность которой резко возрастает при развитии логики приложения.

Краткое описание: Любой сложный класс должен быть разбит на несколько простых составляющих, отвечающих за определенный аспект поведения, что упрощает как понимание, так и будущее развитие.

Типовые примеры нарушения: 1) смешивание логики и инфраструктуры: бизнес-логика смешана с представлением, слоем персистентности, находится внутри WCF или windows-сервисов и т.п. 2) класс/модуль решает задачи разных уровней абстракции: вычисляет CRC и отправляет уведомления по электронной почте; разбирает json-объект и анализирует его содержимое и т.п.

Anti-SRP – Принцип размытой ответственности. Чрезмерная любовь к SRP ведет к обилию мелких классов/методов и размазыванию логики между ними.

О принципах проектирования

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs ООП)
• L – Liskov Substitution Principle (LSP. Часть 2. О наследовании)
• I – Interface Segregation Principle
• D – Dependency Inversion Principle (Критический взгляд на DIP)
• О принципах проектирования

--------------------------------------------------

Для чего выдумывать все эти паттерны проектирования, принципы и методики? Разве не было бы проще обойтись без всего этого, а просто научить разработчиков хорошему дизайну? Или почему бы не формализовать этот процесс и ввести четкие количественные метрики, которые бы говорили, что одно решение однозначно лучше другого?

«Правильный дизайн» - это святой Грааль молодых разработчиков и молодых менеджеров. И те, и другие мечтают найти ответ на главный вопрос жизни, вселенной и всего такого разработки ПО – как добиться качественного дизайна, в сжатые сроки и с минимумом усилий.

Со временем и молодой разработчик, и молодой менеджер придут к пониманию того, что это невозможно. Невозможно найти идеальный абстрактный дизайн, поскольку слова «идеальный» и «абстрактный» противоречат друг другу. Дизайн – это постоянный поиск компромисса между противоречивыми требованиями: производительностью и читабельностью, простотой и расширяемостью, тестируемостью и цельностью решения.

The Dependency Inversion Principle

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs ООП)
• L – Liskov Substitution Principle (LSP. Часть 2. О наследовании)
• I – Interface Segregation Principle
• D – Dependency Inversion Principle (Критический взгляд на DIP)
• О принципах проектирования

--------------------------------------------------

Принцип инверсии зависимости (Dependency Inversion Principle – DIP):

• Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций.
• Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Роберт Мартин «Принципы, паттерны и методики гибкой разработки» ([Martin2006]).

Принцип инверсии зависимостей – один из самых известных сегодня принципов проектирования, который лежит в основе популярных техник внедрения зависимостей (Dependency Injection). Однако, если посмотреть лишь на его название и описание, то будет довольно сложно понять, что же он означает. Поэтому, если спросить простых обывателей о том, что означает этот принцип, то они начнут что-то говорить о пользе интерфейсов и абстракций, и, вообще, будут путаться в показаниях.

LSP Часть 2. О сложностях наследования

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs ООП)
• L – Liskov Substitution Principle (LSP. Часть 2. О сложностях наследования)
• I – Interface Segregation Principle
• D – Dependency Inversion Principle (Критический взгляд на DIP)
• О принципах проектирования

--------------------------------------------------

Бытует мнение, что генерация исключений InvalidOperationException или NotSupportedException методами наследника означает нарушение этим классом принципа замещения Лисков. И хотя в некоторых случаях это действительно так, судить так однозначно нельзя.

Является ли нарушением LSP, что ImmutableList<T> и ReadOnlyCollection<T> реализует IList<T>, поскольку попытка добавления элемента в такую коллекцию приводит к генерации NotSupportedException? Может показаться, что нарушают, однако в «контракте» интерфейса IList<T> четко сказано, что метод Add будет добавлять элемент, только в случае выполнения «предусловия» – коллекция должна быть изменяемой! Аналогично дела обстоят с потоками ввода вывода, методы Read/Write которых могут генерировать исключения, если свойствами CanRead/CanWrite возвращают false. Во всех этих случаях мы можем говорить о неудачном дизайне, но не можем говорить о нарушении принципа подстановки Лисков!

Liskov Substitution Principle

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs ООП)
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle
• О принципах проектирования

--------------------------------------------------

Принцип подстановки Лисков (Liskov Substitution Principle, LSP):

Должна быть возможность вместо базового типа подставить любой его подтип.
Роберт К. Мартин "Принципы, паттерны и практики гибкой разработки", 2006

...если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в терминах T, поведение P не изменяется при замене o2 на o1, то S является подтипом (subtype) для T.
Барбара Лисков "Абстракция данных и иерархия", 1988

Наследование и полиморфизм является ключевым инструментом ОО разработчика при борьбе со сложностью, для получения простого и расширяемого решения. Наследование используется в большинстве паттернов проектирования и лежит в основе таких принципов, как Open-Closed Principle и Dependency Inversion Principle.

Open/Closed Principle. ФП vs. ООП

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs. ООП)
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle
• О принципах проектирования

--------------------------------------------------

Как мы выяснили в прошлый раз, принцип открыт/закрыт подразумевает две вещи: необходимость фиксации интерфейса с возможностью изменения реализации, а также расширяемость за счет использования наследования и полиморфизма.

Давайте рассмотрим вопрос расширяемости в рамках семейства типов более подробно.

Большинство примеров, показывающих пользу «открытости» модулей обычно сводятся к демонстрации мощи полиморфизма над старым структурным подходом: «Смотрите, как здорово, когда мы избавляемся от конструкции switch в функции Draw и переносим всю логику в класс Shape и его наследники! Теперь наше решение является расширяемым и соответствует принципу Открыт/Закрыт, поскольку мы легко можем к квадрату и треугольнику добавить еще ромб с кругом!».

Да, действительно, добавить новый класс в существующую иерархию довольно легко, но что если мы хотим добавить в существующую иерархию новую операцию, например, метод GetArea в иерархию Shapes?

Open/Closed Principle

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open/Closed Principle (Часть 2. ФП vs. ООП)
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle
• О принципах проектирования

--------------------------------------------------

Принцип открыт/закрыт (Open-Closed Principle, OCP): Программные сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.
Роберт Мартин. Принципы, паттерны и практики гибкой разработки, 2010

Из всех «цельных» (SOLID) принципов, принцип Открыт/Закрыт является самым неоднозначным. Его неоднозначность кроется в противоречивости его определения (как что-то может быть одновременно «открытым» и «закрытым»?), а подкрепляется неоднозначными и разнообразными формулировками этого принципа в разных источниках. Не удивительно, что даже такие монстры, типа Эрика Липперта или Джона Скита относятся к этому принципу неоднозначно и признаются в его непонимании.

Single Responsibility Principle

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs. ООП)
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle
• О принципах проектирования

--------------------------------------------------

Принцип единственной обязанности (Single-Responsibility Principle, SRP): У класса должна быть только одна причина для изменения.
Роберт Мартин. Принципы, паттерны и практики гибкой разработки

Существует ряд патологических случаев нарушения принципа единственной обязанности, которые будут очевидны сегодня практически любому. Классы бизнес-логики, которые знают о пользовательском интерфейсе или о базе данных; класс windows-сервиса c кучей бизнес-логики; статические утилитные классы, изменяющие глобальное состояние и т.п.

При этом нарушение SRP бывают как на уровне классов/модулей, так и на уровне подсистем и приложений. Классическим примером из моей практики являются два вопиющих нарушения SRP на уровне приложений: использование Windows Forms приложения в качестве WCF сервиса, и необходимость взаимодействия виндового сервиса с пользователем через Message Box-ы.

Interface Segregation Principle

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs. ООП)
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle
• О принципах проектирования

--------------------------------------------------

Вы никогда не ловили себя на мысли, что Принцип разделения интерфейса (ISP, Interface Segregation Principle) вам не вполне понятен или, что он является лишь разновидностью принципа единой ответственности (SRP, Single Responsibility Principle)? До недавнего времени у меня было подобное отношение, но оно несколько изменилось, после того, как я посмотрел на него с другой точки зрения.

Причина некоторого недопонимания принципа ISP, как мне кажется, кроется вот в чем. Во-первых, ISP отличается от других принципов SOLID тем, с какой стороны он применяется (об этом позднее), а во-вторых, у него далеко не самое лучшее определение.

Давайте начнем с определения. Вот формулировка принципа ISP из любимой мною книги Боба Мартина «Принципы, паттерны и методики гибкой разработки»:

"Этот принцип относится к недостаткам "жирных" интерфейсов. Говорят, что класс имеет жирный интерфейс, если функции этого интерфейса недостаточно сцепленные (not cohesive). Иными словами, интерфейс класса можно разбить на группу методов. Каждая группа предназначена для обслуживания разных клиентов. Одним клиентам нужна одна группа методов, другим – другая."

Контракты vs. Монады?

DISCLAIMER: чтобы было легче понять, о чем пойдет речь в этой заметке, стоит прочитать заметку "Борьба с "нулевыми" ссылками в C#".

Q: Если бы в BCL был тип Optional<T> или Nullable<T> для ссылочных типов, ты бы его использовал в своем коде?

A: Да, конечно!

Q: Значит, тогда ты бы отказался и от контрактов?

A: …

Примерно такой диалог произошел у меня после прошедшей вчера встречи Kiev ALT.NET, посвященной вопросам борьбы с нулевыми ссылками в C# (вот презентация с выступления, а вот – код).

У этого вопроса есть один простой ответ, и звучит он так: «Нет, я не откажусь от контрактов!», но поскольку подобная форма ответа не слишком информативна, то я готов объяснить свою точку зрения более подробно.

Еще одна книга по паттернам? Дайте две!

Привет, читатель! Я хочу поговорить с тобой о паттернах проектирования. Знаешь, это такая старая штука, о которой модно было писать в конце прошлого века, и некоторые изверги о них еще иногда спрашивают на собеседованиях. У меня возникла мысль, что пришла пора снова вспомнить о них, но на этот раз рассмотреть их в современных реалиях. А разве есть более подходящий способ это сделать, кроме как взять ... и написать об этом книгу?

Книги по дизайну и ООП

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

Невозможно стать хорошим архитектором прочитав несколько книг, поскольку нужно четко понимать, как конкретное теоретическое решение отражается в реальных системах. Я никак не могу помочь вам с практикой, но могу посоветовать хорошую литературу в области ООП/ООД/ФП.

Как проводить технические собеседования?

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

Для чего мы проводим собеседование? Мы хотим найти кандидата, который бы подходил под наши требования «подходящего» разработчика. Но поскольку мы не можем взять человека и посадить его на три недели за решение наших текущих задач, мы придумываем некую модель, соответствие которой означает, что кандидат нам подходит.

Хорошая, модная и плохая гибкая разработка

и о книге Бертрана Мейера "Agile!: The Good, the Hype and the Ugly"

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

Бертран Мейер "Agile!: The Good, the Hype and the Ugly"

Сейчас гибкие методы (agile methods) являются чуть ли не стандартом в современной разработке ПО. Все проводят статус митинги, ретроспективы, пишут user stories и тест-кейсы, делают частые релизы и привлекают бизнес-пользователей; ненавидят "водопадные" методы и доказывают вред переработок. Часть принципов и практик гибкой разработки стали частью нашей жизни, и уже появилось целое поколение разработчиков, которые даже не слышали про альтернативные методологии.

Is TDD Dead. Часть 5

В то время, как в Виларибо спорят жив ли TDD или мертв, в Вилабаджо думают, а стоит ли компилировать код перед коммитом.

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

Is TDD Dead. Part V on Youtube. В целом, получилось более затянуто чем обычно (ведь выступление длилось в двое дольше), но, как всегда, весьма любопытно.

Проблема обсуждения вопросов дизайна

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

Обсуждение вопросов дизайна является довольно сложным вопросом и у этого есть как минимум несколько причин. Во-первых, дизайн любой системы постоянно развивается, при этом результат зависит не только от способностей членов команды, но и от исторического контекста (злосчастное, «исторически сложилось»). Это значит, что мы не можем судить о существующем дизайне в вакууме, нам нужно еще и понимать, как мы к нему пришли и какие проблемы считали наиболее приоритетными. Во-вторых, не существует достаточно объективной меры качества дизайна, которая бы четко доказывала, что одно решение действительно лучше другого. В-третьих, при обсуждении вопросов дизайна автор статьи или книги сталкивается с вопросом выбора размера и сложности примера. С одной стороны, нет смысла рассматривать продвинутые техники проектирования на примитивных примерах, ведь примитивные задачи можно решить любым способом. С другой стороны, автор не может давать слишком сложные примеры, поскольку 90% читателей просто не захотят тратить свое время и с ними разбираться.

Борьба с "нулевыми" ссылками в C#

UPDATE: интересно продолжение этой статьи? Читайте: “Контракты vs. Монады?”.

Вступление

В моих черновиках уже больше года лежит статья, в которой я хотел рассказать о проблеме разыменовывания пустых ссылок (null reference dereferencing), с подходами в разных языках и платформах. Но поскольку у меня все никак не доходили руки, а в комментариях к прошлой статье ("Интервью с Бертраном Мейером") была затронута эта тема в контексте языка C#, то я решил к ней все-таки вернуться. Пусть получилось не столь фундаментально как я хотел изначально, но букв и так получилось довольно много.

Ошибка на миллиард долларов?

В марте 2009-го года сэр Тони Хоар (C.A.R. Hoare) выступил на конференции Qcon в Лондоне с докладом на тему "Нулевые ссылки: ошибка на миллиард долларов" (Null References: The Billion Dollar Mistake), в котором признался, что считает изобретение нулевых указателей одной из главных своих ошибок, стоившей индустрии миллиарды долларов.

Интервью с Бертраном Мейером

Не так давно, мне посчастливилось взять интервью у Бертрана Мейера, того самогоJ, автора самого фундаментального труда в области ООП и разработке ПО (это я все о том же талмуде "Объектно-ориентированное конструирование программных систем"), у человека, который внес неоценимый вклад в развитие инженерных аспектов разработки ПО, в формализацию объектной методологии, а также процесс разработки в целом.

Возможность эта появилась у меня благодаря Учебному Центру Люксофт, который организует мастер класс Бертрана по теме "Design by Contract" (на который, кстати, могут записаться все желающие за умеренную плату;)). И мы решили, что было бы неплохо пообщаться с Бертраном до этого и обсудить некоторые интересные моменты разработки ПО.

Перед интервью я подготовил список вопросов на 3 страницы (!), к сожалению, из-за ограничения по времени я так и не узнал, чья же версия принципа открыт-закрыт является более разумной – Бертрана или "дядюшки" Боба. Но несмотря на это, мы успели обсудить много интересного, начиная от контрактов, заканчивая идеями из новой книги Бертрана под названием "Agile!: The Good, the Hype and the Ugly".

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

Модульный тест: определение

В наших с вами интернетах недавно поднялся нешуточный шум по поводу того, жив ли TDD сейчас, нужен ли он, и в каком виде. Все началось со статьи Дэвида Хансона "TDD is dead. Long living testing", после которой последовали статьи многих авторов и живые обсуждения этой проблемы включая hangout вместе с Дэвидом, Кентом Беком и Мартином Фаулером .

Но немногие знают, что за несколько дней до этого все тот же Мартин Фаулер постарался дать определение модульного теста (bliki:UnitTest), перевод которого представлен ниже. А после перевода идут кое-какие мои мысли по этому поводу.

---------------------------------

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

Паттерн Итератор

Пред. паттерн: Паттерн Посредник

Назначение: представляет доступ ко всем элементам составного объекта, не раскрывая его внутреннего представления.

Подробнее – Iterator on Wiki

Мотивация

Практически любое приложение в той или иной мере работает с коллекциями данных. Мы постоянно используем векторы, списки, деревья и хеш-таблицы. В некоторых случаях для обработки данных коллекции мы используем специфический API конкретных коллекций, но в большинстве случаев мы получаем доступ к их внутренностям за счет специального абстрактного слоя – итераторов.

Книги для изучения C#/.NET

DISCLAIMER: выбор хорошей книги – это довольно сложный и индивидуальный процесс. Список ниже основывается на моем личном опыте и обилии "перекрестных ссылок" из разных книг, статей, обсуждений в форумах и личных обсуждениях с коллегами. Если вдруг вы не увидите свою любимую книгу в этом списке, это не значит, что она его недостойна, возможно, она просто аналогично одной из книг, представленных ниже.

Пришло время немного переформатировать старый пост с "классическими книгами по C#/.NET", чтобы отразить не просто список достойных источников для изучения C#/.NET, но и упростить выбор нужных книг в зависимости от уровня и потребностей читателя.

Об автоматизированном тестировании

и книге Стива Фримана "Growing Object-Oriented Software Guided by Tests"

DISCLAIMER: как и многие ревью, в этот раз будет гораздо больше обсуждений темы дизайна и автоматического тестирования, чем непосредственно рецензии книги. Так что, не проходите мимо!

Содержание

• Почему столько мнений?
• Замедляют ли они разработку и окупаются ли они позднее?
• Как тесты влияют на процесс разработки?
• Все ли нужно тестировать и достаточно ли юнит-тестов?
• Тесты вперед или назад?
• Каким должно быть качество тестов?
• Подходы к улучшению кода тестов
• О книге "Growing Object-Oriented Software Guided by Tests"

В мире разработки ПО нет более неоднозначной темы, чем тестирование. Нет, я не о тестировании ПО в целом, тут все ясно, оно нужно, без него никак. А вот отношение к автоматическим тестам и особенно к юнит-тестам весьма неоднозначное.

О книге Джошуа Кериевски «Рефакторинг с использованием шаблонов»

Если посмотреть на опыт использования паттернов проектирования, то он разнится от «это самая ценная штука в арсенале разработчика», до «любителям паттернов проектирования нужен особое место в аду, в котором их ждет синглтонная фабрика со стратегией кипячения в абстрактном котле систем с унаследованным кодом». Если говорить проще, то паттерны – это такой инструмент, который в умелых руках будет помогать, а в неумелых – серьезно осложнит сопровождение полученной системы. (Что, на самом деле, характерно для любого инструмента, а не только для паттернов проектирования, см. Культ Карго в программировании.)

Именно такое отношение к паттернам и сподвигло меня к написанию серии постов о паттернах проектирования в современном мире, которую я решил разбавить парой рецензий.

Паттерн Посредник

Пред. запись: RAII в C#. Локальный Метод Шаблона vs. IDisposable

Назначение: Определяет объект, инкапсулирующий способ взаимодействия множества объектов.

Другими словами: Посредник – это клей, связывающий несколько независимых классов между собой.

Описание: Посредник обеспечивает слабую связанность (low coupling) системы, избавляя объекты от необходимости явно ссылаться друг на друга, позволяя тем самым независимо изменять их и взаимодействия между ними.

Подробнее – Mediator on Wiki

Мотивация

В качестве примера, давайте отойдем от темы анализа паттернов проектирования и посмотрим на пример, приведенный Робертом Мартином в своей статье "Принцип инверсии зависимостей" (Robert Martin – Dependency Inversion Principle) и в своей книге "Принципы, паттерны и методики гибкой разработки на языке C#".

RAII в C#. Локальный Метод Шаблона vs. IDisposable

Пред. запись: Шаблонный Метод
След. запись: Паттерн Посредник

Данная статья является продолжением обсуждения паттерна Шаблонный Метод, начатого в прошлый раз.

Одной из ключевой идиом языка С++ является идиома RAII – Resource Acquisition Is Initialization. Главная ее идея заключается в том, что некоторый ресурс, например, память, дескриптор, сокет и т.п. захватывается в конструкторе и освобождается в деструкторе. А поскольку деструкторы локальных объектов вызываются обязательно, независимо от того, по какой причине управление покидает текущую область видимости, мы получаем полуавтоматическое управление ресурсами.

При этом «автоматическое управление» применяется не только для ресурсов – памяти, дескрипторов, файлов или сокетов, но и для других целей. Так например, автоматический вызов деструктора используется в многопоточных приложениях для реализации критических секций в коде. Для этого используются классы std::mutex, а также класс std::unique_lock, который захватывает блокировку в конструкторе и освобождает в деструкторе:

Паттерн Шаблонный Метод

Пред. запись: Паттерн Стратегия
След. запись: RAII в C#. Локальный Метод Шаблона vs. IDisposable

Назначение: Шаблонный Метод определяет основу алгоритма и позволяет подклассам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом.

Другими словами: шаблонный метод – это каркас, в который наследники могут подставить свои реализации.

Подробнее – Template Method Pattern on Wiki

Общие сведения

На заре своего становления, наследование считалось ключевой концепцией ООП для расширения и повторного использования кода. Однако со временем, многим разработчикам стало очевидно, что наследование не такой уж и простой инструмент, использование которого приводит к сильной связности (tight coupling) между базовым классом и его наследником. Эта связность приводит к сложности понимания иерархии классов, а отсутствие формализации отношений между базовым классом и наследниками не позволяет четко понять, как именно разделены обязанности между классами Base и Derived, что можно делать наследнику, а что – нет.

Паттерн Стратегия

Пред. запись: GoF паттерны на платформе .NET
След. запись: Паттерн Шаблонный Метод

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

Другими словами: стратегия инкапсулирует некоторое поведение с возможностью его подмены.

Подробнее – Strategy Pattern on Wiki

Мотивация

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

GoF паттерны на платформе .NET

След. запись: Паттерн Стратегия

Посты серии:

• Паттерн Стратегия
• Паттерн Шаблонный Метод
• RAII в C#. Локальный Метод Шаблона vs. IDisposable
• Паттерн Посредник

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

Так, когда в начале 90-х на арене программного мира появились паттерны проектирования, многие начали мечтать о том, что благодаря им даже бизнес-пользователи и 1С программисты смогут собирать приложение из готовых кирпичиков. Довольно быстро стало ясно, что этого не случится и начали искать другие подходы, включая программирование через конфигурацию, пламенно воспетую Хантом и Томасом в их «Программисте-прагматике». Затем появились IoC (или DI) контейнеры и начался новый этап создания «слабосвязанных приложений», разбираться с которыми стало еще сложнее, чем прежде благодаря замене «физической» (прямой) связи между компонентами на «логическую» (косвенную).

Ключевые концепции DDD

… и рецензия книги Эрика Эванса “Domain-Driven Design: Tackling Complexity in the Heart of Software”

Хороший дизайн приложения является главной основой любого приложения. Чрезмерная сложность дизайна приводит к увеличению стоимости изменений и некоторой «хаотичности» этого процесса. Чрезмерная простота – оставляет бреши в полученных моделях, в результате чего приложение может не выполнять тех функций, ради которых оно разрабатывается.

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

О фреймворках и свободе

“Множество переусложненных решений (overengineering) было принято во имя гибкости. Но дополнительные уровни абстракции и уровни косвенности гораздо чаще мешают, нежели помогают в этом деле. Посмотрите на дизайн систем, которые действительно вдохновляют программистов, занимающихся их разработкой, и как правило вы увидите нечто простое. Простого решения добиться не просто (simple is not easy).”

Эрик эванс "Domain-Driven Design: Tackling Complexity in the Heart of Software"

Обсуждая те или иные вопросы дизайна уже неоднократно поднимался вопрос гибкости vs. простоты решения. С одной стороны, гибкость очень привлекательна. Что может быть лучше, чем возможность на лету адаптировать приложение под изменившиеся требования? И хотя эта мысль очень заманчива, большинство опытных разработчиков знают, что она утопична, если она приходит в начале работы над проектом.

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

Microsoft Fakes. Тестирование поведения

DISCLAIMER: исходный код Verification Fakes можно найти на github, а скомпилированная версия доступна через nuget.org/packages/VerificationFakes.

В прошлой заметке мы рассмотрели примеры использования Microsoft Fakes для создания стабов – заглушек, возвращающих требуемые данные. Однако в некоторых случаях нам все же нужно проверить, что в определенных условиях тестируемый класс обращается к некоторой зависимости. Такой вид тестирования называется тестированием поведением и именно такой вид «подделок» каркасом Microsoft Fakes практически не поддерживается.

Microsoft Fakes. Тестирование состояния

Все приведенные примеры можно найти на github.

Microsoft Fakes – это очередной изоляционный фреймворк, который является логическим продолжением экспериментального проекта Microsoft Moles.

Все изоляционные фреймворки делятся на несколько категорий, в зависимости от времени генерации «подделок» и их типу:

По времени генерации:

• генерация на лету во время исполнения тестов;
• во время компиляции;

По типу генерируемых «подделок»:

• на основе полиморфизма, что позволяет «мокать» лишь полиморфные методы;
• на основе CLR Profiling API, что позволяет мокать невиртуальные методы, включая статические.

О пользе выбора

Мы очень часто сталкиваемся с дилеммой при разработке проекта или одной из его фич: что выбрать, подход А или подход Б? Что лучше, использовать WCF или веб-сервисы; Entity Framework или NHibernate; читать конфигурацию из файла конфигурации или из базы данных?

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

Поскольку иногда бывает сложным убедить собеседника в своей правоте мы можем прийти к заключению, что нужно найти компромиссное решение. Здесь мы ступаем на очень тонкий лед. Может показаться, что лучшим решением этой дилеммы будет создание гибкого решения, которое будет удовлетворять обоим подходам одновременно. Очевидно, что в этом случае мы не просто сможем переключаться от одного решения к другому: мы поддерживаем два решения сразу! Разве не прекрасно?

Ретроспектива 2013

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

При этом если посмотреть на категорию статей, то легко заметить, что акцент в прошлом году сместился с описания тонкостей языка C# в сторону дизайна приложений. Дизайн (не важно, ОО, ФП или какой еще) – это одна из самых интересных областей разработки ПО.