​​Уважаемая аудитория, у нас апдейт

Добры молодцы и девицы, у нас новина!
Из-за частых челобитных от вас об использовании в наших писаньях да лубочных представленьях басурманских словес, над писарями пестун наказал выписать толмача и впредь баять токмо на родном языке.

Челом бьём, вече NEWHR (Новый вербовщик)

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

я скопипастил большой промт для этого, и каково было мое удивление, что эта тварь повела себя как школьная училка, заставляет общаться с ним на "вы". Пиздец!

Статья от моего камарада Анатолия. Вот это заморочился мужик!! А-хре-неть!!!

https://vc.ru/life/671075-pol-eto-lava-istoriya-razrabotki-prototipa-interaktivnoy-svetodiodnoy-igrovoy-platformy

МОСКВА, 27 апреля. /ТАСС/. Президент РФ Владимир Путин согласился с необходимостью развивать собственные протоколы связи взамен зарубежных TCP/IP для обеспечения технологического суверенитета и независимости страны.
https://tass.ru/politika/17633161

Принципы S.O.L.I.D. - говно, потому что невнятные, и требуют толкователя.

Я в этой индустрии десятилетия, и регулярно натыкаюсь на очередное объяснение или, наоборот, уточняющий вопрос. Недавно опять в твиттере наткнулся на "а что для вас SRP?".
На Хабре наверно уже 100 статей, одна другой хуже. Всегда по одному сценарию: кто-то пишет, как он понял, а ему суют в панамку, что на самом-то деле подразумевалось совсем другое. Очень похоже на толкование Библии, прям один в один.

Пользуюсь ли я SOLID? Не знаю. Я пользуюсь опытом. Уж точно не сверяюсь после каждой строчки кода, а удовлетворяет ли это, например, букве O.

Кстати, да, паттерны - тоже сомнительная штука. Никакие паттерны не сделают из джуна синьора.

Даже наоборот, как начнут паттерны везде пихать на ровном месте - код вообще не понять.
2+2 складывают через три пизды и 10 абстракций.

Понимание того, где гибкость нужна, где нет - имхо не особо формализуемо.

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

Просили покритиковать какой-нибудь язык. А я не хочу, хочу посравнивать Angular и Go. Да, я знаю, что ангуляр - не язык, а фреймворк, да еще и фронтенд, и сравнивать их тупо, но я все равно буду :) Ну, я же испытываю эмоции при использовании, значит их можно сравнить.

Ну так вот. Когда-то, миллион лет назад, я жёстко хейтил язык Go за его примитивность и невыразительность. Например, если посмотреть на тот же Rust: Rust и Go - это как макбук и деревянные счёты. На го писать противно - слишком тупой язык. Я правда так думал.

Однако время шло, и судьба меня закинула сначала писать бекенд на Go, а потом, что ещё страннее, параллельно писать фронтенд на Ангуляре.

И вот мои наблюдения. То, что ты пишешь на Go, ты понимаешь полностью. Взял полено, выточил перочинным ножиком из него Буратино. Максимально просто. На ангуляре же ты машешь волшебной палочкой в надежде, что случайно всё сработает, и потом пытаешься понять, почему всё так странно выходит. То носа нет, то руки из жопы.

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

В Ангуляре это жесть. Компонент может молча не отрисоваться, потому что ты в модуле в магическом месте не подключил другие магические модули. Или подключаешь к компоненту свой scss файл, и ошибся в пути. Получшь ошибку типа "include не сработал" (не помню точный текст) без указания строки кода или хоть какого-то намёка на причину проблемы.

Вообще, концепция конфигурации вместо программирования я теперь считаю сомнительной. Явное всё же лучше неявного.

Модули ангуляра придумал враг людей, ацкая сотона. Зато простейшая программа выглядит солидно: ты там что-то вечно декларируешь, импортируешь, компонуешь и тд., сразу видно, что умный. В го наоборот, чувствуешь себя тупым, код выглядит так себе, но всё, блять, понятно и работает.

Ну так вот, если Ангуляр и соизволит выдать ошибку, то это будет стектрейс на 100 строк, состоящий на 99% из магических обёрток.

В Go же ты сам явно определяешь, где как и что выводить. А магия и обертки там не приняты.


Скорость компиляции.

Go компилирует код мгновенно. Я хз, как это работает, но это волшебство. ×10 к скорости разработки.

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

Кстати, в go много бессмысленной писанины, и это раздражает, но с появлением copilot это всё за тебя пишет робот. Ты только пишешь if, а он уже добавляет err != nil, пишет в лог или там возвращает ошибку дальше. Магия, какой она должна быть.

Ну и последнее. Зависимостей в го поменьше. Раз в миллион где-то.
На го не принято использовать фреймворки, орм и любую другую магию - только точечно нужные библиотеки. Поэтому завендорить зависимости - норма жизни.

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

У меня всё. Подписывайтесь на наш канал, в следующей серии буду сравнивать jQuery и Haskell

В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.
Вот примеры.


DRY
Например, DRY - don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.


«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY - хороший принцип, но бывают исключения.

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


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

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

и тысячи таких

У каждого программиста между ушей есть нейросеть, которой он пользуется. Нельзя рассматривать его как бездумного робота.
Если кто-то тупой и постоянно творит дичь, то не надо добавлять правил и следить за их исполнением, тупого надо просто увольнять. Зачем вам тупой???. Если это опытный программист, и в большинстве случаев поступает разумно, то не надо его ограничивать всякой хернёй - это уменьшение эффективности, да еще и снижение мотивации

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

Есть два момента в собеседовании
1. Когда ты рассказываешь о своем опыте. У тебя банально не хватит времени. Каков бы твой опыт не был, какие бы задачи ты не решал, у интервьюера нет столько времени в собеседовании что бы тебя полноценно выслушать

2. Вопросы интервьюера которые по тысячу раз встречаться на других собеседованиях и объективной оценки они конечно же не несут

Они не дадут вам понимая сможет ли кандидат в случае чего в критический момент взять на себя починку упавшего прода

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

Они не дадут вам понимания сможет ли кандидат что то написать самостоятельно с пониманием того что ему нужно на условном webpack и сможет ли вообще понять сделал он это хорошо или нет

Они не дадут вам понимания того способен ли кандидат проявить креативность и предложить идею и реализовать ее что бы сэкономить количество человеко часов, а главное в короткий срок

Они не дадут вам понимания будет ли кандидат соблюдать существующие принципы проекта, а не придумывать свои правила на код ревью, а ведь из-за этого идет потеря нервов и время на урегулирования ситуации

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

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

И много всего другого

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

Компания ищет в первую очередь не человека отвечающего как надо на вопросы интервьюера, компания ищет человека который будет способен развивать и поддерживать продукт в лучшем для него виде

Сегодня я узнал, что VK технически представляет собой один большой монолит. Монолит на KPHP, который компилируется в c++. Но ведь c++ тоже надо компилировать.

Я честно говоря не понимаю, как огромная команда может работать по такой схеме. Они же вынуждены синхронизировать процесс деплоя между бизнесовыми командами. Сколько это всё компилируется? 100500 часов?
Как тупо сделать экстренный хотфикс в такой системе? Например, чтобы закрыть уязвимость. Это прямо антидевопс подход.

Пара мыслей про микросервисы vs монолит.

Имхо к микросервисам надо переходить в тот момент, когда команда становится слишком большой, и приходит мысль разбить её на две части.

В этот момент надо во-первых, разбить команду правильно, т.е. не по технологиям (а ля бекенд и фронтенд), а согласно логике бизнеса.

Во-вторых, эти команды должны иметь возможность действовать независимо. Деплоить, рефакторить, перестраивать базы данных и что угодно, при этом не ждать никакого апрува другой команды.

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

Еще раз, это не технологическое решение, а процессное. Монолит vs микросервисы надо рассматривать с точки зрения ускорения работы бизнеса, а не "в кубере это удобно, а это нет".

Разумеется, спагетти-код разделить сложно, поэтому и монолит внутри себя с самого начала должен состоять из более менее отдельных модулей. Об этом, кстати, говорили на Highload, но там подход был имхо довольно упоротый - сразу городить по БД на каждый модуль. Имхо это чересчур для стартапа на уровне проверки гипотезы.

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

Написал чуть более расширенную статью на Хабр, плюсаните кто может )

https://habr.com/ru/companies/karuna/articles/746434/

Кстати, я думаю, что простые микросервисы - это первый код, который когда-нибудь будет полностью написан ИИ вообще без человека.

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

Можно уточнить тестами, в крайнем случае, если тупит.

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

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

Думаю, это вполне реально, и далеко не за горами. Просто Copilot на максималках

Оказывается, Oracle выкатил официальное уведомление компании "Rust for Javanoscript Developers Ltd", чтобы они переименовались во что-нибудь другое, потому что Javanoscript - зарегистрированная торговая марка компании Oracle. Источник

Во-первых, facepalm, а во-вторых, что это даёт Ораклу кроме репутационных рисков? Какие выгоды?

В разработке ПО существует одно неразрешимое противоречие - это оценка сроков.

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

С другой стороны, разработка порою в душе не е**т вообще не знает, сколько надо времени, особенно если
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода

Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.

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

Короче, предсказание сроков - это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии - честно, результат будет такой же. Херня полная.

Самый рабочий подход - это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.

Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10.

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

В итоге просто называешь какую-то магическую цифру и молишься Ктулху.

Вишенка на торте - это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо 🙂

Вместе с Женей Антоновым, небезызвестным автором канала Тимлид Очевидность, мы договорились написать пост на одну и ту же тему, а потом сравнить наши мысли.

И вот что получилось у меня:

------------------

Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?

Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!

Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.

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

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

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

Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.

В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.

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

Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.

-----------------

Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)

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