Cross Join - канал о разработке pinned «Минусы скрама 1) Считается, что команда "комитится", что сделает всё запланированное на спринт. Однако точно угадать сроки невозможно никогда, в жизни не видел еще точно угаданных сроков. А перерабатывать по ночам, чтобы успеть в спринт, никто не будет,…»
Пара мыслей про микросервисы vs монолит.
Имхо к микросервисам надо переходить в тот момент, когда команда становится слишком большой, и приходит мысль разбить её на две части.
В этот момент надо во-первых, разбить команду правильно, т.е. не по технологиям (а ля бекенд и фронтенд), а согласно логике бизнеса.
Во-вторых, эти команды должны иметь возможность действовать независимо. Деплоить, рефакторить, перестраивать базы данных и что угодно, при этом не ждать никакого апрува другой команды.
Вот где-то в этой точке надо уже подумать о том, чтобы технологии начинали помогать бизнес-процессам, и выделять отдельные, независимые куски кода со своими базами. Будет это сразу кубер или какие-то наколенные решения поначалу - не так уж и важно.
Еще раз, это не технологическое решение, а процессное. Монолит vs микросервисы надо рассматривать с точки зрения ускорения работы бизнеса, а не "в кубере это удобно, а это нет".
Разумеется, спагетти-код разделить сложно, поэтому и монолит внутри себя с самого начала должен состоять из более менее отдельных модулей. Об этом, кстати, говорили на Highload, но там подход был имхо довольно упоротый - сразу городить по БД на каждый модуль. Имхо это чересчур для стартапа на уровне проверки гипотезы.
Имхо к микросервисам надо переходить в тот момент, когда команда становится слишком большой, и приходит мысль разбить её на две части.
В этот момент надо во-первых, разбить команду правильно, т.е. не по технологиям (а ля бекенд и фронтенд), а согласно логике бизнеса.
Во-вторых, эти команды должны иметь возможность действовать независимо. Деплоить, рефакторить, перестраивать базы данных и что угодно, при этом не ждать никакого апрува другой команды.
Вот где-то в этой точке надо уже подумать о том, чтобы технологии начинали помогать бизнес-процессам, и выделять отдельные, независимые куски кода со своими базами. Будет это сразу кубер или какие-то наколенные решения поначалу - не так уж и важно.
Еще раз, это не технологическое решение, а процессное. Монолит vs микросервисы надо рассматривать с точки зрения ускорения работы бизнеса, а не "в кубере это удобно, а это нет".
Разумеется, спагетти-код разделить сложно, поэтому и монолит внутри себя с самого начала должен состоять из более менее отдельных модулей. Об этом, кстати, говорили на Highload, но там подход был имхо довольно упоротый - сразу городить по БД на каждый модуль. Имхо это чересчур для стартапа на уровне проверки гипотезы.
👍15🔥2💩1
Go 1.21 - аттракцион невиданной щедрости (версия выйдет уже через месяц -другой)
Я уже писал про работу со слайсами и мапами в 1.21 (теперь можно из коробки найти элемент в списке!!!!111111). Т.е. не прошло и 10 лет, как стандартная библиотека наполнилась самыми необходимыми, самыми базовыми функциями. Я чуть не разрыдался от счастья.
Так вот, недавно туда же включили и нормальный логгер!
Чтоб вы понимали, я видел опросники для собесов по Go, где один из стандартных вопросов был "расскажите, почему встроенный логгер такое говно, что его никто не использует".
Его никто не использует, потому что они ничего не может. В итоге у всех в проектах появились сторонние решения zerolog, logrus и т.д.
В новой версии Go добавили пакет log/slog (игра слов: slog переводится как "вкалывать", "утомительный"), в котором есть:
- уровни severity: Debug, Info, Warn, Error (или можно использовать любое integer-число)
- возможность использовать Handler: textHandler, jsonHandler или свой собственный, удовлетворяющий интерфейсу Handler
- встроенная возможность передачи ключ-значение:
если использовать вместе с json-хандлером, то вывод будет такой:
- эти ключи-значения можно группировать, и получать вложенный джейсон (slog.Group)
- можно выводить лог с контекстом
- всякие фишечки для удобства и производительности, например метод With, который возвращает sub-логгер, при создании которого можно сразу задать некоторые атрибуты. Встроенные хандлеры отформатируют их один раз.
В общем, в своих проектах я, пожалуй, выкину zerolog, потому что встроенного логгера мне вроде бы теперь хватает.
Кстати, все эти нововведения стали возможны благодаря тому, что в 1.19 сделали дженерики. Даже если они в продуктовом коде большинству не нужны, то для общих библиотек - must have
Я уже писал про работу со слайсами и мапами в 1.21 (теперь можно из коробки найти элемент в списке!!!!111111). Т.е. не прошло и 10 лет, как стандартная библиотека наполнилась самыми необходимыми, самыми базовыми функциями. Я чуть не разрыдался от счастья.
Так вот, недавно туда же включили и нормальный логгер!
Чтоб вы понимали, я видел опросники для собесов по Go, где один из стандартных вопросов был "расскажите, почему встроенный логгер такое говно, что его никто не использует".
Его никто не использует, потому что они ничего не может. В итоге у всех в проектах появились сторонние решения zerolog, logrus и т.д.
В новой версии Go добавили пакет log/slog (игра слов: slog переводится как "вкалывать", "утомительный"), в котором есть:
- уровни severity: Debug, Info, Warn, Error (или можно использовать любое integer-число)
- возможность использовать Handler: textHandler, jsonHandler или свой собственный, удовлетворяющий интерфейсу Handler
- встроенная возможность передачи ключ-значение:
// здесь message - это "hello",
// и еще приделывается ключ-значение count=3
logger.Info("hello", "count", 3)
если использовать вместе с json-хандлером, то вывод будет такой:
{"time":"2022-11-08T15:28:26.000000000-05:00","level":"INFO","msg":"hello","count":3}- эти ключи-значения можно группировать, и получать вложенный джейсон (slog.Group)
- можно выводить лог с контекстом
// slog.InfoCtx(ctx, "message", "key", val)- всякие фишечки для удобства и производительности, например метод With, который возвращает sub-логгер, при создании которого можно сразу задать некоторые атрибуты. Встроенные хандлеры отформатируют их один раз.
В общем, в своих проектах я, пожалуй, выкину zerolog, потому что встроенного логгера мне вроде бы теперь хватает.
Кстати, все эти нововведения стали возможны благодаря тому, что в 1.19 сделали дженерики. Даже если они в продуктовом коде большинству не нужны, то для общих библиотек - must have
👍2💩1
Написал чуть более расширенную статью на Хабр, плюсаните кто может )
https://habr.com/ru/companies/karuna/articles/746434/
https://habr.com/ru/companies/karuna/articles/746434/
Хабр
Монолит или микросервисы — это не вопрос технологических предпочтений, это про time-to-market
На конференциях эта тема (монолит vs микросервисы) обсуждается с завидной регулярностью, но обычно в техническом ключе. Кто-то любит консистентность монолита, кто-то гибкость микросервисов, какие-то...
❤16👍7💩1
Кстати, я думаю, что простые микросервисы - это первый код, который когда-нибудь будет полностью написан ИИ вообще без человека.
Ну реально: если входы понятно описаны(эндпоинты или консюмеры кафки), чуток бизнес-логики в доке, в итоге принять данные, в базу записать, что получилось, и куда-нибудь в кафку отправить результат, если надо. Вот и всё, по сути.
Можно уточнить тестами, в крайнем случае, если тупит.
Ибо иногда делаешь какой-нибудь простой а-ля crud и думаешь, блин, это даже дебил может сделать, не надо даже включать голову.
Ну да, возможно будут какие-то сложности в поддержке, но опять же, если он с нуля генерится за минуту, то просто меняешь первоначальное описание и перегенеришь.
Думаю, это вполне реально, и далеко не за горами. Просто Copilot на максималках
Ну реально: если входы понятно описаны(эндпоинты или консюмеры кафки), чуток бизнес-логики в доке, в итоге принять данные, в базу записать, что получилось, и куда-нибудь в кафку отправить результат, если надо. Вот и всё, по сути.
Можно уточнить тестами, в крайнем случае, если тупит.
Ибо иногда делаешь какой-нибудь простой а-ля crud и думаешь, блин, это даже дебил может сделать, не надо даже включать голову.
Ну да, возможно будут какие-то сложности в поддержке, но опять же, если он с нуля генерится за минуту, то просто меняешь первоначальное описание и перегенеришь.
Думаю, это вполне реально, и далеко не за горами. Просто Copilot на максималках
🤔10👍6
Оказывается, Oracle выкатил официальное уведомление компании "Rust for Javanoscript Developers Ltd", чтобы они переименовались во что-нибудь другое, потому что Javanoscript - зарегистрированная торговая марка компании Oracle. Источник
Во-первых, facepalm, а во-вторых, что это даёт Ораклу кроме репутационных рисков? Какие выгоды?
Во-первых, facepalm, а во-вторых, что это даёт Ораклу кроме репутационных рисков? Какие выгоды?
🤡13👎1👀1
В разработке ПО существует одно неразрешимое противоречие - это оценка сроков.
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно - ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
С другой стороны, разработка пороюв душе не е**т вообще не знает, сколько надо времени, особенно если
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода
Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.
Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже.
Короче, предсказание сроков - это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии - честно, результат будет такой же. Херня полная.
Самый рабочий подход - это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.
Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10.
Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать... ну а всё-таки, сколько дней-то займёт?"
В итоге просто называешь какую-то магическую цифру и молишься Ктулху.
Вишенка на торте - это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо 🙂
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно - ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
С другой стороны, разработка порою
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода
Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.
Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже.
Короче, предсказание сроков - это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии - честно, результат будет такой же. Херня полная.
Самый рабочий подход - это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.
Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10.
Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать... ну а всё-таки, сколько дней-то займёт?"
В итоге просто называешь какую-то магическую цифру и молишься Ктулху.
Вишенка на торте - это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо 🙂
👏19👍7💯4🤮2👎1🔥1
Вместе с Женей Антоновым, небезызвестным автором канала Тимлид Очевидность, мы договорились написать пост на одну и ту же тему, а потом сравнить наши мысли.
И вот что получилось у меня:
------------------
Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?
Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!
Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.
Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно.
Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем.
И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях.
Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.
В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.
Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком.
Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.
-----------------
Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)
И вот что получилось у меня:
------------------
Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?
Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!
Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.
Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно.
Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем.
И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях.
Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.
В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.
Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком.
Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.
-----------------
Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)
👍20❤4🤮3👎2🔥2🤔1🌚1👀1
Forwarded from Пятиминутка PHP
Итак, принципы программирования по заветам Марксизма-Ленинизма от Владимира Ильича: LENIND
L - Labor Equality Principle (Принцип равенства труда): Все элементы кода должны иметь равные возможности для исполнения. Избегайте привилегирования каких-либо частей кода за счет других. Каждая функция, метод или класс должны иметь равный доступ к ресурсам и возможности для выполнения своих задач.
E - Economic Efficiency Principle (Принцип экономической эффективности): Максимизируйте использование ресурсов. Оптимизируйте ваш код для достижения максимальной производительности с минимальными затратами. Всякий излишек должен быть устранен.
N - Necessity Principle (Принцип необходимости): Каждый элемент кода должен быть необходимым и иметь цель. Избегайте бесцельного кода. Если часть кода не способствует общей цели программы, она должна быть исключена.
I - International Solidarity Principle (Принцип международной солидарности): Код должен быть написан таким образом, чтобы его можно было легко использовать, модифицировать и понимать в любой точке мира. Это включает в себя учет локализации и интернационализации, использование ясных комментариев и документации, а также придерживание стандартов кодирования.
N - No Exploitation Principle (Принцип нон-эксплуатации): Код не должен злоупотреблять своими ресурсами или зависимостями. Избегайте ситуаций, когда одна часть кода "эксплуатирует" другую, используя больше ресурсов, чем необходимо, или принуждая ее выполнять задачи за себя.
D - Dictatorship of the Proletariat Principle (Принцип диктатуры пролетариата): Код должен служить интересам большинства пользователей. Конечные пользователи - это "пролетариат" вашего кода, и его нужно разрабатывать с учетом их потребностей и интересов. Вы должны активно слушать отзывы и требования пользователей и стремиться их удовлетворить.
L - Labor Equality Principle (Принцип равенства труда): Все элементы кода должны иметь равные возможности для исполнения. Избегайте привилегирования каких-либо частей кода за счет других. Каждая функция, метод или класс должны иметь равный доступ к ресурсам и возможности для выполнения своих задач.
E - Economic Efficiency Principle (Принцип экономической эффективности): Максимизируйте использование ресурсов. Оптимизируйте ваш код для достижения максимальной производительности с минимальными затратами. Всякий излишек должен быть устранен.
N - Necessity Principle (Принцип необходимости): Каждый элемент кода должен быть необходимым и иметь цель. Избегайте бесцельного кода. Если часть кода не способствует общей цели программы, она должна быть исключена.
I - International Solidarity Principle (Принцип международной солидарности): Код должен быть написан таким образом, чтобы его можно было легко использовать, модифицировать и понимать в любой точке мира. Это включает в себя учет локализации и интернационализации, использование ясных комментариев и документации, а также придерживание стандартов кодирования.
N - No Exploitation Principle (Принцип нон-эксплуатации): Код не должен злоупотреблять своими ресурсами или зависимостями. Избегайте ситуаций, когда одна часть кода "эксплуатирует" другую, используя больше ресурсов, чем необходимо, или принуждая ее выполнять задачи за себя.
D - Dictatorship of the Proletariat Principle (Принцип диктатуры пролетариата): Код должен служить интересам большинства пользователей. Конечные пользователи - это "пролетариат" вашего кода, и его нужно разрабатывать с учетом их потребностей и интересов. Вы должны активно слушать отзывы и требования пользователей и стремиться их удовлетворить.
🤮25😁15🤡4👍3💩3🌚3🔥1😱1
Пара мыслей про поиск мёртвого кода в Go, в порядке бреда
В Go 1.20 сделали возможность сбилдить приложение с флагом cover
после чего, если запустить такое приложение, то будет собираться статистика, какие части приложения были выполнены, а какие нет, и складываться в папочку, указанную в переменной окружения.
Это, конечно, было сделано для хитрых интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но возможно это можно попробовать использовать и по-другому:
запустить прям на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются.
Это бывает нужно, когда в проекте есть старый легаси-код, и никто уже не знает, что там и зачем. Часто часть этого кода - просто старое недовыпиленное говно. И наоборот - кажется, что код уже не нужен, а он нет-нет, но иногда работает.
Правда, сбор статистики наверняка вносит некоторое торможение в код, насколько много - хз, я пока что не пробовал (У меня сейчас довольно простые микросервисы, там мало кода, и нет старого непонятного легаси). Так что это точно не всем подойдёт.
Просто как мысль на подумать
Пара деталей:
Запускать надо с переменной окружения GOCOVERDIR
После завершения приложения в этой папке появятся бинарники, которые можно сконвертировать в нормальный вид
и посмотреть, что там, стандартными средствами, например так:
Кстати, если приложение было внезапно принудительно завершено, например из-за паники, то статистика не соберется
В Go 1.20 сделали возможность сбилдить приложение с флагом cover
go build -cover
после чего, если запустить такое приложение, то будет собираться статистика, какие части приложения были выполнены, а какие нет, и складываться в папочку, указанную в переменной окружения.
Это, конечно, было сделано для хитрых интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но возможно это можно попробовать использовать и по-другому:
запустить прям на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются.
Это бывает нужно, когда в проекте есть старый легаси-код, и никто уже не знает, что там и зачем. Часто часть этого кода - просто старое недовыпиленное говно. И наоборот - кажется, что код уже не нужен, а он нет-нет, но иногда работает.
Правда, сбор статистики наверняка вносит некоторое торможение в код, насколько много - хз, я пока что не пробовал (У меня сейчас довольно простые микросервисы, там мало кода, и нет старого непонятного легаси). Так что это точно не всем подойдёт.
Просто как мысль на подумать
Пара деталей:
Запускать надо с переменной окружения GOCOVERDIR
GOCOVERDIR=somedata ./myapp
После завершения приложения в этой папке появятся бинарники, которые можно сконвертировать в нормальный вид
go tool covdata textfmt -i=somedata -o coverage.txt
и посмотреть, что там, стандартными средствами, например так:
go tool cover -html=coverage.txt
Кстати, если приложение было внезапно принудительно завершено, например из-за паники, то статистика не соберется
👍21😱2🤮2
Мало кто знает, что Кирилл Мокевнин завёл свой канал Организованное программирование. С интересом читаю и рекомендую подписаться, опыт виден в каждой строчке
Вот его мнение по поводу замены програмистов ИИ 👇
Вот его мнение по поводу замены програмистов ИИ 👇
👍3
Forwarded from Организованное программирование | Кирилл Мокевнин (Kirill Mokevnin)
Серебряной пули нет
Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает.
Если кратко, Брукс определяет два вида сложности: случайная и необходимая.
Случайная сложность, это сложность которая возникает от выбора неверных инструментов или подходов. То на что мы можем влиять и исправлять. Например мы можем выбрать более подходящий язык или фреймворк, использовать готовую библиотеку вместо написания своей и так далее. Большая часть улучшений, которыми мы занимаемся и которые делает индустрия, находятся именно в этой части, так как тут все понятно.
С необходимой сложностью все не так просто. Необходимая сложность определяется бизнес задачами. Если наша программа должна делать 30 разных штук, то мы будем должны эти 30 штук написать. И у нас не будет возможность этого избежать, так как само оно делаться не начнет. Нужно считать зарплату? Придется писать код. Нужно строить отчет? Мы будем писать код, который готовит этот отчет.
Брукс говорит о том, что мы хорошо справляемся со случайной сложностью, но даже когда мы ее уберем почти всю, у нас останется необходимая сложность, которая и является ядром нашего приложения.
Теперь немного моих мыслей по этому поводу. Любая задача, которую мы решаем внутри нашего приложения, моделируется с помощью конечного автомата. Например заказ товара в магазине это процесс в котором есть состояние набора корзины, оформления покупки, возврата и доставки. Тоже самое относится к регистрации, к публикации постов, к прохождению курсов и т.п. Так вот код который мы пишем, это переходы из одного состояние в другое. Таким образом, мы можем примерно оценить сложность нашей системы. Взять все сущности которые проходят через нее, описать автоматы и посчитать количество переходов. Это и будет та необходимая сложность, от которой избавиться нельзя.
А что насчет искуственного интелекта? Тоже самое, большинство фич, которые не являются примитивными крудами, не содержатся где-то в одном месте, как единый кусок кода. Обычно это работа с очередьми, интеграция с внешними источниками, конкретная структура базы, асинхронное выполнение, отправка писем и многое другое, что в сумме может написать только человек. Все остальное всего лишь более умный автокомплит и рефакторинг.
Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает.
Если кратко, Брукс определяет два вида сложности: случайная и необходимая.
Случайная сложность, это сложность которая возникает от выбора неверных инструментов или подходов. То на что мы можем влиять и исправлять. Например мы можем выбрать более подходящий язык или фреймворк, использовать готовую библиотеку вместо написания своей и так далее. Большая часть улучшений, которыми мы занимаемся и которые делает индустрия, находятся именно в этой части, так как тут все понятно.
С необходимой сложностью все не так просто. Необходимая сложность определяется бизнес задачами. Если наша программа должна делать 30 разных штук, то мы будем должны эти 30 штук написать. И у нас не будет возможность этого избежать, так как само оно делаться не начнет. Нужно считать зарплату? Придется писать код. Нужно строить отчет? Мы будем писать код, который готовит этот отчет.
Брукс говорит о том, что мы хорошо справляемся со случайной сложностью, но даже когда мы ее уберем почти всю, у нас останется необходимая сложность, которая и является ядром нашего приложения.
Теперь немного моих мыслей по этому поводу. Любая задача, которую мы решаем внутри нашего приложения, моделируется с помощью конечного автомата. Например заказ товара в магазине это процесс в котором есть состояние набора корзины, оформления покупки, возврата и доставки. Тоже самое относится к регистрации, к публикации постов, к прохождению курсов и т.п. Так вот код который мы пишем, это переходы из одного состояние в другое. Таким образом, мы можем примерно оценить сложность нашей системы. Взять все сущности которые проходят через нее, описать автоматы и посчитать количество переходов. Это и будет та необходимая сложность, от которой избавиться нельзя.
А что насчет искуственного интелекта? Тоже самое, большинство фич, которые не являются примитивными крудами, не содержатся где-то в одном месте, как единый кусок кода. Обычно это работа с очередьми, интеграция с внешними источниками, конкретная структура базы, асинхронное выполнение, отправка писем и многое другое, что в сумме может написать только человек. Все остальное всего лишь более умный автокомплит и рефакторинг.
👍11❤8
В очередной раз проверил, как работает усталость на способность программировать. Вчера поздно вечером, можно сказать ночью, уставший, решил порешать задачи на литкоде. Простые и средние задачи шли норм, но вот дошел до задачки hard, где надо было чуток подумать, и началось интересное.
Я сумел придумать алгоритм, и он даже сработал на некоторых тестах, но в одном тесте был какой-то затык: я пытался дебажить и так, и сяк, убил точно больше получаса на поиск проблемы, сдался и лёг спать. Интеллект 0%
Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут.
Просто перепутал && и || 😂
Так тупо, капец
В общем, алгоритм от капитана:
1) устал - отдохни (кофе - не отдых, если чо)
2) отдохнул - работай
3) при необходимости повторить
Несколько лет назад с другом обсуждали такую идею, на работников навешивать какой-нибудь аппарат типа ЭЭГ, и замерять уровень усталости (хз, есть такие или нет). Возможно так будет эффективнее (и для работника, и для работодателя), чем среднее по больнице: работай 8 часов с перерывом на обед, и может быть в среднем по планете будет норм.
Я сумел придумать алгоритм, и он даже сработал на некоторых тестах, но в одном тесте был какой-то затык: я пытался дебажить и так, и сяк, убил точно больше получаса на поиск проблемы, сдался и лёг спать. Интеллект 0%
Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут.
Просто перепутал && и || 😂
Так тупо, капец
В общем, алгоритм от капитана:
1) устал - отдохни (кофе - не отдых, если чо)
2) отдохнул - работай
3) при необходимости повторить
Несколько лет назад с другом обсуждали такую идею, на работников навешивать какой-нибудь аппарат типа ЭЭГ, и замерять уровень усталости (хз, есть такие или нет). Возможно так будет эффективнее (и для работника, и для работодателя), чем среднее по больнице: работай 8 часов с перерывом на обед, и может быть в среднем по планете будет норм.
👍22🔥3❤2💩1
Пятничный наброс
Есть два способа управлять разработчиками, через процессы и через использование головного мозга.
В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.
Плюсы: можно брать более-менее любого человека, его поставят на рельсы, проконтролируют, и поезд будет ехать в нужную сторону
Минусы: нет чувства ответственности за результат, все заняты процессами. Да и вообще, подход "один размер подходит всем" работает не очень эффективно, поэтому быстрой разработки тут не будет точно. Смелых решений никто не предложит. Ты начальник, я дурак. Инициативные люди устают биться о стену апрувов на каждый чих и выгорают. Тимлид тоже подгорает, потому что приходится принимать все решения, а не все решения принимаются правильно (так как сверху видно далеко не всё).
Во втором случае предполагается, что мы нанимаем не только навыки кодописательства, но и мозг целиком. Что программист может сам обговорить некоторые детали с заказчиком, сам понять, что важно тестировать, а что нет. Какие подходы и библиотеки использовать. Например, потому что он сам же будет это поддерживать, выкатывать на прод и разгребать потом проблемы. Формальные апрувы необязательны, разве что он сам захочет показать код товарищам для валидации идеи.
Плюсы: максимальная свобода порождает дополнительную мотивацию. С развязанными руками легче работать. Появляется ответственность за результат. Результат достигается оптимальным в данном контексте образом, а не по усредненной инструкции. Предлагаются идеи, что можно поменять, чтобы было легче работать. Тимлид на расслабоне может поехать в отпуск, да и вообще он может себе позволить быть самым тупым в команде, это нормально.
Минусы: огромные требования к найму. Если ленивый или тупой попадет в команду с максимальной свободой, то проекту пизда. Отсюда вытекает главное требование к тимлиду: быть способным быстро уволить человека, который работает плохо. И не мешать ничем людям, которые и так работают хорошо. По сути, надо изредка контролировать лишь результат: код более менее норм, пишется быстро, прод не ложится каждые 5 минут и т.д. А как именно человек этого достиг - это его дело.
Понятно, что новичков все равно придется контролировать поначалу, да и вообще, это крайние вырожденные случаи, обычно бывает смесь двух подходов. Но я всё же явно тяготею к последнему способу и стремлюсь продвинуться к нему как можно сильнее.
Есть два способа управлять разработчиками, через процессы и через использование головного мозга.
В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.
Плюсы: можно брать более-менее любого человека, его поставят на рельсы, проконтролируют, и поезд будет ехать в нужную сторону
Минусы: нет чувства ответственности за результат, все заняты процессами. Да и вообще, подход "один размер подходит всем" работает не очень эффективно, поэтому быстрой разработки тут не будет точно. Смелых решений никто не предложит. Ты начальник, я дурак. Инициативные люди устают биться о стену апрувов на каждый чих и выгорают. Тимлид тоже подгорает, потому что приходится принимать все решения, а не все решения принимаются правильно (так как сверху видно далеко не всё).
Во втором случае предполагается, что мы нанимаем не только навыки кодописательства, но и мозг целиком. Что программист может сам обговорить некоторые детали с заказчиком, сам понять, что важно тестировать, а что нет. Какие подходы и библиотеки использовать. Например, потому что он сам же будет это поддерживать, выкатывать на прод и разгребать потом проблемы. Формальные апрувы необязательны, разве что он сам захочет показать код товарищам для валидации идеи.
Плюсы: максимальная свобода порождает дополнительную мотивацию. С развязанными руками легче работать. Появляется ответственность за результат. Результат достигается оптимальным в данном контексте образом, а не по усредненной инструкции. Предлагаются идеи, что можно поменять, чтобы было легче работать. Тимлид на расслабоне может поехать в отпуск, да и вообще он может себе позволить быть самым тупым в команде, это нормально.
Минусы: огромные требования к найму. Если ленивый или тупой попадет в команду с максимальной свободой, то проекту пизда. Отсюда вытекает главное требование к тимлиду: быть способным быстро уволить человека, который работает плохо. И не мешать ничем людям, которые и так работают хорошо. По сути, надо изредка контролировать лишь результат: код более менее норм, пишется быстро, прод не ложится каждые 5 минут и т.д. А как именно человек этого достиг - это его дело.
Понятно, что новичков все равно придется контролировать поначалу, да и вообще, это крайние вырожденные случаи, обычно бывает смесь двух подходов. Но я всё же явно тяготею к последнему способу и стремлюсь продвинуться к нему как можно сильнее.
🔥33👍12😁2💩2
Нашел забавную вводную статью (я бы даже сказал вводную миникнигу), объясняющую происходящее с программой на низком уровне: как работает процессор, как запускается приложение, как несколько процессов работают одновременно, что такое syscall, зачем нужен libc, как идет взаимодействие с памятью и т.д.
Причем всё, можно сказать, практически на пальцах, насколько это возможно. Для тех, у кого нет общего понимания здесь - must read:
https://cpu.land/
Подпишись на канал о разработке Cross Join
Причем всё, можно сказать, практически на пальцах, насколько это возможно. Для тех, у кого нет общего понимания здесь - must read:
https://cpu.land/
Подпишись на канал о разработке Cross Join
🔥45👍9❤6💩2
Cross Join - канал о разработке pinned «Нашел забавную вводную статью (я бы даже сказал вводную миникнигу), объясняющую происходящее с программой на низком уровне: как работает процессор, как запускается приложение, как несколько процессов работают одновременно, что такое syscall, зачем нужен libc…»
В статье про комплексную эффективность разработки есть забавные цифры про концентрацию программиста:
Разработчик не робот, ему в среднем нужно 23 минуты непрерывной концентрации, прежде чем он войдёт в состояние потока, в котором достигается оптимальная продуктивность.
Инженеры в больших корпорациях по статистике имеют лишь 16.9 часов в неделю, когда они могут нормально сосредоточиться (против 22.5 в более маленьких компаниях).
Т.е. простая, но важная мысль: для эффективности команды надо не только следить, чтобы не было бессмысленных митингов, но важен и порядок их следования: экстремально важно, чтобы у разработчиков был большой кусок непрерывного времени, с учетом митингов/обедов и прочих активностей.
От этой беды, кстати, часто страдают разработчики, ставшие тимлидами: мало того, что куча митингов, но между ними мозг еще и не успевает толком перестраиваться на программирование, и толку от такого кодинга зачастую немного. Это вызывает страдания ("я весь день только болтал, а работать - не работал"). Особенно, потому что со стороны на такую ерунду, как разбивка времени по дню, вообще никто не обращает внимания.
Что можно сделать навскидку: регулярные встречи двигать в самое начало (конец) дня или вплотную к обеду; выделять в календаре блоки времени "я работаю", чтобы никто не вставил туда встречу; на скучных митингах выключать звук - это хорошее время спокойно поработать 🙂
Если серьёзно, то очень хорошо, что эту тему начали поднимать. Пройдет лет 5, и учет непрерывности времени разработки может быть будет стандартом. Хотя, хрен там, наверно 10
P.S. Когда падает прод, чайка-менеджмент из серии "ну че, скоро там почините?" тоже не добавляет концентрации
Разработчик не робот, ему в среднем нужно 23 минуты непрерывной концентрации, прежде чем он войдёт в состояние потока, в котором достигается оптимальная продуктивность.
Инженеры в больших корпорациях по статистике имеют лишь 16.9 часов в неделю, когда они могут нормально сосредоточиться (против 22.5 в более маленьких компаниях).
Т.е. простая, но важная мысль: для эффективности команды надо не только следить, чтобы не было бессмысленных митингов, но важен и порядок их следования: экстремально важно, чтобы у разработчиков был большой кусок непрерывного времени, с учетом митингов/обедов и прочих активностей.
От этой беды, кстати, часто страдают разработчики, ставшие тимлидами: мало того, что куча митингов, но между ними мозг еще и не успевает толком перестраиваться на программирование, и толку от такого кодинга зачастую немного. Это вызывает страдания ("я весь день только болтал, а работать - не работал"). Особенно, потому что со стороны на такую ерунду, как разбивка времени по дню, вообще никто не обращает внимания.
Что можно сделать навскидку: регулярные встречи двигать в самое начало (конец) дня или вплотную к обеду; выделять в календаре блоки времени "я работаю", чтобы никто не вставил туда встречу; на скучных митингах выключать звук - это хорошее время спокойно поработать 🙂
Если серьёзно, то очень хорошо, что эту тему начали поднимать. Пройдет лет 5, и учет непрерывности времени разработки может быть будет стандартом. Хотя, хрен там, наверно 10
P.S. Когда падает прод, чайка-менеджмент из серии "ну че, скоро там почините?" тоже не добавляет концентрации
👍40🤡3🤔1💩1
Петя в канале "Пятиминутка PHP" (советую подписаться!) скинул восхитительную новость. Так вот для чего были все эти вопросы на собеседованиях про сортировку :)))) 👇