О книге “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)
• О принципах проектирования

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

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

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

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