Cross Join - канал о разработке
693
@crossjoin
Канал о разработке. Go, PHP, Postgres, тимлидство и т.д
-
Cross Join - канал о разработке
В очередной раз проверил, как работает усталость на способность программировать. Вчера поздно вечером, можно сказать ночью, уставший, решил порешать задачи на литкоде. Простые и средние задачи шли норм, но вот дошел до задачки hard, где надо было чуток подумать, и началось интересное. Я сумел придумать алгоритм, и он даже сработал на некоторых тестах, но в одном тесте был какой-то затык: я пытался дебажить и так, и сяк, убил точно больше получаса на поиск проблемы, сдался и лёг спать. Интеллект 0% Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут. Просто перепутал && и || 😂 Так тупо, капец В общем, алгоритм от капитана: 1) устал - отдохни (кофе - не отдых, если чо) 2) отдохнул - работай 3) при необходимости повторить Несколько лет назад с другом обсуждали такую идею, на работников навешивать какой-нибудь аппарат типа ЭЭГ, и замерять уровень усталости (хз, есть такие или нет). Возможно так будет эффективнее (и для работника, и для работодателя), чем среднее по больнице: работай 8 часов с перерывом на обед, и может быть в среднем по планете будет норм. -
Cross Join - канал о разработке
Мало кто знает, что Кирилл Мокевнин завёл свой канал Организованное программирование. С интересом читаю и рекомендую подписаться, опыт виден в каждой строчке Вот его мнение по поводу замены програмистов ИИ 👇 -
Cross Join - канал о разработке
Серебряной пули нет Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает. Если кратко, Брукс определяет два вида сложности: случайная и необходимая. Случайная сложность, это сложность которая возникает от выбора неверных инструментов или подходов. То на что мы можем влиять и исправлять. Например мы можем выбрать более подходящий язык или фреймворк, использовать готовую библиотеку вместо написания своей и так далее. Большая часть улучшений, которыми мы занимаемся и которые делает индустрия, находятся именно в этой части, так как тут все понятно. С необходимой сложностью все не так просто. Необходимая сложность определяется бизнес задачами. Если наша программа должна делать 30 разных штук, то мы будем должны эти 30 штук написать. И у нас не будет возможность этого избежать, так как само оно делаться не начнет. Нужно считать зарплату? Придется писать код. Нужно строить отчет? Мы будем писать код, который готовит этот отчет. Брукс говорит о том, что мы хорошо справляемся со случайной сложностью, но даже когда мы ее уберем почти всю, у нас останется необходимая сложность, которая и является ядром нашего приложения. Теперь немного моих мыслей по этому поводу. Любая задача, которую мы решаем внутри нашего приложения, моделируется с помощью конечного автомата. Например заказ товара в магазине это процесс в котором есть состояние набора корзины, оформления покупки, возврата и доставки. Тоже самое относится к регистрации, к публикации постов, к прохождению курсов и т.п. Так вот код который мы пишем, это переходы из одного состояние в другое. Таким образом, мы можем примерно оценить сложность нашей системы. Взять все сущности которые проходят через нее, описать автоматы и посчитать количество переходов. Это и будет та необходимая сложность, от которой избавиться нельзя. А что насчет искуственного интелекта? Тоже самое, большинство фич, которые не являются примитивными крудами, не содержатся где-то в одном месте, как единый кусок кода. Обычно это работа с очередьми, интеграция с внешними источниками, конкретная структура базы, асинхронное выполнение, отправка писем и многое другое, что в сумме может написать только человек. Все остальное всего лишь более умный автокомплит и рефакторинг. -
Реклама
-
Cross Join - канал о разработке
Написал на Хабр статью про Go 1.21 habr.com/ru/comp…s/747726 -
Cross Join - канал о разработке
Javascript почему-то игнорирует дефолтный порт, даже если он был явно указан. Счастливой отладки :) 
-
Cross Join - канал о разработке
Пара мыслей про поиск мёртвого кода в Go, в порядке бреда В Go 1.20 сделали возможность сбилдить приложение с флагом cover go build -cover
после чего, если запустить такое приложение, то будет собираться статистика, какие части приложения были выполнены, а какие нет, и складываться в папочку, указанную в переменной окружения. Это, конечно, было сделано для хитрых интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но возможно это можно попробовать использовать и по-другому: запустить прям на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются. Это бывает нужно, когда в проекте есть старый легаси-код, и никто уже не знает, что там и зачем. Часто часть этого кода - просто старое недовыпиленное говно. И наоборот - кажется, что код уже не нужен, а он нет-нет, но иногда работает. Правда, сбор статистики наверняка вносит некоторое торможение в код, насколько много - хз, я пока что не пробовал (У меня сейчас довольно простые микросервисы, там мало кода, и нет старого непонятного легаси). Так что это точно не всем подойдёт. Просто как мысль на подумать Пара деталей: Запускать надо с переменной окружения GOCOVERDIRGOCOVERDIR=somedata ./myapp
После завершения приложения в этой папке появятся бинарники, которые можно сконвертировать в нормальный видgo tool covdata textfmt -i=somedata -o coverage.txt
и посмотреть, что там, стандартными средствами, например так:go tool cover -html=coverage.txt
Кстати, если приложение было внезапно принудительно завершено, например из-за паники, то статистика не соберется -
Cross Join - канал о разработке
Итак, принципы программирования по заветам Марксизма-Ленинизма от Владимира Ильича: 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 (Принцип диктатуры пролетариата): Код должен служить интересам большинства пользователей. Конечные пользователи - это "пролетариат" вашего кода, и его нужно разрабатывать с учетом их потребностей и интересов. Вы должны активно слушать отзывы и требования пользователей и стремиться их удовлетворить. -
Cross Join - канал о разработке
Вместе с Женей Антоновым, небезызвестным автором канала Тимлид Очевидность, мы договорились написать пост на одну и ту же тему, а потом сравнить наши мысли. И вот что получилось у меня: ------------------ Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно? Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть! Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать. Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно. Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем. И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях. Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной. В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии. Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком. Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению. ----------------- Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину) -
Cross Join - канал о разработке
В разработке ПО существует одно неразрешимое противоречие - это оценка сроков. С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно - ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве. С другой стороны, разработка порою в душе не е**твообще не знает, сколько надо времени, особенно если - новая функциональность нетипична - есть зависимости на другие команды - будет задействована новая технология - ТЗ надо сильно уточнять - надо разобраться в логике легаси-кода Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий. Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже. Короче, предсказание сроков - это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии - честно, результат будет такой же. Херня полная. Самый рабочий подход - это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало. Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10. Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать... ну а всё-таки, сколько дней-то займёт?" В итоге просто называешь какую-то магическую цифру и молишься Ктулху. Вишенка на торте - это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо 🙂 -
Cross Join - канал о разработке
Оказывается, Oracle выкатил официальное уведомление компании "Rust for Javascript Developers Ltd", чтобы они переименовались во что-нибудь другое, потому что Javascript - зарегистрированная торговая марка компании Oracle. Источник Во-первых, facepalm, а во-вторых, что это даёт Ораклу кроме репутационных рисков? Какие выгоды? -
Cross Join - канал о разработке
Кстати, я думаю, что простые микросервисы - это первый код, который когда-нибудь будет полностью написан ИИ вообще без человека. Ну реально: если входы понятно описаны(эндпоинты или консюмеры кафки), чуток бизнес-логики в доке, в итоге принять данные, в базу записать, что получилось, и куда-нибудь в кафку отправить результат, если надо. Вот и всё, по сути. Можно уточнить тестами, в крайнем случае, если тупит. Ибо иногда делаешь какой-нибудь простой а-ля crud и думаешь, блин, это даже дебил может сделать, не надо даже включать голову. Ну да, возможно будут какие-то сложности в поддержке, но опять же, если он с нуля генерится за минуту, то просто меняешь первоначальное описание и перегенеришь. Думаю, это вполне реально, и далеко не за горами. Просто Copilot на максималках -
Cross Join - канал о разработке
Написал чуть более расширенную статью на Хабр, плюсаните кто может ) habr.com/ru/comp…s/746434 -
Cross Join - канал о разработке
Go 1.21 - аттракцион невиданной щедрости (версия выйдет уже через месяц -другой) Я уже писал про работу со слайсами и мапами в 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 -
Cross Join - канал о разработке
Пара мыслей про микросервисы vs монолит. Имхо к микросервисам надо переходить в тот момент, когда команда становится слишком большой, и приходит мысль разбить её на две части. В этот момент надо во-первых, разбить команду правильно, т.е. не по технологиям (а ля бекенд и фронтенд), а согласно логике бизнеса. Во-вторых, эти команды должны иметь возможность действовать независимо. Деплоить, рефакторить, перестраивать базы данных и что угодно, при этом не ждать никакого апрува другой команды. Вот где-то в этой точке надо уже подумать о том, чтобы технологии начинали помогать бизнес-процессам, и выделять отдельные, независимые куски кода со своими базами. Будет это сразу кубер или какие-то наколенные решения поначалу - не так уж и важно. Еще раз, это не технологическое решение, а процессное. Монолит vs микросервисы надо рассматривать с точки зрения ускорения работы бизнеса, а не "в кубере это удобно, а это нет". Разумеется, спагетти-код разделить сложно, поэтому и монолит внутри себя с самого начала должен состоять из более менее отдельных модулей. Об этом, кстати, говорили на Highload, но там подход был имхо довольно упоротый - сразу городить по БД на каждый модуль. Имхо это чересчур для стартапа на уровне проверки гипотезы. -
Cross Join - канал о разработке
Видео демонстрирующее работу Windows NT 3.51 на 600MHz процессоре с 128Mb рамы на борту. Все приложеньки открываются моментально. Лицо пользователей Notion представили? ⏳ -
Реклама
-
Cross Join - канал о разработке
Сегодня я узнал, что VK технически представляет собой один большой монолит. Монолит на KPHP, который компилируется в c++. Но ведь c++ тоже надо компилировать. Я честно говоря не понимаю, как огромная команда может работать по такой схеме. Они же вынуждены синхронизировать процесс деплоя между бизнесовыми командами. Сколько это всё компилируется? 100500 часов? Как тупо сделать экстренный хотфикс в такой системе? Например, чтобы закрыть уязвимость. Это прямо антидевопс подход. -
Cross Join - канал о разработке
В айти есть одна стабильная проблема, это оценка твоего уровня. Все часто сводится к простым и средним вопросам которые кочуют от одного собеседования к другому, да есть уникальные, интересные и стоящие, но сейчас не о них Есть два момента в собеседовании 1. Когда ты рассказываешь о своем опыте. У тебя банально не хватит времени. Каков бы твой опыт не был, какие бы задачи ты не решал, у интервьюера нет столько времени в собеседовании что бы тебя полноценно выслушать 2. Вопросы интервьюера которые по тысячу раз встречаться на других собеседованиях и объективной оценки они конечно же не несут Они не дадут вам понимая сможет ли кандидат в случае чего в критический момент взять на себя починку упавшего прода Они не дадут вам понимания может ли кандидат поднимать проекты с нуля что бы они не развалились хотя бы через год (иногда тут даже пол года хватает) Они не дадут вам понимания сможет ли кандидат что то написать самостоятельно с пониманием того что ему нужно на условном webpack и сможет ли вообще понять сделал он это хорошо или нет Они не дадут вам понимания того способен ли кандидат проявить креативность и предложить идею и реализовать ее что бы сэкономить количество человеко часов, а главное в короткий срок Они не дадут вам понимания будет ли кандидат соблюдать существующие принципы проекта, а не придумывать свои правила на код ревью, а ведь из-за этого идет потеря нервов и время на урегулирования ситуации Они не дадут вам понимания того знает ли кандидат как работает его инструмент под капотом, а мне лично эти знания дали серьезный буст в скилах Для меня есть разделения в моей карьере - до того как я использовал инструмент и после - это когда уже понял как мой инструмент работает, а зная это могу понимать его подводные камни или в случае чего написать свою версию этого инструмента да и в целом качество проектирования кода возросло И много всего другого Если раньше это было не так заметно, ведь количество вакансий было велико и собеседований соответственно тоже то сейчас когда у компании есть реальные возможности выбора подходящего кандидата он упускается из-за все таких же не меняющихся принципов собеседований Компания ищет в первую очередь не человека отвечающего как надо на вопросы интервьюера, компания ищет человека который будет способен развивать и поддерживать продукт в лучшем для него виде -
Cross Join - канал о разработке
В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться. Вот примеры. DRY Например, DRY - don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен. «[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец Т.е. DRY - хороший принцип, но бывают исключения. KISS Keep it simple, stupid. Всем хотелось бы держать программу простой, но иногда приходится всё усложнить, чтобы добиться ускорения разработки, уменьшения количества ошибок и т.д. Например, KISS может войти в прямое противоречие с тем же DRY: код с дублированием зачастую проще понимать (меньше абстракций и зависимостей), зато это огромное поле для ошибок (забыл поправить в третьем файле) и замедление добавления новых фич. В фунции не должно быть более чем X строк, длина строки должна быть не более чем Y и т.д. (правила линтера) Обычно этот X придумывается от балды. В таких случаях хочется спросить, почему именно столько, а не на одну больше или на две меньше. И обычно время от времени появляется вполне валидный код, который по каким-то причинам не влезает, и люди извращаются как могут, переписывают через дичь, чтобы как-то пайплайн протащить. Мы пишем только на таком-то языке И начинаются пляски с бубном вокруг PHP, на котором пытаются завести highload-решения. Это выливается в интереснейшие инженерные задачи, как из говна и палок сделать самолёт. Бесконечные темы для докладов на конференциях. и тысячи таких У каждого программиста между ушей есть нейросеть, которой он пользуется. Нельзя рассматривать его как бездумного робота. Если кто-то тупой и постоянно творит дичь, то не надо добавлять правил и следить за их исполнением, тупого надо просто увольнять. Зачем вам тупой???. Если это опытный программист, и в большинстве случаев поступает разумно, то не надо его ограничивать всякой хернёй - это уменьшение эффективности, да еще и снижение мотивации