Напишите пост, где дайте три примера ваших попыток преодолеть далёкое понятийное расстояние
Пример 1
Последнее время часто режет слух употребление технических понятий тимлидом. После того, как он перешёл из позиции разработчика в менеджерскую позицию (и код писать перестал) понятийное расстояние между нами скорее всего будет увеличиваться. Есть неписанное правило хорошего тона: если я как разработчик не очень хорошо знаю тему, я не бросаюсь заявлениями по ней. Особенно это касается штук, который сложно проверить руками. Например, того, как внутри устроена виртуальная машина Эрланга, на которой выполняется наш Elixir код. Фантазировать себе можно что угодно. Но надо идти и читать описания того, как там устроено. И потом складывать у себя в голове как это устройство влияет на то, что мы тут пытаемся запрограммировать. Похожая история с соседскими экспертными знаниями, например в области devops.
Очередной диалог на созвоне. Который начинается с общих фраз, “как хорошо, что мы идём итерационно”. А потом вдруг вплетается “хорошо, что у нас канареечные релизы”. Это отсылка к технологии раскатки изменений приложения Canary Release, которая снижает риски выкатки новой версии приложения. Новой значит возможно нестабильной. И можно выкатить эту версию на небольшой процент пользователей, убедиться, что всё хорошо. И тогда докатить на всех.
Нюанс в том, что у нас такого механизма на данный момент нет. Он не реализован. Получается, что человек не понимает о чём он говорит. Через попытки уточнить, что имелось в виду. Мы пришли к тому, что он говорил про то, что мы не удаляем сразу старую версию кода. А вставляем рядом новую. Например, у нас есть кусок кода, который делает расчёт выплат по организации. Он работал не очень быстро. Мы берём и делаем папку V2, а старый код перекладываем в V1. И через переменные окружения даём возможность выбрать какой версией пользоваться. Это тоже снижает риски. Потому что можно сделать замер на версии 1, потом переключиться - сделать замер на версии 2. Если версия 2 работает правильно и при этом работает быстрее, то окей можно переходить на версию 2. При этом всё-таки такие замеры не делаются на продакшен серверах, т.е. на реальных пользователях. Т.е. вот эта реализация скорее может отсылать к двум понятиям: сохранение обратной совместимости и feature flags. Feature flags это у нас есть галочка, по которой мы можем включить новый функционал. И выключить соотвественно. Это тоже не совсем переключение версий из моего примера, но это на один шаг поняйтиного расстояния отодвинуто. А канареечные релизы где-то на другой дороге.
Пример 2
Конкурентность vs параллельность (concurrency vs parallelism)
Делаю задачу. Виртуальная машина эрланга (Erlang VM) поддерживает параллельное выполнение из коробки. Т.е. то, что у нас процессоры имеют больше одного ядра. А можно загрузить работой каждое ядро. И код мы хотим выполнять (там где важна производительность/скорость) в несколько потоков. Внутри вирутальной машины реализован механизм планировщиков/schedulers. Планировщик подаёт работу на ядро. Количество планировщиков ограничено количеством логических ядер процессора. И внутри VM можно спросить: сколько всего планировщиков (System.shedulers) и сколько их них доступно на данный момент (System.schedulers_online). И вот мы наконец-то дошли до места. Где я у себя в коде, когда хочу какую-то работу запустить выполняться воспользовавшись всеми ядрами делаю вот такую штуку:
Task.async_stream(1…20, fn phone_number → send_message(phone_number) end) |> Stream.run()
А когда стала сильно умная, но беру и дописываю параметр max_concurrency
Task.async_stream(1…20, fn phone_number → send_message(phone_number) end, max_concurrency: System.schedulers_online() * 2) |> Stream.run()
Вопрос к коллеге был про “умножить на два”. Откуда оно взялось, из каких соображений. Допустим у меня 8 ядер, а мы пишем запусти мне в 8*2 потоков работу. Что это значит, что мы хотим этим выиграть? Тут надо идти разбираться, что параллельность ограничена количеством ядер. Сервер нам может одновременно (параллельно) считать только 8 штук задач/процессов/работ при 8 ядрах. От того, что 100500 напишу в max_concurrency реальность не изменится. Тогда возможно не нужно никаких множителей? Нет. Ведь у нас есть конкурентность.
Конкурентность/concurrency появилась, когда процессор был одноядерный. Это ненастоящая многазадачность, который мы как люди тоже иногда любим страдать. Процессор с одним ядром многозадачность реализует довольно просто: мы ему - давай считай мне 8 задач, он их ставит в очередь и считает каждую по чуть-чуть, потом прерывается и берёт следующую. Виртуальная машина знает сколько у неё реально доступно планировщиков, но если мы попросили 16 задач нам считать одновременно, а ядер 8. То считать будут 8, а сверху всё та же псевдомногозадачность. Договорились до этого понимания с коллегой. А зачем всё-таки накручивать max_concurrency? Чтобы быстрее выполнялась работа. Переключение между процессами внутри эрланга достаточно дешевое (в отличие процессов ОС и в отличие от нашей с вами головы). Но выкручивать на максималку тоже нельзя. Процессы висят в памяти, всё время пока процессор пыхтит и разгребает очередь. Нужно следить за балансом скорость - потребление ресурсов. А то хотели очень быстро, выжрали все ресурсы и приложение упало.
Пример 3
Описания против физического мира
Я где-то уже про эту дорогу из граблей писала. Нам добавили в начало цепочки выполнения задач - системных аналитиков. Системный аналитик пишет описание задачи - что нужно сделать. Спецификацию пишет. Берём пример простой задачи. Есть на бекенде роут/ручка (URL), которая возвращает некоторые данные. У этих данных есть формат, какие поля нужны (название поля: значение). В задаче аналитик пишет: нужно добавить три вот таких поля, а вот эти два старых поля переименовать вот так. Хорошее описание? Отличное! Разработчик берёт такую задачу и делает её за 15 минут, ладно, за полчаса - если тесты поправит или допишет на новые поля. Дальше этот разработчик приходит в наш разработческий чат и просит ревью (посмотреть его код). Любой коллега по такому коду пробежится по диагонали и скажет всё хорошо. Но разработчику не повезло - я пошла делать ревью. И эту ручку я знаю, потому что я её и делала. И знаю для чего мы её делали. Пошла читать задачу на переделку. И стало мне грустно.
В чём проблема? Здесь есть несколько проблем понимания. Человек наверное не знаком с понятием “обратная совместимость”. Если вы изменяете что-то существующее, прошлый интерфейс должен сохраняться. Иначе вы сломаете запросы для тех, кто пользуется интерфейсом. В нашем случае это про переименование полей. Вторая штука - это понятие о связях внутри проекта. Не пишу внутри системы. Хотя они на своём аналитическо-системно-бытовом как будто бы как раз и должны понимать, что если ты код меняешь в одном сервисе на бекенде, то этим кодом пользуется кто-то в других сервисах. А что это значит? Что нужно найти этих людей/сервисы, которые пользуются - выяснить связи. И задачу на изменения протащить по всем командам, которые эта задача затрагивает. А не молча поменять у нас и остальным всё сломать. Написала объснение, отдала лиду системного анализа с просьбой донести до коллег/добавить в чеклист. Надеюсь поможет.