[СММ-2024] Неблизкие понятийные расстояния

Напишите пост, где дайте три примера ваших попыток преодолеть далёкое понятийное расстояние

Пример 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 минут, ладно, за полчаса - если тесты поправит или допишет на новые поля. Дальше этот разработчик приходит в наш разработческий чат и просит ревью (посмотреть его код). Любой коллега по такому коду пробежится по диагонали и скажет всё хорошо. Но разработчику не повезло - я пошла делать ревью. И эту ручку я знаю, потому что я её и делала. И знаю для чего мы её делали. Пошла читать задачу на переделку. И стало мне грустно.

В чём проблема? Здесь есть несколько проблем понимания. Человек наверное не знаком с понятием “обратная совместимость”. Если вы изменяете что-то существующее, прошлый интерфейс должен сохраняться. Иначе вы сломаете запросы для тех, кто пользуется интерфейсом. В нашем случае это про переименование полей. Вторая штука - это понятие о связях внутри проекта. Не пишу внутри системы. Хотя они на своём аналитическо-системно-бытовом как будто бы как раз и должны понимать, что если ты код меняешь в одном сервисе на бекенде, то этим кодом пользуется кто-то в других сервисах. А что это значит? Что нужно найти этих людей/сервисы, которые пользуются - выяснить связи. И задачу на изменения протащить по всем командам, которые эта задача затрагивает. А не молча поменять у нас и остальным всё сломать. Написала объснение, отдала лиду системного анализа с просьбой донести до коллег/добавить в чеклист. Надеюсь поможет.

6 лайков

Вы же уже умеете видеть, что оно, достаточно частая ситуация - когда люди используют фразы не разбираясь что фразы значат. А чтобы разбираться - нужно хотеть быть точным, хотеть быстро понимать и доносить информацию. Это не так то и просто, если например, человек вырос в окружении, где считалось что любая сложность в коммуникации… это плохие черты собеседника)) В каком то подобном случае, человек и не пойдет искать решений (в его мире нет ничего об этом). И дорога такого человека к неписанному правилу, будет примерно такой: а) узнать а желательно еще и увидеть что точность в формулировках приносит какую то пользу, и не один раз б) поверить что этому учатся а не магия и не врожденное, в) отважиться на обучение, г) честно пройти обучение
И каждый шаг тут - не на один месяц

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

1 лайк

“Поплачь о нём, пока он живой”…

Да, я понимаю. Что я в большей степени “не смогла промолчать на косяк”. Обсуждали недавно, что такое поведение это следствие МиС) А реально “описание никак не меняет мир”. Ждём третий семестр. Про себя тихо повторяем “аналитики не нужны”, нужны инженеры…

1 лайк

Все хорошо. Это правильный результат курса МИС. Я тоже там была. И все точно так же видела. Да и делала. Но мы уже на следующем семестре - и я буду напоминать, что вам труда стоило, научиться слышать и говорить. По умолчанию этого ожидать от окружающих …рано еще. Это поможет - в третьем семестре.
Замечательный пост!

1 лайк

сократить бы до “если я не очень хорошо знаю тему, я не бросаюсь заявлениями по ней” - счастье бы настало)) но

В примере 1 то что я вижу - было выявление “далекого понятийного расстояния” но попытки преодолеть как таковой/активной не было?

паровозик не смог

1 лайк

Понимааааешь… Я не могу его склонять/учить/воспитывать. У меня нет такой формальной роли. При этом я нутром чую, что ему сейчас менеджерские функции важнее, а разработческое он поддерживает на уровне “могу вести беседу”, а то что это неточно или мимо кассы, это неважно. А я для себя не решила, что мне с этим делать. Потому что как мы понимаем это ситуация обучения, а её сначала надо продать. “Точные формулировки экономят силы, время, деньги и ещё и очень приятно, и добавляют блеска в глазах и шелковситую шерсть на бороде”. А потом ещё и учить, давать объяснения, проводить презентации. Короче дорого как-то и как будто бесперспективно. Вот я урывками и врываюсь. Иногда не врываюсь, когда устала.

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

1 лайк