Страницы

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

Блогу 5 лет

clip_image002

Да, все верно, первый пост был опубликован ровно 5 лет назад, 2 декабря 2008 года и назывался “LINQ to Objects. VS2008 SP1 Bug” и был посвящен тому, что в VS2008 следующий код:

UPDATE (заменил Select на Cast), спасибо Eugene Ivanchenko:

var bytes = Enumerable.Range(1, 5).Cast<byte>().ToList();

работал нормально, а в VS2008 SP1 падал с ошибкой. Это теперь мы знаем, что так и должно быть и распаковка типа с конвертацией всегда завершается с ошибкой, но тогда это поведение казалось ошибкой.

С тех пор опубликовано две сотни постов и, что самое главное, мне это продолжает нравитьсяJ

Зачем мне это?

Наверняка многие читатели слышали популярное нынче слово Time Management. А многие, скорее всего, даже используют некоторые методики эффективного управления временем.

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

clip_image004

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

Так вот, основная сложность саморазвития заключается в том, что этот тип дел относится ко второму квадранту: это дело важное, но не срочное.

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

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

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

На замечательном тренинге, который вел мой коллега Сергей Новик, мы играли в игру, в которой нам нужно было составить план саморазвития. Он был произвольным и достаточно неформальным, но основная его идея была в том, чтобы каждый прикинул основные активности, которые он будет выполнять для собственного развития с числовыми показателями: прочитать N книг в год; перевести M статей в месяц; опубликовать K постов в квартал и т.д.

Не важно, какие числовые показатели вы выберете и что именно для вас является наиболее оптимальным способом обучения. Важно, чтобы у вас повысилось это самое чувство важности самообучения прямо сейчас. Для меня лично важным мотиватором служит ведение этого блога, для другого это может быть участие в pet- или open source проекте, для кого-то – чтение книг или статей. Важно, чтобы вы нашли стимулы, которые максимально подходят именно вам.

О чем я собираюсь писать в дальнейшем?

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

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

  • паттерны в современных .NET приложениях;
  • юнит тестирование: Microsoft Fakes + Verification Fakes
  • асинхронное и параллельное программирование
  • дизайн вообще и DDD, в частности
  • C#/.NET (в частности, есть мысли о небольшом цикле об исключениях)
  • философия программирования: ФП vs ООП и всякое другое.

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

Happy blogging-а всемJ

3 комментария:

  1. Я как раз хотел задать вам вопрос, а тут такой пост с призывом сделать это :)
    Тема DDD очень интересна, но к сожалению слабо освещена в контексте распределенных систем и/или систем с серьезными требованиями к производительности.
    Ради ускорения работы приложения приходится "утончать" логику доменных объектов, либо дублировать ее - делать "обычный" вариант и быстрый, для работы в режиме batch-обработки данных.
    Выскажите пожалуйста свое мнение о таких ситуациях

    ОтветитьУдалить
    Ответы
    1. Очень интересный вопрос.
      Все дело в том, что под "системами с серьезными требованиями к производительности" понимаются разными людьми разные вещи. Для кого-то 10 запросов в секунды - это уже высокая производительность, а для кого-то 1000 запросов в секунду - это детский лепет.
      Но в любом случае, я обратил внимание, что именно бизнес-правила и бизнес-логика практически не когда не является узким местом в плане прозиводительности: обычно все упирается в данные, ввод-вывод, многопоточную обработку или еще что-то подобное. Именно поэтому можно смело начинать работать над полноценной доменной моделью и лишь после профилирования думать о переносе логики в хранимки или думать об "утоньшении" бизнес-слоя.

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

      Удалить
  2. Еще один тонкий момент с DDD - работа в распределенных приложениях. Допустим у нас есть WPF клиент, коммуницирующий с сервером через WCF. Распространенной практикой здесь является отправка клиенту DTO-шек, что приводит к тому, что клиент начинает дублировать логику домена, в частности логику валидации.
    Решением тут является вынесение такой логики в отдельные сервисные классы, что приводит к уточшению доменных классов со всеми вытекающими (анимичная модель, transaction script), либо работа с доменными классами на клиенте. Минусы второго подхода в том, что нужно либо писать логику сериализации из/в доменные объекты, либо использовать их в качестве интерфейсов между сервером и клиентом (для работы с DataContractSerializer-ом).
    Что думаете на этот счет?

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

    ОтветитьУдалить