понедельник, 19 декабря 2016 г.

Реализация синглтонов в .NET: Field-like vs. Lazy

Недавно один из читателей задал вопрос по поводу разницы между двумя реализациями синглтонов: через обычное статическое поле или же через статическое поле, содержащее Lazy<T>:

public class FieldLikeSingleton
{
    // Вариант C# 6
    public static FieldLikeSingleton Instance { get; } = new FieldLikeSingleton();

   
private FieldLikeSingleton() 
{}
}


public class FieldLikeLazySingleton
{
    private static readonly Lazy<FieldLikeLazySingleton> _instance =
 
       
new Lazy<FieldLikeLazySingleton>(() => new FieldLikeLazySingleton());

   
public static FieldLikeLazySingleton Instance => _instance.Value;

   
private FieldLikeLazySingleton() {}
}

Для простоты, первую реализацию я буду называть field-like реализацией (*), а вторую – ленивой.

 

понедельник, 21 ноября 2016 г.

Горизонтальные и вертикальные слои приложения

«У лука есть слои, и у людоедов есть слои! Ты понял?» - Шрек

Эта заметка навеяна выступлением Jimmy Bogard на 0redev под названием “Solid Architecture in Slices not Layers”, которую я всячески рекомендую.

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

Conway’s Law

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

Такой разделение еще сильнее выстраивает барьеры между слоями приложения, поскольку тут начинает во всей красе проявляться Conway’s Law, когда архитектура приложения начинает повторять структуру организации.

понедельник, 14 ноября 2016 г.

Памятка ынтырпрайз кодера

После прочтения “Release It!” захотелось сохранить ряд мыслей по поводу разработки распределенного ынтырпрайз софта. То, о чем нужно думать, что нужно подпилить, о чем нужно не забыть и т.п.

1. Все что может отвалиться, обязательно отвалится

База ляжет, удаленный веб-сервис начнет тупить, перестанет проходить автортизация, ажура начнет отбивать запросы (throttling). Это значит, что любое взаимодействие с внешними системами должно это учитывать. К сожалению, это легче сказать, чем сделать, поскольку современные библиотеки для распределенного взаимодействия слоены до нельзя и с точки зрения API не вполне очевидно, что именно может пойти не так, какие исключения могут вылететь, и что с ними нужно будет делать.

понедельник, 24 октября 2016 г.

Менторинг и парное программирование

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

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

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

Теперь давайте об этом более подробно.

понедельник, 17 октября 2016 г.

О парном программировании

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

До последнего времени у меня не было личного опыта парного программирования, поэтому мое мнение было сугубо теоретическим. За последние полгода у меня появился какой-то опыт, и именно им и хотелось бы поделиться.

PairProgramming

Итак, начнем с проблем.

четверг, 29 сентября 2016 г.

Hero Pattern

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

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

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

понедельник, 19 сентября 2016 г.

О шаринге знаний и компетенций с коллегами

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

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

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

понедельник, 5 сентября 2016 г.

Инкапсуляция и сокрытие информации

В области проектирования существует два понятия, которые часто используются совместно – инкапсуляция (encapsulation) и сокрытие информации (information hiding).

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

(*) – иногда понятие инкапсуляции применяется в более широком смысле. Например, говорят, что фабрика «инкапсулирует» информацию о конкретном типе создаваемого объекта. В этом контексте инкапсуляция является синонимом сокрытия информации.

(**) – хотя принято считать, что у класса недолжно вообще быть открытых данных, но с практической точки зрения, открытое неизменяемое поле хоть и нарушает инкапсуляцию, обычно не приводит к таким же серьезным проблемам сопровождения, как открытые изменяемые данные.

вторник, 30 августа 2016 г.

Что не так с оператором switch?

В обсуждении одного из моих ответов на ru.stackoverflow в G+ был поднят вопрос по поводу того, является ли оператор switch design или code smell-ом?

Тут нужно быстро вспомнить, откуда ноги вообще растут (ИМХО). В наших с вами разных языках программирования существует много разных способов решения одной и той же проблемы. Например, когда у нас есть определенная задача (нарисовать фигуру?!) и несколько разновидностей входных данных (круг, квадрат, прямоугольник?), то решить ее можно разными способами. Можно взять впихнуть тип в структурку и в методе draw перебрать все возможные варианты.

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

вторник, 23 августа 2016 г.

Принцип YAGNI

На ru.stackoverflow.com недавно был задан вопрос, который, ИМХО, стоит вашего внимания: Нарушает ли OCP и DIP (из SOLID) принцип YAGNI?. Ниже представлен немного более развернутая версия моего ответа.

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

Следование одному принципу может привести к нарушению другого. Так, например, любое наследование *можно* рассматривать как нарушение SPR, поскольку теперь за одну ответственность (рисование фигур) отвечает целая группа классов. Принципы DIP и OCP, которые часто требуют наследования, могут привести к появлению дополнительных «швов», т.е. интерфейсов/базовых классов в системе, что, опять-таки, приведет к нарушению SRP и/или ISP.

среда, 29 июня 2016 г.

О сути исключений

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

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

И именно о семантике исключений сегодня и пойдет речь.

вторник, 21 июня 2016 г.

Должен ли менеджер кодить?

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

clip_image002

Я уже не раз встречаю мнение о том, что не зависимо от уровня, менеджер в софтверной компании должен оставаться hands on и продолжать кодить (*). Мысль эта несколько необычна, поскольку первое, чему приходится научиться любому начинающему менеджеру в области софтостроения – это как раз-таки, отказаться от этого самого кодирования.

(*) Об этом не раз писал Joe Duffy в постах и твитах, а также Michael Lopp в своей книге “Managing Humans”.

Как и в многих других вещах, ответ на вопрос «Кодить или нет?» несколько сложнее, чем может показаться и не подразумевает бинарной логики в ответе – «да» или «нет».

понедельник, 30 мая 2016 г.

О сомнительных советах об эффективности

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

Но самая главная проблема появляется тогда, когда в совете об эффективности той или иной фичи не объясняется ситуация, в которой этот совет является применимым. Вроде бы, цитату Кнута/Хоара о преждевременной оптимизации знают все, но продолжают давать советы об эффективности в ультимативной форме.

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

среда, 18 мая 2016 г.

О рецензировании кода

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

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

Но если эта практика и применяется, то совсем не факт, что она приносит столько пользы, сколько об этом твердят в мудрых книгах адепты гибкости. Итак, в чем же может быть проблема?

clip_image002

понедельник, 9 мая 2016 г.

TDD: Test-Driven vs. Type-Driven development

Боб «не люблю статическую типизацию» Мартин произвел отменный вброс в своем недавнем посте “Type Wars”, в котором он выразил мысль, что наличие TDD и 100%-е покрытие тестами вполне заменяет статическую типизацию:

“You don't need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What's more, the benefits of that achievement are enormous.”

После чего поднялась небольшая волна в этих ваших тырнетах, в результате даже Марк “Я-то точно знаю TDD” Сииман был обвинен в ереси и непонимании принципов, заложенных в TDD.

среда, 4 мая 2016 г.

Параметризованные юнит-тесты в xUnit

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

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

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

вторник, 26 апреля 2016 г.

Что мне не нравится в Xunit

xUnit - это самый популярный нынче тестовый фреймворк, который сейчас активно используется во многих open source проектах типа Roslyn, CoreFx и сотнях проектах поменьше. Я всю свою сознательную жизнь использовал NUnit, но сейчас, иногда по работе, иногда просто при работе с чужеродными кодовыми базами, мне приходится иметь дело с xUnit.

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

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

Итак, начнем.

понедельник, 18 апреля 2016 г.

Размышления о TDD

В наших с вами тырнетах снова образовался всплеск активности по поводу TDD, о его здоровье и жизненных показателях. Началось все с поста Ian Sommerville “Giving up on test-first development”, а продолжилось постом Боба «я все знаю о дизайне» Мартине “Giving up on TDD” и еще несколькими постами.

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

Результат vs. Процесс

Когда речь заходит о TDD (Test-Driven Development), то возникает впечатление, что речь идет о каком-то тайном знании. «Знающие» индивидуумы рассказывают о своих успехах с хитрым выражением лица и некоторым снисхождением к тем, кто еще не осознал всей прелести этой аббревиатуры. При этом, когда их просят рассказать о выгодах сего процесса, они начинают бормотать о пользе тестов, важности хорошего дизайна, легкости рефакторинга и гибкости получаемых систем. Иногда, в качестве аргументом могут встречаться фразы о самодокументируемом коде, наличиях «встроенной» в тесты спецификации и высоком покрытии, как о важном артефакте любой вменяемой кодовой базы. А если вы начнете детально обсуждать модульные тесты, то вас перебьют и скажут, что TDD – это вообще-то про дизайн (т.е. про проектирование), а не про тестирование.

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

вторник, 12 апреля 2016 г.

ErrorProne.NET. Часть 4. Реализуем Extract Method

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

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

clip_image002

Каждый фиксер должен указать, какую проблему он должен решать. Для этого нужно унаследоваться от класса CodeFixProvider и переопределить свойство FixableDiagnosticIds:

пятница, 11 марта 2016 г.

ErrorProne.NET. Часть 3

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

В языке C# есть довольно много возможностей, которые выворачиваются в довольно сложный IL-код и приводят к поведению, не всегда очевидному для пользователей/читателей кода. Хорошим примером подобного рода является ограничение new() в обобщениях, использование которой приводит к использованию отражения (reflection) и созданию новых экземпляров объектов с помощью Activator.CreateInstance, что меняет «профиль» исключений и негативно сказывается на производительности.

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

вторник, 8 марта 2016 г.

ErrorProne.NET. Часть 2

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

ErrorProne.NET унаследовал многие возможности из моего другого проекта – ExceptionAnalyzer, но в несколько измененном виде. Вот какие правила он содержит:

  • ERP021 – Incorrect exception propagation: «неправильный» проброс исключения с помощью throw ex; вместо throw;
  • ERP022 – Unobserved exception in generic exception handler: когда блок catch, который перехватывает все исключения возвращает управления без попытки «наблюдения» перехваченного исключения.
  • ERP023 – Suspicious exception handling: only Message property was observed: когда в обобщенном блоке catch идет обращение лишь к свойству ex.Message исключения.

Теперь обо всех этих исключениях более подробно.

четверг, 25 февраля 2016 г.

ErrorProne.NET. Часть 1

У меня уже давно чесались руки сделать анализатор, который поможет отлавливать разные ошибки, в той или иной степени, специфичные для платформы .NET. Многие подобные ошибки уже прекрасно отлавливает R#, но ведь всегда хочется чего-то своего. К тому же, анализаторы Розлина бесшовно интегрируются в билд процесс, могут использоваться по ночам (*), да и могут содержать рулы, специфичные для вашего продукта.

Итак, взяв за основу идеи из R# и из аналогичной библиотеки для Java от гугла под названием Error Prone, я взялся за работу. Ниже представлен первая часть результатов моей работы.

Вызов чистых методов

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

воскресенье, 7 февраля 2016 г.

О человеческом оптимизме

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

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

--------

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

среда, 3 февраля 2016 г.

Асинхронные постусловия в библиотеке Code Contracts

На прошлой неделе я выкатил релиз-кандидат новой версии библиотеки Code Contracts (v.1.10-rc1). В этом релизе было поправлено довольно много, а главной «новой» возможностью стала вменяемая реализация асинхронных постусловий.

Для начала стоит напомнить, что такое постусловия вообще, и асинхронные постусловия в частности.

Постусловие метода – это некоторое условие, которое должно быть истинным при успешном завершении метода. Например, постусловие может гарантировать, что возвращаемое значение не будет равно null, что перед завершением метода Start, состояние будет равняться определенному значению (например, Starting) и т.п.

понедельник, 11 января 2016 г.

О книге Барбары Оакли «Думай как математик»

DISCLAIMER: если вы проходили курс Learning How To Learn на Coursera, то в книге не будет толком ничего нового. С другой стороны, если вы курс таки проходили, то знаете, что space repetition – это весьма полезная техника, а значит книга может быть полезной даже в этом случае.

image

Любопытно, что мы, программисты, как и представители многих других профессий, тратим существенную часть нашего времени на обучение. Мы учим всяческие новые технологии, новые концепции, паттерны и парадигмы, или просто подключаемся к новому проекту на десятом году его жизни. Это значит, мы тратим много времени на обучение. Поскольку мы учимся большую часть нашей жизни, мы должны быть весьма хороши в этом. Правда? Ну, как вам сказать, чтобы не обидеть…

среда, 6 января 2016 г.

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

Недоеденный салат оливье, ошметки мандарин по всему дому и елка, намекают на Новый Год, а значит пришло время подвести итоги года предыдущегоJ

Прошлый год оказался довольно насыщенным на события: я дописал и опубликовал книгу, сменил команду, начал активно пилить Code Contracts и у меня родился сын! Интересно? Еще бы! Подробности под катом.