Просто пусть полежит здесь.
Некогда для своего же удобства был написан мини пошаговый db для bash. Просто красивый вывод исполняемой строки с глубиной вложения и с возможностью продолжения по нажатию клавиши.
Так бывает, когда привыкаешь к стилю, который уже за десяток лет отточен до мелочей, а тим-лид или ещё кто-то там из молодых-зелёных авторитарно ставит условия, потому что это меинстрим, «бэстпрактис» и прочая ерунда, которая сильно расходится с именно вашими «бэстпрактис» за годы.
> 6. Зависимости стоит использовать тогда, когда они нужны
Пакетоманьяки. Ради какого-то дополнения строки слева или использования конкурентных фьючерсов/промисов готовы ставить 11-строчные библиотеки на каждый чих, вместо написания алгоритма просто у себя в отдельном файле. Если так хочется готовый код, то возьми и скопируй его себе без зависимости. Но городить милионные зависимости просто потому что «так правильно бэст практис чувак» — это есть безумие.
> 7. Не нужно писать абстракции до тех пор, пока в этом не возникнет реальная необходимость
Да за неиспользования DRY, GRASP, GoF и прочего иногда вас готовы сжечь уже прямо на собеседовании.
Думал, может у вас есть какое-то секретное приложение на телефон, умеющее считывать артикулы с описаниями в чеках и переводящее всё в человеческие записи в бд.
У меня вопрос к ресурсу: как вы умудряетесь сохранять каждую трату? Меня, например, очень напрягает вносить длиннющие чеки. Куда вы вносите траты, которые не хотите отображать в отчёте?
Для большинства проблем, с которыми вы пытаетесь справиться, существуют готовые решения. Поэтому, когда вы пытаетесь выполнить задачу, проверьте, не выполнял ли ее кто-нибудь другой. В данном случае вы не срезаете углы, вы срезаете усилия.
Как верный, так и вредный совет. Некоторые решения хоть и популярные с милионными «звёздочек», но настолько громоздкие и отсталые в технологическом плане, что проще и правильнее написать с нуля нечто маленькое, но выполняющее свою задачу. Так даже проще в отладке.
Если у вас отсутствует комиссия за снятие наличных, значит вы её уже заплатили тем или иным способом (чаще, при зачислении на счёт банка, в котором вы снимаете деньги).
Очень интересен процесс апдейта схем БД. Пусть есть app1 работающая на scheme1 и app2, которая работает на scheme2 без обратной совместимости со scheme1 (пускай добавлена новая таблица, требуемая в app2). Как это вот всё на 85тысячах машин одновременно разворачивается и как паузится работа всей банковской системы?
Неплохо. Всё хорошо идёт до того момента, пока вы не сталкиваетесь с дебагом внутри воркера. Попробуйте отладить воркер, который создаётся на основе функции из текущего скрипта.
new Blob(....)
new Worker(URL.createObjectURL(blob));
Некогда для своего же удобства был написан мини пошаговый db для bash. Просто красивый вывод исполняемой строки с глубиной вложения и с возможностью продолжения по нажатию клавиши.
могло включаться в любом месте файла, который надо отладить просто добавлением DEBUG_BY_LINE=1
Пакетоманьяки. Ради какого-то дополнения строки слева или использования конкурентных фьючерсов/промисов готовы ставить 11-строчные библиотеки на каждый чих, вместо написания алгоритма просто у себя в отдельном файле. Если так хочется готовый код, то возьми и скопируй его себе без зависимости. Но городить милионные зависимости просто потому что «так правильно бэст практис чувак» — это есть безумие.
> 7. Не нужно писать абстракции до тех пор, пока в этом не возникнет реальная необходимость
Да за неиспользования DRY, GRASP, GoF и прочего иногда вас готовы сжечь уже прямо на собеседовании.
Как верный, так и вредный совет. Некоторые решения хоть и популярные с милионными «звёздочек», но настолько громоздкие и отсталые в технологическом плане, что проще и правильнее написать с нуля нечто маленькое, но выполняющее свою задачу. Так даже проще в отладке.