Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

Data Access Layer – одна из наиболее больных тем.
Написание хорошего слоя доступа к данным – это не тривиальная задача. Примеров реализации невероятно много, но адекватных среди них единицы.
Можно ли считать реализацию шаблона Repository — DAL?
Вот что предлагают MS msdn.microsoft.com/en-us/library/ff649690.aspx

А вот и местные работы habrahabr.ru/post/52173
Варианты довольно нормальные.
Но когда я вижу

«Репозиторий – это фасад для доступа к базе данных.»

…

Всегда ли нужно использовать то, что предлагают?

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

Глава 12 Symbol Table

Место для хранения во время синтаксического анализа всех
идентифицируемых объектов для разрешения ссылок.

Понятно? Конечно понятно, к описанию претензий нет.

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

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

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

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

В очередной раз упражняясь в практике TDD на Java я создал небольшой учебный проект, в котором показал, что если тесты проходят, то это еще не значит, что код выполняется правильно. На самом деле, разработка модульных тестов, в которых учитываются различные варианты входных данных это кропотливая работа. Для решения возникшей проблемы нашел для себя библиотеку junit-quickcheck, опытом использования которой спешу поделиться.

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

Интервью с Дмитрием Бородиным, одним из трёх основателей компании Topface. О том как зарождался проект и каким по счету проектом он был. Об архитектуре и разработке крупного масштабируемого проекта и мастер-классе на Devconf. На какие два типа делятся программисты.

Мастер-класс Дмитрия на DevConf 2015 пройдет 20 июня

Балдология, как оказалось (вы ведь слышали о существовании такой науки, правда?), имеет на Хабре отражение в виде нескольких статей, вот они:

«Алгоритм быстрого поиска слов в игре балда»
«Алгоритм и тактика поиска слов в игре Балда»
«Как я гонял Балду на Visual Basic for Applications для MS Access»

Эта статья — продолжение моей предыдущей, последней в списке. Отправными точками для написания были присланные мне в комментариях ссылки на способ хранения словаря в виде дерева (статья в Википедии с описанием алгоритма Trie), а также упоминание коллеги chibiryaev о его собственной реализации поиска, которая тратит на нахождение слова в словаре из 110 000 элементов всего 16 миллисекунд!

Собственно, задача №1 – увеличение скорости поиска слов в текстовом массиве.
Начнем с реализации алгоритма Trie. Для этого нам необходимо поместить весь словарь существительных (43 303 слова) в структуру связанного дерева. Visual Basic не поддерживает переменных-ссылок, подобно C++ или C# (не говоря уже о Pascal), но в этом качестве вполне подойдут индексы массива.

Чего только ни услышишь от апологетов тех же Java или C# про разработку на C/C++! Якобы этот язык устарел и на нем никто не пишет. Вот только когда требуется создать no latency или low latency сервис или нужно сэкономить память и время выполнения узкого места обработки больших объемов данных, то тут же прибегают за помощью к «архаичным» разработчикам на C/C++. Просто потому, что эти ребята умеют вручную управлять памятью и прекрасно представляют, что за начинка у той или иной высокоуровневой операции. Сегодня наша задача — стать на шаг ближе к этим ребятам.

Каждый ищет в языках программирования что-то своё: кому-то важна функциональная сторона, кому-то богатство библиотек, а другой сразу обратит внимание на длину ключевых слов. В данной статье я хотел бы рассказать, что особенно важно для меня в Rust — его очевидность. Не в том, что его легко изучить с нуля, а в том, как легко исследовать поведение кода, глядя на его фрагменты. Я перечислю особенности языка, позволяющие точно определить, что делает та или иная функция, вырванная из контекста.

Особенно отмечу, что не пытаюсь полностью описать язык, а только одну его сторону. Это мой личный взгляд на философию Rust, не обязательно совпадающий с официальной позицией разработчиков! Кроме того, Rust не будет очевиден пришельцу из других языков: кривая обучение довольно резкая, и не раз компилятор заставит вас мысленно сказать «wtf» на пути к просветлению.

До того, как я пришел в HeadHunter, я не знал, что такое code review. Я знал, что такое code approval — так было в одной американской компании, где я начинал свою карьеру, и где весь код в проекте проходил перед мудрыми глазами профессора Фортрана за столиком в глубине офиса. Он с отеческой улыбкой смотрел на мои первые шаги в разработке и говорил: «Вот тут поправь, пожалуйста, и можешь выпускать».

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

Шаблоны можно назвать самым главным отличием и основным преимуществом языка C++. Возможность создать шаблон алгоритма для различных типов без копирования кода и со строгой проверкой типов — это лишь один из аспектов использования шаблонов. Код специализаций шаблона строится на этапе компиляции, а это значит, что поведением создаваемых типов и функций можно управлять. Как тут удержаться от возможности попрограммировать компилируемые классы?

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

Начало

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

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

Думаю все из нас, кто учился на ИТ-специальностях, в университете изучали конечные автоматы. Для тех, кто не в курсе, это абстрактный автомат способный находиться в конечном количестве состояний, переход из одного состояния в другое происходит при выполнение некоторых условий. Штука интересная, но не совсем понятно когда и как это можно применить для решения реальных задач. О том, как я пришел к решению возникшей задачи на основе конечного автомата, а также о том, как реализовал его на bash, я бы и хотел рассказать. А в качестве бонуса опишу как сохранять его состояние для возможности восстановить работу с прерванной точки.

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

Говоря о тексте, большинство программистов C++ думают о массивах кодов символов и кодировке, которой эти коды соответствуют. Наиболее опытные разработчики вообще не мыслят понятие текста без указания кодировки, наименее опытные просто считают массив байтов с кодами символов данностью и интерпретируют в понятиях кодировки операционной системы. Фундаментальная разница между этими двумя подходами не только в опыте разработчика, но и в том, что не думать о кодировке намного проще. Пора рассмотреть способ, как не заботиться о хранении кодировки, перекодировке текста, получать свободный доступ к символам и при этом видеть безошибочное представление текста вне зависимости от того, кто и где смотрит на строку текста: в Китае ли, в США или на острове Мадагаскар.

Создавая объект за объектом, мы часто не обращаем внимания на такую «мелочь», как динамическое выделение памяти. Наравне с копированием и сериализацией, выделение памяти из кучи через new постепенно сводит на нет преимущества C++ в скорости. Чем интенсивнее мы пользуемся заветным new, тем сложнее становится приложению, поскольку память кончается, фрагментируется и всячески стремится утекать. Эта участь уже постигла удобные, но неявно опасные для производительности контейнеры STL: vector, string, deque, map. Особенно обидно терять скорость на выделении небольших объектов в больших количествах. Но есть способ обработать размещение памяти таких объектов на стеке, при этом скрывая детали реализации в специальный класс данных. В этом нам поможет механизм размещающего new — непревзойденный способ оптимизации приложения, полного частых и мелких выделений памяти из кучи.

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

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

(Да, я понимаю всю иронию написания целой статьи по теме того, о чём призываю не писать других вообще. Но, как минимум, у меня будет ссылка, которую я смогу давать интересующимся, когда меня будут спрашивать, почему я не одобряю обсуждение САР теоремы. Также, я хочу извиниться, если статья вам покажется слишком напыщенной, но эта напыщенность опирается на множество ссылок.)

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

Когда результат SQL-запроса влечет бесконечные приведения типов ко всевозможным вариантам типов полей. Когда код заполнен малопонятной логикой с гигантским перебором перегрузок по типам boost::variant. Когда не знаешь, как принять аргумент произвольного типа по RPC-протоколу. Тогда требуется механизм эмуляции динамической типизации в C++. Расширяемый и удобный, создающий понятный API. Такой, что не требует предопределенного списка типов и не заставляет работать с указателями на базовый класс. Такой механизм есть — нам поможет двойная диспетчеризация!

Некоторое время назад, листая просторы хабра, я наткнулся на вакансию «Python Backend Разработчик». В ней больше всего меня подкупило расположение офиса — он был рядом с домом, и я написал отклик. Ответ пришел быстро с вопросом о том, не готов ли я выполнить тестовое задание. Я ответил, что подумаю, если мне его пришлют. Письма с заданием не было недели две.

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