Деды писали код

Public

Просмотреть канал

Не можете присоединиться? @deadcode0x

299 Участники

Обновлено: May 25, 2026 at 5:55 AM

Деды писали код

Регулярные советы по программированию от старшего поколения. Об авторе: программировал за деньги, когда ЭВМ были большими, а операционки — маленькими. https://deadcode.dev/ 💡у ссылки означает: на вебе тема раскрыта подробнее.

@deadcode0x is a dedicated channel for httpsdeadcodedev with regular updates in Кодинг и программирование

Рейтинг

Глобальный рейтинг

#20893

-2023

Рейтинг по языку

#15906

-1764

Рейтинг по категории

#97

-11

Рост участников (Последние 30 дней)

Всего: 299

Рост за 24ч: +0 0%

Последние посты

Деды писали код

17 мар. 2026 г., 21:10

pinned «Нам нужно поговорить. @deadcode1x»

Деды писали код

17 мар. 2026 г., 21:10

Даты обновлений в таблицах

Хорошей привычкой при проектировании баз данных должна стать привычка добавлять поля createdAt и updatedAt к (почти) любой таблице и обновлять их соответственно при создании и при апдейте. Хорошие ORM это делают сами, но даже и без ORM важно чтобы эти данные у тебя были. Стоимость их хранения копеечная, а иной раз они крайне, крайне полезны. Не стесняйся показывать их пользователю.

Подводный камень с этими полями: updatedAt с точки зрения пользователя и с точки зрения системы — это разные даты. Системное время обновления — это когда и в самом деле запись поменялась в самой базе. Пользовательское время — это когда конкретно сам пользователь внес изменения. Человек часто по этим датам ориентируется.

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

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

https://deadcode.dev/303/

879

Деды писали код

17 мар. 2026 г., 21:10

📷 Photo

Код не для исполнения

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

Например, у меня есть разветвистый if .. else if .. else if ... В конце каждой ветки стоит почти одинаковый вызов. И вот в одной из веток его нет, а логика очень похожа. И чтобы мой коллега как-нибудь не заметил эту очевидную проблему и не скопировал туда строчку — это сделал я сам.

Если бы я не написал этой строчки this.$bus.$emit(), то рано или поздно она была бы кем-то сюда внесена, потому что везде же она есть.

https://deadcode.dev/296/

877

Деды писали код

17 мар. 2026 г., 21:10

📷 Photo

Возврат неуспешного результата из функции в JS

if (stat(filename) == -1) {

Такой код прижился только в C. В скриптовых языках не следует возвращать -1 как признак (не)успешного выполнения. Канонически правильного способа вернуть ошибку толком и нет; сишный errno — это костыль.

В JavaScript нужно просто договориться с собой, что ты возвращаешь из функции структуру:


return {
success: true,
user: {
id: ...
}
}


• избавься от проверки типа значения как признака. Никаких const count = returnCount() и затем if (count === null);
• если метод возвращает success-структуру, то в результате всегда присутствует ключ success. Не нужно его опускать, полагаясь на то, что в этом случае result.success == false;
• если метод возвращает success-структуру, то он не имеет права вернуть null;
• если ты используешь сишный паттерн, модифицируя переданный в функцию хеш, то четко укажи это в названии: parseUserAndAugmentWithIds(user = {});

Еще можно делать так, как на картинке.

https://deadcode.dev/302/ 💡

704

Деды писали код

17 мар. 2026 г., 21:10

Нам нужно поговорить.

https://t.me/deadcode1x

686

Деды писали код

17 мар. 2026 г., 21:10

/health/ check

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

А правильно вот так. Мониторилка должна приходить на URL, специально подготовленный для нее (/health/). Там ты проверяешь:

• в порядке ли коннект к базе (SELECT 1)
• в порядке ли memcached/redis/etc (.set(), затем .get())
• в порядке ли погода (loadavg, достаточно ли свободной памяти и т.п.)
• и т.д.

Проверки выполняешь последовательно, и в случае ошибки выдаешь ее в теле со статусом HTTP 500. Так в случае аварии ты сразу узнаешь, кто сломался (конечно, если твой сервис само тело ответа показывает).

Важно: пользуйся существующими коннектами к базам. Что толку с того, что твой health check покажет, что к базе можно успешно открыть новое соединение, когда у тебя рабочие соединения мертвые и веб не работает?

И только если все хорошо, тогда говори HTTP 200. https://deadcode.dev/151/ (нулевой).

https://deadcode.dev/290/

724

Деды писали код

17 мар. 2026 г., 21:10

Есть два сервера

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

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

Тем не менее, я регулярно вижу, как ребята поднимают memcached на одном сервере; затем, когда они его апгрейдят — у них каскадно падает вся инфраструктура. Причем каскадно и причем вся.

Поэтому: вместо одной виртуалки за $30 лучше подними две по $15.

%АНЕКДОТ_ПРО_ДВУХ_ЖЕН_ПО_20_ЛЕТ%

https://deadcode.dev/293/

682

Деды писали код

17 мар. 2026 г., 21:10

Есть два крона

Простой кейс: твой сервис https://deadcode.dev/293/ и у тебя есть задача, которую нужно по cron'у выполнять каждую минуту, например, разбирать очередь задач. Или чистить внешний сторадж. Как разделить таски так, чтобы сервера между собой не дрались?

Есть очень простой хак.

В одном кроне запускаешь свою задачу с ключем --odd, в другом с ключом --even. В самом же коде проверяешь номер задачи (или что угодно). Если он четный и тебе сказали --even — выполняешь, иначе — пропускаешь. И наоборот, скрипт с ключом --odd выполняет только нечетные задачи. Еще так можно по-быстрому распределить большие работы между серверами в одноразовых скриптах.

Easy!

PS: Мнемоническое правило, как запомнить что even — это четное, а odd — нечетное: в слове even — четное количество букв.

https://deadcode.dev/295/

777

Деды писали код

17 мар. 2026 г., 21:10

📷 Photo

Атомарная выборка только одной записи

Представь простую очередь задач в SQL. У каждой есть уникальный ID, поле статуса (новая, в работе, закончена) и данные. Представь себе, что очередь у тебя разбирают несколько серверов.

Как сделать так, чтобы одну задачу забирал только один сервер?

На помощь приходит SELECT ... FOR UPDATE.

Как только SQL сервер получает запрос на выборку FOR UPDATE, он никому другому больше не отдаст эту запись, пока ты не закроешь транзакцию.

Кстати, организовывать очередь на SQL нужно аккуратно. Природа ее нагрузки такова, что очередь — небольшая, а SQL — уже задыхается. Не для очередей его взращивали.

https://deadcode.dev/257/

792

Деды писали код

17 мар. 2026 г., 21:10

📷 Photo

Как принимать платежные уведомления

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

Как правильно принимать эти IPN:

Это должен быть отдельный http сервер (или .php), со своим конфигом, не использующий общий код проекта. Все, что должен делать этот скрипт — записать сырые данные платежного уведомления в базу и сказать HTTP 200 OK. И все, ничего больше!

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

Не надо пытаться парсить эти данные. Ты можешь сломаться.

Нельзя использовать общий код проекта. Там может быть ошибка. И рестартить не надо будет.

А вот парсить их можно https://deadcode.dev/257/.

https://deadcode.dev/281/

701

Showing 10 of 10 posts

No more posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

Деды писали код

Деды писали код

Рейтинг

Рост участников (Последние 30 дней)

Последние посты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

Albinasummer

PM работа. Проектные менеджеры

Русский Модный Код

Литературный коД

Компьютерная математика Weekly

AI Projects

ReLab Family

Книги по программированию

Похожие каналы Telegram

Albinasummer

PM работа. Проектные менеджеры

Русский Модный Код

Литературный коД

Компьютерная математика Weekly

AI Projects

ReLab Family

Книги по программированию

Отзывы пользователей (0)

Последние посты