В одной конторе соискателю на позицию Senior C# developer выдали тестовое задание: отсортировать файл со строками определенного формата.

Требования такие:

* Формат строки: число, точка, пробел, далее любые символы до конца строки.

* Порядок сортировки — сначала сортируем текстовой части строки, потом по числу если текстовые части совпадают.

* Кодировка — UTF-8.

* Размер файла — 100гб - гарантированно больше объема ОП.

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

Как и многие другие программисты, узнав о таком тестовом задании, я возмутился. Внешнюю сортировку слиянием практически всех проходили в ВУЗе, но практически никто никогда не писал её. Задача очень непрактическая и непонятно какие навыки проверяет. Так мне казалось.

Эта задача вызвала бурные обсуждения о способах её решения. Многие программисты, причисляющие себя к рангу senior, предложили использовать базы данных, ибо не барское это дело - вручную писать алгоритмы сортировки. Некоторые даже попытались сделать решение на Apache Spark. Однако никто до конца задачу не решил, ибо мало кому удалось отсортировать в нужном порядке даже 10ГБ файл менее чем за 15 минут без SSD.

Я подумал, что стоит решить задачу до конца с помощью программирования, и тоже причислить себя к рангу senior developer.

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

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

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

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

Прошлый раз я сказал, что C# не поддерживает двойную диспетчеризацию. Это была наглая ложь! На самом деле C# поддерживает множественную диспетчеризацию. Вы можете выбрать метод на основании типа времен выполнения любого количества аргументов.

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

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

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

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

(Если вы не читали первую статью серии, то обязательно начните с нее)

Распространенная проблема, которую я вижу в объектно-ориентированном проектировании:

* Волшебник — это разновидность игрока.
* Воин — это разновидность игрока.
* У игрока есть оружие.
* Посох — это разновидность оружия.
* Меч — это разновидность оружия.

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

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

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

Чтобы программа не грохалась, а выдавала осмысленное сообщение и давала возможность продолжить работу, надо было добавить проверку.

Это перевод первой части статьи. Статья была написана в 2008 году. Спустя 10 лет почти не потеряла актуальности.

Детерминированное освобождение ресурсов — необходимость

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

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

Угадайте какой рекомендации не следует рантайм .NET, и как следствие все языки на его базе?

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

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

По сути, это «авторитет». Что бы им стать нужно два фактора:
— Уметь быть убедительным, убеждать. Развитая речь и система аргументации, жизненный опыт (есть что рассказать)
— Поддерживать внутри коллектива справедливость, систему понятий ;-)
В итоге получается человек, с которым комфортно, на которого можно положиться, который никогда не паникует и не теряется. К таким людям внутри коллектива остальные тянутся, вот и получается лидер.

Дисклеймер: Под Linq to Database здесь и далее понимаем самые распространенные .NET библиотеки для доступа к реляционным СУБД с использованием Linq запросов. Такие как Linq2SQL, Entity Framework, NHibername, Linq2db и подобные

• 20:1 по времени написания кода
• 25:1 по времени отладки кода
• 10:1 по скорости работы программы
• 5:1 по объему кода

• Нужен установленный Excel на компьютер, чтобы получить данные.
• В полученном документе для названий колонок используется InternalName полей.
• В полученном документе используется “сырой” формат данных, что далеко не всегда подходит.