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

Description
Регулярные советы по программированию от старшего поколения.

Об авторе: программировал за деньги, когда ЭВМ были большими, а операционки — маленькими.

https://deadcode.dev/

💡у ссылки означает: на вебе тема раскрыта подробнее.
Advertising
We recommend to visit
HAYZON
HAYZON
6,299,082 @hayzonn

💼 How to create capital and increase it using cryptocurrency

👤 𝐅𝐨𝐮𝐧𝐝𝐞𝐫: @Tg_Syprion
🗓 ᴀᴅᴠᴇʀᴛɪsɪɴɢ: @SEO_Fam
Мои каналы: @mazzafam

Last updated 7 hours ago

Канал для поиска исполнителей для разных задач и организации мини конкурсов

Last updated 1 week, 3 days ago

Новые и перспективные Web3 игры с добычей токенов.

Чат: https://t.me/Crypto_Wolf_Chat

Правила чата смотрите в описании чата.

Все свои вопросы направляйте в чат или главному модератору чата: @Exudna_118

По теме сотрудничества: @Zombini

Last updated 2 months, 3 weeks ago

4 years, 2 months ago

С праздником, дорогие коллеги! ❤️

4 years, 4 months ago

Монетарные значения должны быть целочисленными
Как известно, 0.2 + 0.1 = 0.30000000000000004. Казалось бы, можно округлить да и дело с концом. Но нет: НДС от суммы в счете и сумма НДСов счета запросто могут отличаться за счет ошибок округления.

Поэтому все денежные единицы стоит хранить и исчислять в целом количестве копеек и конвертировать в дробные доллары только на этапе показа пользователю. В базах это BIGINT. В js я делаю просто const amountHr = Math.floor(amount/100).toFixed(2).

С Satoshi посложнее, конечно.

https://deadcode.dev/323/

4 years, 5 months ago

Плавно вводи ресурсы в эксплуатацию
Допустим, у тебя система хранения с линейным масштабированием. Добавил новый сервер — расширилось место.

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

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

https://deadcode.dev/320/

4 years, 5 months ago

Создавай хелперы для межмодельного кода
Вот есть пользователь (User), вот есть купоны на скидки (PromoCode). Тебе нужно применить одно к другому.

Где разместить этот код?

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

В модели купона? Неправильно, ведь этот код изменяет только данные пользователя и ничьи больше.

Выход? Создай класс PromoCodeToUserApplyController. Пусть даже там будет всего пара методов, зато точно понятно, зачем этот класс и к чему он относится. Поверь, он разрастется.

А если метод только один, то назови класс PromoCodeToUserApplyHelper. И, кстати, хорошо в объектно-ориентированном проекте избавиться он голых функций и все вынести в классы. Да, многие тебе скажут что так делать не надо, но они имеют в виду другое. Плохой тон не в том чтобы избегать классов там, где достаточно функции; плохой тон — плодить бессмысленные классы. То есть классы, название которых не отражает их суть. Я за то, чтобы было много всяких разных изолированных сущностей и много методов, и у каждого — свое понятное название. Тогда код легко читается.

https://deadcode.dev/318/

4 years, 5 months ago

Fallback в коде: что, если не получилось?

Если в коде что-то не получилось (нет ответа от базы, API недоступен, платеж не прошел и т.д.) то важно предусмотреть правильное конструктивное поведение.

Пример из жизни (слегка упрощенный, конечно). Приложение при запуске делает запрос домой и спрашивает, оплатил ли пользователь подписку на ZZZ. Что делать приложению, если не удалось достучаться к серверам, или ответ некорректен? Скажем, прошло десять лет, компания закрылась, а домен ушел к порносайту.

Давать доступ к ZZZ.

Потому что не давать было бы деструктивным действием — у пользователя бы пропала важная для бизнеса функция и он бы страдал по нашей вине.

https://deadcode.dev/313/

4 years, 5 months ago

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

Поэтому я считаю, что есть два подхода к exceptions.

Первый: ловить как можно ближе к источнику. Оборачивай свое обращение к файлу в try { } catch и считай, что в catch у тебя просто ветка ошибки чтения файла. Грубо говоря, это просто такой синтаксис: try { read(); } catch { } вместо if (!read()) { }. Это еще можно пережить. Например, в современном JavaScript они стали официальным методом получения ошибки из Promise (async/await).

Второй: лови как можно выше и умирай. Считаем, что exception, который произошел выше нижайшего уровня (первый случай) — это катастрофа. Его нужно ловить лишь для того, чтобы умереть с достоинством (сообщить об ошибке и не зависнуть).

Не надо использовать exception как инструмент для возврата ошибки! Соблазн высок: вместо протаскивания какой-то информации об ошибке всю пачку вызовов на самый верх (сложно!) — просто кинули exception и типа где-то поймали (просто). Нельзя! Через некоторое время ты перестанешь понимать ветвление собственного кода, запутаешься в ресурсах, которые нужно освбождать, ну а вся борьба с memory leaks на этом и вовсе заканчивается.

https://deadcode.dev/309/

4 years, 5 months ago

А кстати,

вместо нулевого Content-Length можно отдавать HTTP статус 204.

Совет без номера потому что.

4 years, 6 months ago

Стоит ли автоматизировать эту задачу?
Есть простой способ узнать ответ на этот вопрос.

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

Пример. У нас в проекте есть партнерская программа для узкого круга элитных участников. Выплаты делаются каждые два-три месяца, участников меньше десяти. Выплачивать вручную одному участнику: минута. Накладные расходы на цикл выплаты: 10 минут (кофе, открыть excel, открыть paypal, etc). 10 участников × 1 минуту × 4 раза в год + 10 накладных минут × 4 раза в год = почти 2.5 часа. На поддержку докинули 1 час на год, потому что каждая выплата сделана человеком и он в контексте.

Разработать код автоматической выплаты посчитали минимально в 12 идеальных часов: код выплаты, код учета, код показывания чека, админка для суппорта, UI для юзера, очередь запросов на выплату и т.д. Поддержку пользователей по автоматической выплате прикинули на год в 3 часа, потому что по каждой нужно будет разбираться, почему было столько.

Итого: 3.5 часа против 15 часов.

Эту задачу автоматизировать точно не стоит.

https://deadcode.dev/306/

We recommend to visit
HAYZON
HAYZON
6,299,082 @hayzonn

💼 How to create capital and increase it using cryptocurrency

👤 𝐅𝐨𝐮𝐧𝐝𝐞𝐫: @Tg_Syprion
🗓 ᴀᴅᴠᴇʀᴛɪsɪɴɢ: @SEO_Fam
Мои каналы: @mazzafam

Last updated 7 hours ago

Канал для поиска исполнителей для разных задач и организации мини конкурсов

Last updated 1 week, 3 days ago

Новые и перспективные Web3 игры с добычей токенов.

Чат: https://t.me/Crypto_Wolf_Chat

Правила чата смотрите в описании чата.

Все свои вопросы направляйте в чат или главному модератору чата: @Exudna_118

По теме сотрудничества: @Zombini

Last updated 2 months, 3 weeks ago