Когда хорошая идея становится популярной - все начинают пересказывать её "как поняли". В итоге в информационном поле от изначальной идеи остаётся настолько мало, что её перестают воспринимать всерьёз. В этой статье я хочу рассказать о двух таких идеях: Scrum и ООП
Всё началось с подготовки к финалу RuCode – масштабному соревнованию для всех увлечённых алгоритмическим программированием. Погружаясь в разбор заданий прошлых лет, мне кое-что совершенно случайно попало в руки, интересная задача: реализовать шахматы с "туманом войны" в консоли
Идея показалась мне настолько вдохновляющей, что я решил пойти дальше, а что если превратить эту консольную головоломку в настоящую игру с графикой и той самой атмосферой тумана войны, который так знаком игрокам в стратегиях
Идея зацепила сразу, представьте классические шахматы, но с элементом неожиданности. Вы не видите все фигуры противника, а только те клетки, куда могут ступить ваши фигуры. Каждый ход превращается в тактическую загадку, что скрывается в темноте? Где спрятался вражеский ферзь? и т.д.
Так обычная подготовка к соревнованиям превратилась в увлекательный эксперимент, результатом которого стала эта статья и реализация шахмат с туманом войны на Python
Мат рождается в душе. Больше всего его рождается когда сталкиваешься с чем-то похожим на <подставь свой фреймворк>. Инструмент с прекрасными целями и задачами постепенно превращается во все больший и больший кусок г.. в котором приходиться копаться. Ощущаешь себя жужжащей мухой, летающей вокруг по необходимости.
Когда трава была зеленее, когда мы сильно боролись за каждый такт процессора, тратя на это наше время, которое мы тогда не очень ценили, все было в какой-то мере проще.
Если тебе нужна была фича, ты ее делал сам.
Или ты искал уже реализованную фичу, и прикручивал к своему коду.
Больше времени уходило на поиск. Не всегда можно было найти.
Сейчас все поменялось.
Подключение новой фичи чаще всего присоединяет к твоему коду 100500 дополнительных фиговин, которые мало того, что чаще не нужны, но и которые мешают запустить твой код.
Они подключаются по дефолту сами, и ты ищешь как их отключить. Но так как библиотеки постоянно меняются, это не так просто. Сколько раз подключал <подставь свой фреймворк>, ещё не разу не было одинакового кода. Постоянно меняются названия методов, их параметры, типы.
Раньше было просто. Возьмем для примера <подставь свой фреймворк>. Ты подключал и говорил ему, что нужно делать в первом случае, что во втором, что в третьем.
Сейчас же так просто не работает. Все стало сложнее. Ты указываешь доступный всем метод по старинке, но не тут то было. Клиенты получают в ответ фигу. Ты думаешь, что поменялся синтаксис, ищешь новые незадеприкейчаные методы (которых по количеству уже меньше, чем задеприкейчаных), но все равно клиенты получают фигу. Один и тот же код разрешает пользователям работать с одними запросами, но не разрешает с другими. Уверен, что это как-то объясняется. Просто подключается ещё куча бинов по дефолту, с доп параметрами по дефолту, и т.д. Идеология упрощения.
Но то, что прямо игнорируется команда разработчика, это уже перебор.
В парадигме ООП объекты взаимодействуют друг с другом. Первоначальная идея такого взаимодействия, впервые появившаяся в языке Smalltalk, заключалась в том, что объект A отправлял сообщение объекту B. В языках, разработанных позднее, используется вызов методов. В обоих случаях возникает один и тот же вопрос: как объект ссылается на другие объекты, чтобы достичь желаемых результатов?
В этой статье я рассматриваю проблему передачи зависимостей объекту. Я рассмотрю несколько вариантов и проанализирую их преимущества и недостатки.
Введение
Мы часто говорим об алгоритмах как о «сердце» любой сложной системы. В контексте нашей платформы Гриндаты алгоритмы — это не просто код. Представьте, что данные — это деньги или документы клиентов, а алгоритмы — это инструкции и правила, которые позволяют быстро находить, сортировать, обрабатывать и сохранять эти «деньги/документы».
Процесс создания алгоритма для бизнес‑логики всегда начинается с декомпозиции действий. Далее мы переводим эти действия на алгоритмический язык, подбирая оптимальные пути решения. Но чтобы делать это быстро и эффективно, необходима прочная концептуальная база.
Формулы удачного написания алгоритма не существует, поскольку задачи всегда разного толка и сложности. Однако понимание основных парадигм программирования — это первый и главный ключ к написанию оптимально работающих алгоритмов. Наши алгоритмы являются мультипарадигменными, поэтому рассмотрим два основных подхода, лежащих в их основе: ООП и ФП.
Концептуальная основа: ООП (Объектно‑ориентированное программирование)
Концепция ООП лежит в основе структуры и окружения нашей платформы. Понимание ООП необходимо аналитику для:
Доброго времени суток дорогой читатель!
Всё последующее содержание статьи очевидно является некой формой садизма, так что если если вы пришли за чоколадкой golangом, питоном, ванильным чапманом или другими формами сладкой жизни, лучше уходите.
Тема изоляции данных клиентов (мультитенантность) в saas или подобных продуктах исторически считается если не самой, то одной из наиболее сложных и требующих архитектурных извращений, тем в веб-разработке.
Существует несколько разных подходов, от банального tenant_id в каждой таблице базы данных, до физического разделения данных на разные сервера под разных тенантнов.
Компромиссным решением является выделение идентичных по содержимому (таблицам) схем для каждого нового клиента в одной базе данных. Таким образом мы получаем относительную защиту от утечек данных между клиентами с минимальными затратами на аренду новых серверов. Именно этот вариант мы и будем рассматривать.
Именно с публикации этой статьи в 2000 году берет свое начало формирование лондонской школы тестирования, также известной как «мокистская» школа. В ней авторы не только вводят ключевые концепции мок-объектов и эндотестирования, но и закладывают методологический фундамент подхода, принципиально изменившего практику юнит-тестирования — подхода, основанного на явном определении взаимодействий между объектами, замене зависимостей и тестировании поведения системы изнутри.
Команда Go for Devs подготовила перевод статьи о том, как работает сборщик мусора в Go. Автор подробно объясняет семантику алгоритма триколорной маркировки и очистки, механизмы Stop The World, пейсинг и источники задержек. Главное — не бороться со сборщиком, а работать с ним в унисон: устранять лишние выделения и снижать нагрузку на кучу.
В 2003 году Алан Кей, признанный автор термина «объектно-ориентированное программирование», ответил на вопросы исследователя Штефана Рама. В этом письме он раскрывает первоначальный замысел ООП, который значительно отличается от того, чему большинство из нас учат сегодня. Публикуем перевод этого исторического документа.
Достаточно часто в реализации сервисов есть необходимость оперировать денежными единицами, хранить их в БД, обмениваться по API и выполнять конвертацию
Создавайте приложения так, чтобы они могли работать без пользовательского интерфейса или базы данных. Это позволит запускать автоматизированные регрессионные тесты, продолжать работу при недоступности базы данных, а также связывать приложения друг с другом без какого-либо участия пользователя.
Команда Python for Devs подготовила перевод статьи о генераторах множеств в Python. С их помощью можно создавать, преобразовывать и фильтровать множества одной строкой кода. Разбираем примеры, практические приёмы и ошибки, которых стоит избегать.
В теории типов вариантность описывает отношение между двумя обобщёнными типами (дженериками). Например, в каких обстоятельствах родительский тип может быть заменён дочерним, а в каких — нет, и так далее.
На эту тему можно найти множество ресурсов, особенно таких, где всё описано длинно и сложным, формально-архитектурным языком. Мне бы хотелось создать короткую и простую памятку (с небольшими вкраплениями формализмов), к которой можно легко вернуться, если вдруг забудутся детали.
Только что закончил коммент коллеге в комментариях к статье про «Неравную борьбу OS/2 с Windows» и подумал что это достойно отдельного поста. Но оказалось что для поста этот материал слишком велик. Хорошо пусть будет статья.
Надеюсь наш разговор в комментариях достоин более широкого прочтения и возможно больших обменов мнений.
Ниже прямым текстом приводятся мои мысли, цитаты взяты из ответов мне @axe_chitaесли только источник не заявлен явно.
Не все написаное коллегой попало в ниже приведенный текст. Но это объяснимо — это как бы ответы на вопросы коллеги, имеющего сильно отличающееся от действительности представление по предмету дискуссии. Подозреваю, что многие на Хабре имеют подобные представления.
Конечно я не претендую на истину в последней инстанции, но уж больно сильно поразили меня наши с коллегой расхождения.
С тех пор, как «банда четырёх» ещё в 90-е выпустила свою легендарную книгу «Паттерны объектно-ориентированного проектирования», сами «паттерны проектирования» стали краеугольным камнем всевозможных рассуждений о программной архитектуре. Однако, со временем этот термин становится всё более размытым. Сегодня при упоминании паттернов может иметься в виду:
Назначение этого паттерна: та проблема, для решения которой он предназначен Реализация: точная структура класса или код для воплощения этого паттерна
Рассказывая о «паттернах проектирования в Python, о которых следует забыть», мы имеем в виду как раз реализации. В самом деле, эти паттерны решают реальные задачи. Но в Python решение этих задач ничуть не напоминает те варианты, которые предлагаются на C++ или Java.
Держа в уме эту идею, делаем простой вывод:
Мишка учится лазать по деревьям, чтобы добраться до мёда. Но орлы никуда не лазают, они летают.
Недавно я прочёл книгу «Паттерны разработки на Python TDD, DDD и событийно-ориентированная архитектура». Основной акцент в ней сделан на том, как именно нужно структурировать программы, чтобы они по мере роста оставались простыми и удобными в поддержке. Это моя любимая тема из области программирования, поэтому, конечно же, книга мне понравилась. Пожалуй, я не возьмусь использовать именно те приёмы, которые авторы рекомендуют в книге — но они обсуждают классные идеи, напомнившие мне о задачах, встречавшихся в моей практике на предыдущих работах. Кроме того, отмечу, что английская версия книги есть в свободном доступе онлайн, так какие вообще вопросы?
В книге рассматривается предметно-ориентированное проектирование и событийно-ориентированная архитектура (в основу которой удобно закладывать микросервисы, но это не обязательно). В этом посте я немного раскрою наиболее понравившиеся мне идеи из книги, но, прежде, чем переходить к этому, хочу артикулировать некоторые детали:
Попробуйте поискать в Интернете «Паттерны проектирования на Python» — и получите целую простыню туториалов, демонстрирующих, как в точности воспроизвести на Python паттерны проектирования из книги «Банды четырёх». Там же будут диаграммы классов, иерархии фабрик и столько шаблонного кода, что выхлопа хватит, чтобы отопить маленькую деревню. Так вам внушают, будто вы пишете «серьёзный» код. Умно. Профессионал ьно. Готово для корпоративного использования.
Но вот в чём проблема: большинство из этих паттернов решают проблемы, которые в Python просто отсутствуют. Паттерны разрабатывались для таких языков как Java и C++, где для выполнения самых базовых вещей требуется настоящая эквилибристика — нет ни функций первого класса, ни динамической типизации, ни модулей в качестве пространств имён. Разумеется, вам потребуется Фабрика или Синглтон, если без них в вашем языке просто не с чем работать.
Слепо копировать эти паттерны в Python — не признак большого ума. Из-за них ваш код сложнее читать, тестировать, а также объяснять очередному бедняге, которому этот код придётся поддерживать. Возможно, через три месяца этим беднягой станете вы..
Мне тут попалась идеальная статья про DI в который нашелся очень интересный пример для разбора. Есть фундаментальные основы, которые почему то никто не хочет сформулировать, а начинающим разработчикам, которые впервые сталкиваются с концепцией DI, в первую очередь надо бы рассказать эти фундаментальные основы, но почему то нет желающих это сделать и у меня даже есть предположения, почему это не получается, я попробую их как-то выразить в том числе.
Я знаю что искать ошибки в статьях начинающих на Хабре это плохой тон, и я вряд ли выйду в плюс с такой статьей, но как говорится: Платон мне друг, но истина дороже.
В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.
Если Вы сталкивались с многопоточными методами в классах и так же, как и мы, ужасались получившемуся раздутому коду ... вы по адресу. Пару ночей, жонглирование type_traits и мы готовы представить Вашему вниманию обёртку для подобных ситуаций!
Библиотека функций к Script-fu
Вы любите рефакторинг? Ну вот и я приблизительно так же. Основное правило хорошего программиста, такое: «Работает, НЕ ТРОГАЙ!». Но иногда, в редкие минуты помутнения/вдохновения, возникает желание, или я бы даже сказал зуд, в одном месте, и мы садимся за рабочее место, берём в руки клавиатуру и начинаем «творить шедевры» с чистого листа.
Системы подпрограмм для языка функциональной геометрии я писал три раза: сначала в функциональном стиле(и в этом то месте и возник пресловутый «свитчинг по типам», потом в стиле примитивных объектов, который не имел наследования, но я придумав хак с шаблонным использованием кода, значительно сократил его дублирование и теперь, когда я разработал развитую ООП систему, во многом повторяющую функциональность CLOS. И это событие прекрасная причина, чтобы переработать старый ООП код, в новой ОО системе. Чем мы с вами здесь и займёмся.
