Вы сейчас передёргиваете. Я говорил, что код пишется для человека, а не для машины. Обоснование я тоже дал - код читается гораздо чаще, чем пишется.
С чем вы хотите поспорить? С тем что код чаще читается, чем пишется? Ну удачи.
Что значит "для бизнеса"? Не для бизнеса.
Я так тоже могу упростить до крайностей, смотрите: Бизнесу нет дела до кода, бизнес делает деньги. И всё, что ему нужно - это деньги. Код ему не нужен. Код - это вообще-то затраты на поддержку, а бизнес затраты не любит. Вывод: бизнес должен избегать написание кода.
Нет метрик этой читаемости, увы.
Да всмысле? Вот же сами пишете:
Что вот можно взять нового сотрудника и он разберется, что в этих строчках происходит? Или за несколько минут/часов сможет найти баг в незнакомо проекте?
Именно так. Вот тот самый пресловутый wtf/min. Есть ещё kloc, глубина наследования, связность классов.
Если вы не можете применить метрики прямо сейчас к проекту, это не значит, что их нет. Они есть. Но в силу уникальности каждого решения очень сложно делать общие метрики, которые уже где-то на таком же решении обкатаны.
Если вам нужно взять тысячу джунов и проверить время вкатывания на одном проекте и на другом, но с разной архитектурой, то не говорите, что это невозможно сделать. У вас просто денег нет на такие исследования.
Вы можете сказать
Не надо за меня говорить, что я могу сказать. Пожалуйста.
И тем более, приравнивать читаемость к каким-то абстрактным практикам. Я выбрал термин "читаемость" и я на нём настаиваю. Я не имел в виду религиозное соблюдение солида или что-то в этом роде. Я говорил про читаемость. Про понятность.
Нет. Написать работающий код любой дурак может. Машина простит любой хаос в оформлении и любые названия переменных.
Код пишется людьми и для людей, и первая задача кода - быть понятным. Потому что код гораздо чаще читается, чем пишется.
Читаемость кода - это не лирика и не демагогия, как вам показалось. Технический долг - это не страшилки программеров. Он реально существует и способен похоронить под своей тяжестью любой проект.
Понятный код способен ускорить на порядок разработку и снизить на порядок стоимость поддержки проекта. Чем больше проект - тем сильнее влияние читаемости.
Работа программиста - это не написание кода. Это управление сложностью конструкции. И ООП - это один из главных инструментов в этом деле. Как любой инструмент, у него есть некий порог полезности, ниже которого накладные расходы на внедрение инструмента не дают выгоды, для себя я оцениваю этот порог в 300-500 строк, то есть дальше крохотного скрипта ООП почти всегда упрощает восприятие кода и сокращает расходы на поддержку.
Я сейчас наговорил кучу банальных вещей, простите.
Не понимаю, как рейки могли придать этой конструкции устойчивость. В моём понимании у этой конструкции поперечный разброд и шатание никуда не делись, тут из вариантов только слева к стенке прислонять и прижимать шкафом справа.
Для устранения такого шатания необходима поперечина вдоль всей задней стенки высотой сантиметров 20 хотя бы. И не с самого верха, а с отступом тоже см 20.
Меня в этой конструкции очень, нет ОЧЕНЬ смущает плечо рычага по горизонтали - расстояние между центрами двух крайних креплений и центральным. Автор на этом же плясать собрался? Вот когда нагрузка направлена строго вниз - всё хорошо. Как только усилие получает сколь-нибудь значительное отклонение влево и вправо, то сразу усиливается этим рычагом. Мультипликатор - высота ножки. То есть, этот саморез вырывает с мясом, стол складывается как карточный домик, автор получает ЧМТ и больше не пляшет.
Я ожидал, что в примерах будет что-то вроде Raft, Valheim или даже Project Zomboid. Принц персии и борда - это зашейдеренные аутлайном довольно сложные модели.
Я сегодня пробовал нагопотить сайт-одностраничку. Сам я в современную вёрстку не умею, а древнюю забыл, поэтому решил отдать на аутсорс. Сначала всё шло хорошо, гопота собрала годный шаблон. Но по мере правок её сознание уплывало всё дальше куда-то в туманную даль. Вот я третий раз попросил вернуть прайс как было, убрать стописят баксов и вернуть зачёркнутые 100:
Она врёт. Нагло, беззастенчиво, в глаза. Но это не самое важное. Самое важное, что начинает терять контекст и переписывать то, о чём давно в нескольких итерациях договорились. Она не может удержать контекст даже маленькой странички. Она не может настроить блоки, чтобы был читаемый текст с достаточной контрастностью. И это простой веб.
В программирование я LLM даже близко не подпущу, там сложность на несколько порядков больше. А последствия бардака на порядок больнее.
Насчет поддержки актуальности, да, проще всего вносить изменения только в модель, остальное перегенерировать
А по-другому никак... Потому что всегда нужно хранить дополнительные параметры модели, которых нет ни в БД, ни в коде. Притом разрабы работают в разных окружениях (тест, дев, прод) и могут менять модель под свою задачу, а потом это всё надо мержить вместе с кодом, чтобы и тот и тот PR заработал в другом окружении.
И да, всё правильно, нужно делать не пересоздание структуры БД, а изменение. У меня этот механизм называется DDL diff. Состояние БД сравнивается с моделью и генерируется DDL, который приводит БД к состоянию модели. Не напрямую, конечно, с выбором и вычиткой DDL. Это всё довольно сложные механизмы, требующие знаний в механике баз данных.
Тут ещё есть один краеугольный камень - удобство. Это уже больше из области психологии, но всё же. Если разрабам неудобно напрямую в таком редакторе менять структуру - хоть что делай, они будут работать в другом инструменте, и иногда синхронизировать модель. Наверное. Но это не точно.
Обратная задача (reverse engineering — создание или обновление модели по коду) может быть уже немного сложнее, хотя в принципе тоже имеет право на существование. Особенно если есть legacy‑проект, где просто база данных, код и нет никаких моделей
Как раз такой проблемы нет. В случае, если приложение уже умеет генерировать DDL diff. Если есть база данных, то можно прочитать её структуру и создать модель. Механизм всё тот же самый. Конечно, с кодом нужно будет повозиться, особенно если запросы раскиданы по всей кодобазе и особенно, если не использовался ORM. Но это в любом случае надо делать, чтобы понимать, какие части модели действительно используются в коде.
Первая проблема при создании такого рода инструмента - это поддержка актуальности. Поэтому я рассматривал подход model-first, когда модель данных создаётся и редактируется в отдельном приложении, и затем уже синхронизируется с БД и кодом.
Собственно, я такое приложение и разрабатываю. Это что-то вроде dbSchema, но есть возможность передавать всю структуру данных в python-скрипт, который уже в нужном языке сгенерирует нужный код. У каждого свои потребности, поэтому я решил именно так сделать.
При растущей мировой экономике другим странам нужно всё больше и больше долларов, чтобы расплачиваться друг с другом. Эта эмиссия может запросто перекрыть (и перекрывает) дисбаланс и делать с этим ничего не нужно. Уж точно не так, как делает Трамп. Он просто угробит сложившиеся отрасли и если у него что-то получится, то это откат экономики США к индустриальной модели.
Да, США получается бенифициар растущей экономики. За счёт стабильности своей валюты, за счёт глобальности экономики и устойчивости государственных бумаг. Они могут просто "напечатать" новые доллары для покрытия дефицита и всем будет хорошо. "Напечатать" я взял в кавычки, потому что фрс так просто не даст денег государству потому что "надо". Там довольно сложная система.
Хорошо, согласен, не очень корректно. Изначально моя мысль была о том, что для постиндустриальной экономики некорректно считать дефицит только по товарному обороту. Цифр у меня нет, цифры для этого утверждения не нужны. ТС давал какие-то цифры в комментарии ниже
Это некорректная цифра, если говорить про торговый баланс. Как я уже сказал, часть товаров экспорта были только что импортированы из фабрик Китая/Тайваня. Очень важно учитывать долю импорта в экспорте, потому что Трамп наложил пошлины именно на импорт, который является частью экспорта.
Такой дисбаланс не может накапливаться вечно: рано или поздно потребуется некая коррекция траектории.
Может. Америка - постиндустриальная страна. Она в основном экспортирует не товары, а услуги. Майкрософт, гугл, оракл, нетфликс практически ничего не производят (у первых есть surface, но это капля в море). Даже железячники вроде nvidia, amd и apple, если уж очень грубо, закупают готовые изделия у подрядчиков и продают по всему миру. Их прибыль в корне постиндустриальная. Голливуд экспортирует фильмы на весь мир и получает прибыль со всего мира.
Смотреть баланс страны только по обороту товара для этой экономики в высшей степени некорректно.
Эта статья о другом. Кстати, у этой статьи есть перевод на хабре. Эта статья о том, что не надо использовать данные внешних ИС для ключа. Даже если внешняя система объявляет их уникальными.
В моём случае не все сущности имеют интовые ключи, для некоторых сущностей были использованы композитные ключи. Да, это другое.
Насчёт IEntity. Мысль понятна, я сам сталкивался с тем, что при дальнейшем развитии системы новые сущности не укладываются в казавшуюся изначально универсальной схему.
Но. Наступает момент, когда приходится сравнивать объекты по ключу, апдейтить их и делать другие нехорошие вещи, которые без primary key делать невозможно. И тут просходит пришествие IEntity 2.0. Точнее, IEntity<TKey> или что-то похитрее в случае композитных PK.
Для себя я отказался от интерфейса в общем случае, но те части системы, которым требуется доступ к PK сущности, требуют наличия у этой сущности генерик-наследования IEntity<TKey>
Вы сейчас передёргиваете. Я говорил, что код пишется для человека, а не для машины. Обоснование я тоже дал - код читается гораздо чаще, чем пишется.
С чем вы хотите поспорить? С тем что код чаще читается, чем пишется? Ну удачи.
Что значит "для бизнеса"? Не для бизнеса.
Я так тоже могу упростить до крайностей, смотрите: Бизнесу нет дела до кода, бизнес делает деньги. И всё, что ему нужно - это деньги. Код ему не нужен. Код - это вообще-то затраты на поддержку, а бизнес затраты не любит. Вывод: бизнес должен избегать написание кода.
Да всмысле? Вот же сами пишете:
Именно так. Вот тот самый пресловутый wtf/min. Есть ещё kloc, глубина наследования, связность классов.
Если вы не можете применить метрики прямо сейчас к проекту, это не значит, что их нет. Они есть. Но в силу уникальности каждого решения очень сложно делать общие метрики, которые уже где-то на таком же решении обкатаны.
Если вам нужно взять тысячу джунов и проверить время вкатывания на одном проекте и на другом, но с разной архитектурой, то не говорите, что это невозможно сделать. У вас просто денег нет на такие исследования.
Не надо за меня говорить, что я могу сказать. Пожалуйста.
И тем более, приравнивать читаемость к каким-то абстрактным практикам. Я выбрал термин "читаемость" и я на нём настаиваю. Я не имел в виду религиозное соблюдение солида или что-то в этом роде. Я говорил про читаемость. Про понятность.
Нет. Написать работающий код любой дурак может. Машина простит любой хаос в оформлении и любые названия переменных.
Код пишется людьми и для людей, и первая задача кода - быть понятным. Потому что код гораздо чаще читается, чем пишется.
Читаемость кода - это не лирика и не демагогия, как вам показалось. Технический долг - это не страшилки программеров. Он реально существует и способен похоронить под своей тяжестью любой проект.
Понятный код способен ускорить на порядок разработку и снизить на порядок стоимость поддержки проекта. Чем больше проект - тем сильнее влияние читаемости.
Работа программиста - это не написание кода. Это управление сложностью конструкции. И ООП - это один из главных инструментов в этом деле. Как любой инструмент, у него есть некий порог полезности, ниже которого накладные расходы на внедрение инструмента не дают выгоды, для себя я оцениваю этот порог в 300-500 строк, то есть дальше крохотного скрипта ООП почти всегда упрощает восприятие кода и сокращает расходы на поддержку.
Я сейчас наговорил кучу банальных вещей, простите.
А что ещё он мог сказать? Ему лопаты продавать надо.
ЧатГПТ нагло и беззастенчиво врёт. И остальные тоже. У них отличается процент и порог вранья, но принципиальной разницы нет.
5 тб вавки при 44кГц/16 бит это 8662 часа. Это год непрерывного воспроизведения, если слушать 24/7. Вы это действительно слушаете?
Не понимаю, как рейки могли придать этой конструкции устойчивость. В моём понимании у этой конструкции поперечный разброд и шатание никуда не делись, тут из вариантов только слева к стенке прислонять и прижимать шкафом справа.
Для устранения такого шатания необходима поперечина вдоль всей задней стенки высотой сантиметров 20 хотя бы. И не с самого верха, а с отступом тоже см 20.
Меня в этой конструкции очень, нет ОЧЕНЬ смущает плечо рычага по горизонтали - расстояние между центрами двух крайних креплений и центральным. Автор на этом же плясать собрался? Вот когда нагрузка направлена строго вниз - всё хорошо. Как только усилие получает сколь-нибудь значительное отклонение влево и вправо, то сразу усиливается этим рычагом. Мультипликатор - высота ножки. То есть, этот саморез вырывает с мясом, стол складывается как карточный домик, автор получает ЧМТ и больше не пляшет.
Я ожидал, что в примерах будет что-то вроде Raft, Valheim или даже Project Zomboid. Принц персии и борда - это зашейдеренные аутлайном довольно сложные модели.
Я сегодня пробовал нагопотить сайт-одностраничку. Сам я в современную вёрстку не умею, а древнюю забыл, поэтому решил отдать на аутсорс. Сначала всё шло хорошо, гопота собрала годный шаблон. Но по мере правок её сознание уплывало всё дальше куда-то в туманную даль. Вот я третий раз попросил вернуть прайс как было, убрать стописят баксов и вернуть зачёркнутые 100:
Она врёт. Нагло, беззастенчиво, в глаза. Но это не самое важное. Самое важное, что начинает терять контекст и переписывать то, о чём давно в нескольких итерациях договорились. Она не может удержать контекст даже маленькой странички. Она не может настроить блоки, чтобы был читаемый текст с достаточной контрастностью. И это простой веб.
В программирование я LLM даже близко не подпущу, там сложность на несколько порядков больше. А последствия бардака на порядок больнее.
А по-другому никак... Потому что всегда нужно хранить дополнительные параметры модели, которых нет ни в БД, ни в коде. Притом разрабы работают в разных окружениях (тест, дев, прод) и могут менять модель под свою задачу, а потом это всё надо мержить вместе с кодом, чтобы и тот и тот PR заработал в другом окружении.
И да, всё правильно, нужно делать не пересоздание структуры БД, а изменение. У меня этот механизм называется DDL diff. Состояние БД сравнивается с моделью и генерируется DDL, который приводит БД к состоянию модели. Не напрямую, конечно, с выбором и вычиткой DDL. Это всё довольно сложные механизмы, требующие знаний в механике баз данных.
Тут ещё есть один краеугольный камень - удобство. Это уже больше из области психологии, но всё же. Если разрабам неудобно напрямую в таком редакторе менять структуру - хоть что делай, они будут работать в другом инструменте, и иногда синхронизировать модель. Наверное. Но это не точно.
Как раз такой проблемы нет. В случае, если приложение уже умеет генерировать DDL diff. Если есть база данных, то можно прочитать её структуру и создать модель. Механизм всё тот же самый. Конечно, с кодом нужно будет повозиться, особенно если запросы раскиданы по всей кодобазе и особенно, если не использовался ORM. Но это в любом случае надо делать, чтобы понимать, какие части модели действительно используются в коде.
Первая проблема при создании такого рода инструмента - это поддержка актуальности. Поэтому я рассматривал подход model-first, когда модель данных создаётся и редактируется в отдельном приложении, и затем уже синхронизируется с БД и кодом.
Собственно, я такое приложение и разрабатываю. Это что-то вроде dbSchema, но есть возможность передавать всю структуру данных в python-скрипт, который уже в нужном языке сгенерирует нужный код. У каждого свои потребности, поэтому я решил именно так сделать.
При растущей мировой экономике другим странам нужно всё больше и больше долларов, чтобы расплачиваться друг с другом. Эта эмиссия может запросто перекрыть (и перекрывает) дисбаланс и делать с этим ничего не нужно. Уж точно не так, как делает Трамп. Он просто угробит сложившиеся отрасли и если у него что-то получится, то это откат экономики США к индустриальной модели.
Да, США получается бенифициар растущей экономики. За счёт стабильности своей валюты, за счёт глобальности экономики и устойчивости государственных бумаг. Они могут просто "напечатать" новые доллары для покрытия дефицита и всем будет хорошо. "Напечатать" я взял в кавычки, потому что фрс так просто не даст денег государству потому что "надо". Там довольно сложная система.
Хорошо, согласен, не очень корректно. Изначально моя мысль была о том, что для постиндустриальной экономики некорректно считать дефицит только по товарному обороту. Цифр у меня нет, цифры для этого утверждения не нужны. ТС давал какие-то цифры в комментарии ниже
А могут и не сломать. Я про это. Торговый дисбаланс может жить счастливо вечно, если будет дальнейшее смещение США в сторону услуг.
Это некорректная цифра, если говорить про торговый баланс. Как я уже сказал, часть товаров экспорта были только что импортированы из фабрик Китая/Тайваня. Очень важно учитывать долю импорта в экспорте, потому что Трамп наложил пошлины именно на импорт, который является частью экспорта.
Может. Америка - постиндустриальная страна. Она в основном экспортирует не товары, а услуги. Майкрософт, гугл, оракл, нетфликс практически ничего не производят (у первых есть surface, но это капля в море). Даже железячники вроде nvidia, amd и apple, если уж очень грубо, закупают готовые изделия у подрядчиков и продают по всему миру. Их прибыль в корне постиндустриальная. Голливуд экспортирует фильмы на весь мир и получает прибыль со всего мира.
Смотреть баланс страны только по обороту товара для этой экономики в высшей степени некорректно.
Ой, а что же вы раньше не сказали? Я бы не проходил четвёрку пять раз...
Писать про 2015 год и забыть про Fallout 4? Мде...
YAGNI - это совершенно нормальный принцип. Если понимать, про что он.
Он про то, что никакое усложнение не нужно по умолчанию. По умолчанию you aint gonna need it.
Это применение технологий/библиотек/фреймворков должно аргументироваться, их отсутствие - нет.
Короче, используйте только то, что нужно, а то, что не нужно - не используйте. И вообще, делайте хорошо, а плохо не делайте.
Эта статья о другом. Кстати, у этой статьи есть перевод на хабре. Эта статья о том, что не надо использовать данные внешних ИС для ключа. Даже если внешняя система объявляет их уникальными.
В моём случае не все сущности имеют интовые ключи, для некоторых сущностей были использованы композитные ключи. Да, это другое.
Насчёт IEntity. Мысль понятна, я сам сталкивался с тем, что при дальнейшем развитии системы новые сущности не укладываются в казавшуюся изначально универсальной схему.
Но. Наступает момент, когда приходится сравнивать объекты по ключу, апдейтить их и делать другие нехорошие вещи, которые без primary key делать невозможно. И тут просходит пришествие IEntity 2.0. Точнее, IEntity<TKey> или что-то похитрее в случае композитных PK.
Для себя я отказался от интерфейса в общем случае, но те части системы, которым требуется доступ к PK сущности, требуют наличия у этой сущности генерик-наследования IEntity<TKey>