Ключ к эффективности разработки: делать то, что нужно, но лишнего не делать.

Кучу времени можно сэкономить если:

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

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

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

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

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

Проверять на код ревью важные вещи
Не докапываться до стилистических мелочей и вкусовщины, а некоторые очевидные MR(PR) вообще не проводить через код ревью

Тщательно запланировать работы перед важным дедлайном
Не тратить (много) времени на планирование, если нет дедлайна или нет взаимодействия с другими командами

К сожалению, люди часто упарываются во что-то одно, или перфекционизм, или вселенский пофигизм. Или 100% тестирование в пет-проекте или катим работу с деньгами без тестирования прямо в прод. Это какое-то когнитивное искажение, человеку проще выбрать один шаблон, и всё делать по нему, унифицируя всё и вся, все проекты и задачи.

Я призываю всегда думать и взвешивать вероятности. Быть осознанным. Ключевой вопрос "А что будет, если не делать?". Это точно окупится.

Короче, нормально делай - нормально будет, и подписывайся на Cross Join

Написал статью, про то, как найти мёртвый код в Go-программе, а также заодно пересчитать тестовое покрытие относительно живого кода

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

В последние дни несколько раз натыкался на обсуждения ниши языка Go

Вот краткое резюме:

Go нужен для написания небольших приложений с высокой производительностью при условии относительной легкости написания кода.

C++ производительнее, но очень сложный и надо внимательно следить за памятью

Си тоже производительнее, но тоже надо следить за памятью и тд, хотя синтаксически он беден и прост.

Rust суперсложный.

Java, PHP, Ruby и т.д. - они не такие дубовые синтаксически, как Go, но производительность в большинстве случаев на практике получается намного хуже. И научиться языкам с нуля сложнее.

Go - где-то по середине. Это идеологически как C (такой же бедный), но только туда вкорячено еще чуть-чуть ООП (без наследования), горутины и управление памятью.

Т.е. если нужно писать большой монолит со 100 слоями абстракций - Go подойдет наверно не очень, лучше брать Java.

Если нужно писать сверхпроизводительные вещи, где важны каждый байт и каждый такт - Go подойдет плохо.

Если нужно написать производительный микросервис без лишних заморок или CLI-утилиту - Go будет идеальным выбором. Причем научиться языку очень просто. Как показывает практика, PHP-шника переучить на Go можно прям на ходу.

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

Хотя программирование там тоже есть )
Надеюсь, его зарождающийся бизнес выстрелит!

https://habr.com/ru/articles/766054/

Вопрос от анонима (мопед не мой), нужен совет, бест практис:

"Я иногда собеседую людей и меня всегда удивлял тот факт, что никто еще не сделал идеального мониторинга.
Мы для себя придумали правила, по которым пытаемся настраивать мониторинг, чтобы он отвечал на главный вопрос - надо ли отрывать жопу и бежать фиксить.

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

Тут надо отметить, что не все нотификации приводят к алерту (не отсылаются в on-call), а только те, что мы определили как Critical. Warning и Info просто насыпают в Slack.

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

Как побороть это говно? Как сделать мониторинг, в котором будут только реальные проблемы?"

На вчерашний вопрос про мониторинг отвечает Алексей Рыбак, уже более 10 лет занимающейся управлением разработкой.

Побороть это всё можно только если отказаться от вашего флоу, при котором неизвестные ошибки вдруг почему-то имеют такое же значение и валится туда же, куда валится отфильтрованное, важное, бережно отобранное. Так будет продолжаться всю жизнь: фильтров на все случаи жизни не понаделаешь. Что делать (1) выбрать бизнес-метрики и реагировать в первую очередь на них: не смогли зарегистрироваться, не смогли выполнить платеж, резко снизился поток регистраций/кликов/юзеров онлайн (2) по процедуре (просыпаться ночью и бежать тушить) реагировать только на отобранное (3) нефильрованное складывать отдельно, и следить, чтобы по возможности каждому типу ошибки соответствовал фильтр, не было неизвестных ошибок (это можно сделать метрикой - процент “неизвестного говна”) (4) если вы большие, то завести дежурных, которые могут по бизнес-метрикам и логам оперативно разрулить ситуацию и принять решение будить инженера или нет.

Кстати, Алексей недавно запустил курс devhands.io/ru, где обещает за 6 месяцев “обучить хайлоаду”, там осталось несколько мест в октябрьский набор. Я сам не очень понимаю, как это можно сделать за 6 месяцев, но там вроде с первого дня дают в управление инфру и сплошь практика, Алексей утверждает, что такой подход работает. Если вдруг кто из подписчиков ходит на эти курсы или интересовался - напишите в комментарии, интересно. Ещё у Алексея есть интересный канал @rybakalexey.

Микросервис на Java - забивать гвозди микроскопом.
Монолит на Go - использовать молоток для исследования бактерий.

Вот вообще не согласен. Любые отклонения как в ту, так и в другую сторону, ни к чему 👇

Пацифизм в работе

Исполнительный и не конфликтный, божий одуванчик, добряк и лапочка, он не задает вопросов, а свято верит в начальство и бежит туда, куда скажут быстрее всех, на благо компании, чисто «за идею». Мечта руководителя, но только слабого руководителя-куколда.

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

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

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

В языке Go есть слоган "Do not communicate by sharing memory; instead, share memory by communicating". Если по-простому, то это означает, что лучше использовать го-каналы, чем прямое изменение переменных (и защищать их мьютексами).

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

Цитата:

Shared memory vs. message passing. Our study found
that message passing does not necessarily make multithreaded programs less error-prone than shared memory.
In fact, message passing is the main cause of blocking bugs.
To make it worse, when combined with traditional synchronization primitives or with other new language features
and libraries, message passing can cause blocking bugs that
are very hard to detect.
...
We believe that message
passing offers a clean form of inter-thread communication
and can be useful in passing data and signals. But they are
only useful if used correctly, which requires programmers
to not only understand message passing mechanisms well
but also other synchronization mechanisms of Go.

Наткнулся на забавную статью "ну почему экосистема фронтенда настолько сложна?"

Я и сам много раз задавался этим вопросом. Я бы даже переформулировал так: "Интересно, почему именно фронтенд настолько усложнился"

Краткий пересказ статьи:

Нет единой системы импортов. ESModules, CommonJS, Asynchronous Module Definition (AMD), Universal Module Definition (UMD)

Многочисленные шаги минификации, траспиляции, uglification (уродования)

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

Множество фронтенд-инструментов полагаются на определенную структуру файлов в проекте, поэтому, например, в корне проекта лежат всевозможные tailwind.config.js, postcss.config.js, eslint.config.js, next.config.js и т.д.

Configuration hell. Огромное количество инструментов, которые нужно как-то поженить между собой. И если на шаг отойти от create-react-app, то столкнешься с адом взаимодействия десятков штуковин.

Из-за множества слоёв преобразования затруднён hot reload.

Напишите в коментах, почему так, зашто и куда всё это движется

В Go был принят proposal, добавляющий в стандартную библиотеку языка улучшенный http-роутер, чем-то похожий на gorilla/mux. Потому что тот, что уже сейчас есть в Go, дает только самые базовые возможности и в реальной жизни не особо применим.

В статье говорится, что его можно ждать уже в 1.22.

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

Рефакторинг старого кода (со звуком)
----
Cross Join - канал о разработке, подпишись

Из книги про Ruby, это ппц :)) Кстати, одна из причин, почему люди идут из разных языков в Go - там мозг вообще не надо подключать

(картинка взята из канала программистика)

Удивительно!

Не прошло и 100500 лет, как вышел pgbouncer 1.21, который научился обрабатывать prepared statements.

Пусть немного странновато реализовано и на синей изоленте, но всё же это прям биг дил

--------
Cross Join - канал о разработке, подпишись

Послушал фоном доклад, в котором анализируется, почему в языке Go (да, я опять про го :)) никто не юзает ORM.

Мой вывод такой, что в Go так просто сложилось (где-то треть народу даже никогда не пробовали ORM в Go, тупо делают как все). При этом запихать данные из селекта в струкутуру можно с помощью, например, jmoiron/sqlx:

people := []Person{}
    db.Select(&people, "SELECT * FROM person ORDER BY first_name ASC")

, а сбилдить запрос из частей по условиям (например, это может быть нужно при обработки формы фильтрации данных), но не юзать небезопасную конкатенацию, можно через squrrel


u

sers := sq.Select("*").From("users").Join("emails USING (email_id)")
active := users.Where(sq.Eq{"deleted_at": nil})
sql, args, err := active.ToSql()

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

Интересно, конечно, что в разных языках по-разному, в Руби, как я понимаю, работают с ORM чуть ли не 100%

Наброс в порядке бреда. Философский вопрос.

Что если взять условную штуку типа нейролинка Маска, вживить ее новорожденному, чтобы с рождения (или даже раньше) записывать всё, что входит и выходит из мозга, все сигналы. И так лет 20. На этих сигналах обучить адскую нейросеть на много-много слоёв. На выходе получим электронный мозг а-ля человеческий или нет?

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

Потом вырастить так одного "учёного", клонировать его миллион раз и моментально перейти к сингулярности.

"80% руководителей в США сожалеют о решении вернуть сотрудников в офисы"

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

Еще про ORM

Интерсную мысль нашел в статье. tldr: когда ORM используется за рамками CRUD, то он начинает только мешать, а за рамками CRUD находится большинство приложений.

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

В итоге при использовании ORM обычно получается что-то вроде проектирования своей бд прямо в коде (сущности и их взаимосвязи), и борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Язык запросов в виде цепочки объектов и методов читается хуже, чем SQL, по сути это особый язык, который надо учить. За себя скажу, что когда писал на PHP (Laravel), длинные запросы на Eloquent меня иногда изумляли своей сложностью чтения.

В итоге, кстати, некоторые производители ORM даже пытаются прикрутить свой собственный абстрактный недоSQL на объектах бизнес логики, например как в DOCTRINE:

```

php

$query = $em->createQuery('SELECT u FROM Doctrine\Tests\Models\Company\CompanyPerson u 

WHERE u INSTANCE OF Doctrine\Tests\Models\Company\CompanyEmployee');

```

или Hibernate:

 java

IQuery q = s.CreateQuery("from foo in class Foo where foo.Name=:Name and foo.Size=:Size");

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

Есть еще такое мнение, что ORM - это как слой, абстрагирующий от способа хранения. Типа, сегодня ты пишешь на MySQL, завтра на Postgres, после завтра вообще в файлах хранишь - и тебе пофиг, код остаётся тем же. Чистая архитектура.

Ну это вообще хрень, конечно. Уродовать код и замедлять разработку, чтобы с вероятностью 0.01% захотеть переехать на другую базу - ну такое.

Про чистоту архитектуры тоже можно вставить 5 копеек, чтобы два раза не вставать. Очень часто слои пересекаются. Ты как ни крути, но делать абсолютно 100% независимый слой бизнес-логики (юзкейсы, сервисы) - это иногда бывает очень дорого. Например, если тебе надо построить хитрый отчет, ты будешь использовать SQL с группировками, оконными функциями, фильтрами и джойнами, выжимая из базы данных всё, что можно, включая хаки. Там будет не до абстракций. Да просто сделать group by и посчитать количество тех, у кого count больше одного - это ведь уже бизнес-логика в SQL.

НО

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

Тем, кто изучает Go, советую посмотреть два видоса Николая Тузова. Николай на видео пишет приложение полностью, от начала и до конца, так как он это делал бы на работе, включая логи, тесты и прочие нюансы. Т.е. очень полезно тем, кто знает основы языка, но в целом немного потерялся и не понимает, как всё это использовать в реальности. Видосы капец длинные, по 3 часа (я предупредил)

https://www.youtube.com/watch?v=rCJvW2xgnk0 - REST API сервис на Go
https://www.youtube.com/watch?v=EURjTg5fw-E - gRPC сервис на Go

Максимально подробно и практично.