Как вообще пришёл к этой книге

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

Другое наблюдение - внутрикорпоративные подходы к реализации изобретений. Знаю о пяти с половиной системах, которые выполняют одну и ту же функцию.

  1. Одну из них очень хотят проектировать, аж баблом поливают.
  2. Другую переписывают (2 мес) вместо найма человека с нужным стеком на поддержку (и развитие? С развитием сложно, детали понимает один человек). Но эксплуатируется и работает.
  3. Третья вроде работает и часть людей ей пользуется, но 1 и 2 её мало, а менять её не хотят.
  4. Половинка - это реализованная инфраструктура для четвёртой системы в пятой системе для выполнения ровно той же функции, которая в проде, но которую так и не начали эксплуатировать.
  5. Пока писал вспомнил про шестую, которую оунер идеи первой упомянутой системы закидал говном и не дал добро на ресурсы для улучшения (сомнительного, к слову) взаимодействия 5 и 6 систем с всё той же функцией.

Велосипеды

Существует точка зрения, согласно которой преобладание «мелочи» — явление нормальное и положительное: «Как в математике бесконечно малые приращения способны образовывать конечные и вполне ощутимые суммы, так незначительные, казалось бы, но организованные и целенаправленные усовершенствования, зафиксированные юридической формулой, создают техническую базу того, что принято называть научно-технической революцией»

Под “мелочами” автор имеет в виду изобретения первого уровня - по факту не открытия, которые имеет смысл патентовать, а простые конструкторские решения.

Несколько улыбает схожесть с текущим состоянием опенсорса с публичными репозиторями ПО на любой вкус и цвет, вплоть до is-even и is-odd.

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

Массовая инъекция таких изобретений призвана искусственно продлить рост и жизнь устаревших по своим принципам систем.

Не менее забавно читать про легаси, которое ещё не про ПО, а про реальный физический мир и двигатели внутреннего сгорания, например.

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

Сова, глобус, принципы устранения технических противоречий и разработка ПО

Подумываю провести аналогии главы “40 основных приёмов по устранению технических противоречий” из книги Найти Идею с архитектурными рефакторингами в разработке ПО. Будет много сов, много глобусов. Стоит оно того, чтобы как минимум похихикать в процессе, а как максимум - поржать с того что все эти ваши рефакторинги придумали 40 лет назад. Заодно систематизирую кашу в голове.

1. Принцип дробления.

Разбейте монолитное приложение на микросервисы.

2. Принцип вынесения.

Отделите от объекта “мешающую” часть в облако. Например, СУБД.

3. Принцип местного качества.

Перейти от однородной структуры объекта к неоднородной

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

Каждая часть объекта должна находиться в условиях наиболее благоприятных для неё.

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

4. Принцип асимметрии.

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

5. Принцип объединения.

Объединить во времени однородные или смежные операции.

Используйте асинхронный батч-процессинг вместо множества зависимых схожих запросов.

6. Принцип универсальности.

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

Заставьте вашего сеньора питониста быть ещё и тимлидом, а то чего он расселся и ничего не делает.

7. Принцип матрёшки.

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

Приложение находится в контейнере, контейнер находится в виртуальной машине, которая находится в железной машине, которая находится в стойке, которая находится в датацентре, который находится в регионе…

20. Принцип непрерывности полезного действия.

а. Вести работу непрерывно (все части объекта должны все время работать с полной нагрузкой).

б. Устранить холостые и промежуточные ходы.

У меня на работе есть сервис, у которого есть модуль периодических задач. Была раньше проблема с смертью процесса от OOMKiller, в ходе которой никак задачу как сбойнувшую не пометишь. Решил это инкрементом счётчика попыток при взятии в работу, но и проверку того, что счётчик переполнен пришлось делать ещё до этого. При удачном выполнении, счётчик разумеется сбрасывается. Он же используется для вычисления экспоненциального таймаута перед повторной попыткой, так как если какая-то из внешних зависимостей засбоила на полчаса, сделать 5-10 попыток раз в 2 минуты… ну, мало смысла имеет.

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

Устранил холостые ходы и сижу довольный.

25. Принцип самообслуживания.

Очень нравится концепция health-check, которые могут исправлять найденные проблемы, а не только говорить “мне херово”. В ту же степь изначально спроектированные ограничения в сроке жизни данных - системы, которые не разрастаются, а агрегируют (при этом способны извлекать пользу из этих агрегатов), а затем и удаляют архивные данные и которые не надо обслуживать руками – офигенные.

26. Принцип копирования.

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

Буквально принцип CQRS, разделение читающей и пишущей нагрузки. Читать можно с множества дешёвых копий с небольшой приемлемой задержкой лага репликации, разгружая от читающей нагрузки мастер-реплику. Туда же вынос аналитики в отдельные BI системы, что даёт возможность не хранить архивы в рабочей базе.

34. Принцип отброса и регенерация частей.

а. Выполнившая свое назначение или ставшая ненужной часть объекта должна быть отброшена (растворена, ис- парена и т. п.) или видоизменена непосредственно в ходе работы.

б. Расходуемые части объекта должны быть восстановлены непосредственно в ходе работы.

Пункт “а” напоминает soft delete совсещённый с отложенным hard delete в базах, позволяющий рабочей БД не распухать со временем и не требовать дополнительного обслживания или сложных технических решений по работе с большими объёмами данных. Куда проще с такими данными просто не работать.

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

Аналогично действует и “прореживание” бэкапов через нечто похожее на цепочку кольцевых буферов, реализованное мной - https://github.com/strizhechenko/backup_scheme

Системный подход к творрчеству

Рисуют примитив для подхода к изобретательским задачам в виде схемы с девятью клетками.

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

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

ТОЛЬКО И ИЩУТ ПРИЧИНЫ ЛИШЬ БЫ ПРЯМ ЗДЕСЬ И СЕЙЧАС САМИМ НИЧЕГО НЕ ДЕЛАТЬ ПРЯМО ТАКИ АЙТИШНИКИ.

Динамизм

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

  • То, что раньше требовало перезапуска, начинает уметь перечитывать конфиги на ходу.
  • Сервера переезжают с железок в виртуалки, потом контейнеры, а дальше и вовсе становятся эфемерными.
  • То что было соединено жёстким соединением, получает возможность двигаться (всевозможные ddns/discovery вместо зашитых IP-адресов).