В некоторых БД буквально сотни зарезервированных слов (еще есть и списки слов которые возможно будут зарезервированы), например в MS-SQL слово user является зарезервированным, поэтому надо писать select u.id from dbo.[user] as u, использование множественного числа для названий таблиц буквально сводит такие неудобства к 0.
Если добавить что для многих приложений со временем встает необходимость поддержки нескольких БД или как сейчас массовый переход с Oracle и MS-SQL, все еще сложнее становиться.
Обычно БД и данные живут дольше чем клиентский софт, django и orm тут очень частная вещь...
Для MS-SQL полностью поддерживаю множественное число для таблиц, чтобы потом не надо было постоянно [] писать, если что ORM эти символы тоже пишут зачастую
Помню писал небольшую утилиту с этой технологией от MS, она диаграммы C4 сначала проверяла, потом добавлял возможность генерации C4, сейчас наверное менее актуальная тема, везде сплошные ИИ технологии все заменяют постепенно.
Если принципы в манифесте не устраивают это просто непонимание или недостаток опыта в разработке или неверная понимание написанного
Принципы общие, они не учитывают контекст продукта и квалификацию команд
Общие принципы трудно написать
Писать, что мол частые поставки вредны - тут просто надо итерационно простыми шагами поставлять, для части продуктов это жизненно необходимо, насколько я помню авторы писали принципы для традиционных корпоративных приложений, там можно поставлять часто.
Я лично мог каждые 15-30 минут поставлять - но я сидел недалеко от пользователей и общался лично
connection.fetch(query, args) -> result - норм тема, особенно если в query вызов хранимки, надо что-то похожее на универсальные хранимки до уровня БД, пока идея ждет своего героя.
Используется, переписывал на одном месте работы методы API с Delphi на C#, в основном благодаря Net.Core код практически уходит, становиться в разы меньше и проще. Хотя методы API на Delphi немного быстрее работали :)
Можно еще по более простым признакам определить, если компания небольшая и частенько вывешивает одинаковые вакансии, скорее всего там текучка (из личного опыта).
Если у вас опыт 18 лет, а с вами связывается тупая HR девочка, компания видимо деревянная, такая работа не подойдет, если вы нацелены на результат или цените свое время, ненавидите бюрократию и т.д.
Если компания не профильная, например строительная, готовьтесь в большинстве случаев стать на уровне охранников и уборщиц. Хотя задачки бывают интересные и больше свободы в техническом плане (меньше документации и неприятной рутины).
Есть некий KPI по разработчикам, тут вообще может быть конская система мотивации, будете с коллегами пахать от звонка до звонка, код как правило плохой (все нацелены только на выполнение своих задач). Под конец месяца аврал, все будут спешить свои задачи сдать.
Просят списывать по 8 частов в день на задачи, уже не реально...
Contragents, Cols: Addr1, Addr2, Phone, MobilePhone - ну это уж точно широкая таблица.
По поводу широких таблиц думаю в считанных приложения это оправдывает себя, просто просчет вполне дешевой альтернативы в виде нормальной формы обычно не делается для большинства приложений.
В некоторых БД буквально сотни зарезервированных слов (еще есть и списки слов которые возможно будут зарезервированы), например в MS-SQL слово user является зарезервированным, поэтому надо писать select u.id from dbo.[user] as u, использование множественного числа для названий таблиц буквально сводит такие неудобства к 0.
Если добавить что для многих приложений со временем встает необходимость поддержки нескольких БД или как сейчас массовый переход с Oracle и MS-SQL, все еще сложнее становиться.
Обычно БД и данные живут дольше чем клиентский софт, django и orm тут очень частная вещь...
Для MS-SQL полностью поддерживаю множественное число для таблиц, чтобы потом не надо было постоянно [] писать, если что ORM эти символы тоже пишут зачастую
Мне в целом понравилась статья, на каждый пункт даны объяснения, тоже подобное что-то писал про базы данных https://habr.com/ru/articles/774154/
Соглашусь с большинством пунктов, понятно что бывают исключения, тут хоть как пиши статю все равно накидают )
Все зависит от контекста, автор по некоторым пунктам перегнул конечно, типа создания индексов по условиями фильтрации
Универсального подхода не бывает, многое зависит от контекста, решаемых задачи и под-задач.
Помню писал небольшую утилиту с этой технологией от MS, она диаграммы C4 сначала проверяла, потом добавлял возможность генерации C4, сейчас наверное менее актуальная тема, везде сплошные ИИ технологии все заменяют постепенно.
Ссылка не работает
На C# код тестов тоже можно писать лаконично и компактно
Побуду сексистом, но лучше парней в таком ракурсе в посты не добавлять
Если принципы в манифесте не устраивают это просто непонимание или недостаток опыта в разработке или неверная понимание написанного
Принципы общие, они не учитывают контекст продукта и квалификацию команд
Общие принципы трудно написать
Писать, что мол частые поставки вредны - тут просто надо итерационно простыми шагами поставлять, для части продуктов это жизненно необходимо, насколько я помню авторы писали принципы для традиционных корпоративных приложений, там можно поставлять часто.
Я лично мог каждые 15-30 минут поставлять - но я сидел недалеко от пользователей и общался лично
connection.fetch(query, args) -> result - норм тема, особенно если в query вызов хранимки, надо что-то похожее на универсальные хранимки до уровня БД, пока идея ждет своего героя.Мне лично статья на Хабре помогла относительно просто пройти собеседования, без выноса мозга. Ссылки на свои статьи добавляю в резюме.
Тоже не понял, сначала подумал что-то более крутое, а так похоже на EAV просто ребрендинг
Норм так, добавлю в свою рисовалку схем (так раз на очереди подобные фичи) https://pikabu.ru/story/razrabatyivayu_utilitu_dlya_formirovaniya_skhem_baz_dannyikh_11202567
Используется, переписывал на одном месте работы методы API с Delphi на C#, в основном благодаря Net.Core код практически уходит, становиться в разы меньше и проще. Хотя методы API на Delphi немного быстрее работали :)
Можешь ссылку дать?
Можно еще по более простым признакам определить, если компания небольшая и частенько вывешивает одинаковые вакансии, скорее всего там текучка (из личного опыта).
Если у вас опыт 18 лет, а с вами связывается тупая HR девочка, компания видимо деревянная, такая работа не подойдет, если вы нацелены на результат или цените свое время, ненавидите бюрократию и т.д.
Если компания не профильная, например строительная, готовьтесь в большинстве случаев стать на уровне охранников и уборщиц. Хотя задачки бывают интересные и больше свободы в техническом плане (меньше документации и неприятной рутины).
Есть некий KPI по разработчикам, тут вообще может быть конская система мотивации, будете с коллегами пахать от звонка до звонка, код как правило плохой (все нацелены только на выполнение своих задач). Под конец месяца аврал, все будут спешить свои задачи сдать.
Просят списывать по 8 частов в день на задачи, уже не реально...
Чтобы не потерять данные :) Подробнее можно почитать в данной статье https://habr.com/ru/companies/dataline/articles/329046/
Предлагаю совместно над второй редакцией поработать :)
Предлагаю совместно над второй редакцией поработать :)
Contragents, Cols: Addr1, Addr2, Phone, MobilePhone - ну это уж точно широкая таблица.
По поводу широких таблиц думаю в считанных приложения это оправдывает себя, просто просчет вполне дешевой альтернативы в виде нормальной формы обычно не делается для большинства приложений.
Если полностью раскрывать все вопросы, то это уже целая книга будет :) На это я пойти не готов (пока).