Я ожидал, что в примерах будет что-то вроде 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>
Это плохо завуалированное послание "сперва сам добейся". Это очень некрасивый ход. Я бы сказал, что недостойный.
Писать статью, чтобы убедить одного анонима в интернете? Я слишком рационален для того, чтобы тратить столько усилий впустую.
Тем более, что свою точку зрения я высказал и Вы её услышали.
вы общаетесь с каждым разрабом, анализируете его труд за полгода/год, в общем, подходите к каждому максимально индивидуально
Так и должно быть. Это называется работа. У программистов индивидуальные задачи, индивидуальные способности, индивидуальные области знаний. Оценки тоже должны быть индивидуальными.
Программисты - это не рота солдат. Они должны работать небольшими командами и в каждой команде должны быть свои тимлиды, ПМ, аналитики и другие ответственные лица.
Если вы не понимаете, что делает человек - вы не в праве оценивать его труд. Точка.
Перекладывание ответственности на метрики сделает хуже в первую очередь именно вам. Или сами углубляйтесь в детали работы каждого, либо доверьтесь ответственным лицам за каждое направление.
А как вы понимаете что каждый человек делает?
Вообще не понимаю, откуда такие вопросы могут взяться. Вы не пробовали поговорить с сотрудником, с его командой? Вникнуть в пул его задач?
Я считаю что команды должны знать что их работа анализируется
Вот именно, что работа должна анализироваться. Внедрение KPI - это не анализ, это попытка отмахнуться навсегда от анализа, т.е. совершенно противоположное.
Без хоть какой-то метрики сложно оценивать результаты разработчиков
Если вы не понимаете, что каждый человек делает - да. Только в этом случае метрики вас не спасут. Как я уже сказал, метрики покажут тех, кто лучше приспособился к метрикам.
Я бы к вам на работу не пошёл. Начнём с того, что с момента, как вы формализуете метрики, программисты начинают работать на метрики, а не на результат.
Будут драки за код-ревью, потому что ревьюить выгодно, а писать код - нет. И закрывать тикеты не выгодно, потому что их могут переоткрыть, а это сразу минус пять тысяч написанных строк кода. И не важно потом, правильно ли был тикет заведён, правильно ли был переоткрыт.
У меня был период, когда я за пару месяцев снёс около 6к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.
Я ожидал, что в примерах будет что-то вроде 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>
Tri-state checkbox - это вполне разумный паттерн, когда нужно выбрать объекты в иерархии. Кстати, очень удобно: можно одним кликом выбрать всю ветку.
Пример
А Вы не понимаете, что мы на паблик ресурсе, да? Моё мнение видно не только вам - вот вам ответ.
Ещё раз. Я не подросток, которого можно взять на "слабо" и мотивировать такими насквозь манипулятивными методами.
Знаете, чем отличается моё мнение от Вашего? Моё имеет хоть какие-то аргументы.
Кстати, минус в карму поставил я. За неконструктивное общение. Мне надоело объяснять элементарные вещи.
Это плохо завуалированное послание "сперва сам добейся". Это очень некрасивый ход. Я бы сказал, что недостойный.
Писать статью, чтобы убедить одного анонима в интернете? Я слишком рационален для того, чтобы тратить столько усилий впустую.
Тем более, что свою точку зрения я высказал и Вы её услышали.
Так и должно быть. Это называется работа. У программистов индивидуальные задачи, индивидуальные способности, индивидуальные области знаний. Оценки тоже должны быть индивидуальными.
Программисты - это не рота солдат. Они должны работать небольшими командами и в каждой команде должны быть свои тимлиды, ПМ, аналитики и другие ответственные лица.
Если вы не понимаете, что делает человек - вы не в праве оценивать его труд. Точка.
Перекладывание ответственности на метрики сделает хуже в первую очередь именно вам. Или сами углубляйтесь в детали работы каждого, либо доверьтесь ответственным лицам за каждое направление.
Вообще не понимаю, откуда такие вопросы могут взяться. Вы не пробовали поговорить с сотрудником, с его командой? Вникнуть в пул его задач?
Вот именно, что работа должна анализироваться. Внедрение KPI - это не анализ, это попытка отмахнуться навсегда от анализа, т.е. совершенно противоположное.
Если вы не понимаете, что каждый человек делает - да. Только в этом случае метрики вас не спасут. Как я уже сказал, метрики покажут тех, кто лучше приспособился к метрикам.
Я бы к вам на работу не пошёл. Начнём с того, что с момента, как вы формализуете метрики, программисты начинают работать на метрики, а не на результат.
Будут драки за код-ревью, потому что ревьюить выгодно, а писать код - нет. И закрывать тикеты не выгодно, потому что их могут переоткрыть, а это сразу минус пять тысяч написанных строк кода. И не важно потом, правильно ли был тикет заведён, правильно ли был переоткрыт.
У меня был период, когда я за пару месяцев снёс около 6к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.