Эта статья о другом. Кстати, у этой статьи есть перевод на хабре. Эта статья о том, что не надо использовать данные внешних ИС для ключа. Даже если внешняя система объявляет их уникальными.
В моём случае не все сущности имеют интовые ключи, для некоторых сущностей были использованы композитные ключи. Да, это другое.
Насчёт IEntity. Мысль понятна, я сам сталкивался с тем, что при дальнейшем развитии системы новые сущности не укладываются в казавшуюся изначально универсальной схему.
Но. Наступает момент, когда приходится сравнивать объекты по ключу, апдейтить их и делать другие нехорошие вещи, которые без primary key делать невозможно. И тут просходит пришествие IEntity 2.0. Точнее, IEntity<TKey> или что-то похитрее в случае композитных PK.
Для себя я отказался от интерфейса в общем случае, но те части системы, которым требуется доступ к PK сущности, требуют наличия у этой сущности генерик-наследования IEntity<TKey>
Это плохо завуалированное послание "сперва сам добейся". Это очень некрасивый ход. Я бы сказал, что недостойный.
Писать статью, чтобы убедить одного анонима в интернете? Я слишком рационален для того, чтобы тратить столько усилий впустую.
Тем более, что свою точку зрения я высказал и Вы её услышали.
вы общаетесь с каждым разрабом, анализируете его труд за полгода/год, в общем, подходите к каждому максимально индивидуально
Так и должно быть. Это называется работа. У программистов индивидуальные задачи, индивидуальные способности, индивидуальные области знаний. Оценки тоже должны быть индивидуальными.
Программисты - это не рота солдат. Они должны работать небольшими командами и в каждой команде должны быть свои тимлиды, ПМ, аналитики и другие ответственные лица.
Если вы не понимаете, что делает человек - вы не в праве оценивать его труд. Точка.
Перекладывание ответственности на метрики сделает хуже в первую очередь именно вам. Или сами углубляйтесь в детали работы каждого, либо доверьтесь ответственным лицам за каждое направление.
А как вы понимаете что каждый человек делает?
Вообще не понимаю, откуда такие вопросы могут взяться. Вы не пробовали поговорить с сотрудником, с его командой? Вникнуть в пул его задач?
Я считаю что команды должны знать что их работа анализируется
Вот именно, что работа должна анализироваться. Внедрение KPI - это не анализ, это попытка отмахнуться навсегда от анализа, т.е. совершенно противоположное.
Без хоть какой-то метрики сложно оценивать результаты разработчиков
Если вы не понимаете, что каждый человек делает - да. Только в этом случае метрики вас не спасут. Как я уже сказал, метрики покажут тех, кто лучше приспособился к метрикам.
Я бы к вам на работу не пошёл. Начнём с того, что с момента, как вы формализуете метрики, программисты начинают работать на метрики, а не на результат.
Будут драки за код-ревью, потому что ревьюить выгодно, а писать код - нет. И закрывать тикеты не выгодно, потому что их могут переоткрыть, а это сразу минус пять тысяч написанных строк кода. И не важно потом, правильно ли был тикет заведён, правильно ли был переоткрыт.
У меня был период, когда я за пару месяцев снёс около 6к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.
Мне кажется, что вы не там ищете ответы. Всё намного проще и если вооружиться бритвой Оккама, то места для когнитивных искажений не останется
Почему опытные разработчики создают переусложненные системы, которые никто не может поддерживать?
Потому что на старте проекта разработчики представляли себе архитектуру иначе, а после многочисленных смен парадигм и требований не было выделено достаточного времени для рефакторинга архитектуры.
Почему команды упорно продолжают использовать устаревшие технологии, когда существуют более эффективные альтернативы?
Потому что альтернативы несут в себе риски, которые сейчас не видны. Здесь есть другой ответ и он вам не понравится: потому что альтернативы не очень-то более эффективны.
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Потому что он работает. Потому, что в него вложено очень много человеко-часов. В написание, переписывание, отладку.
Почему 90% команд разработки регулярно не укладываются в сроки, несмотря на всё более изощренные методологии планирования?
Потому что реально можно оценить лишь видимую часть работы. Так получается, что сложные задачи имеют подводную часть. И какая она по объёму - предсказать невозможно.
Никакая пароварка не сбегает в магазин за продуктами, не помоет их, не нарежет нужными по размеру кубиками. Никакая пароварка не приготовит борщ, гуляш по-венгерски, селёдочку с луком, да даже бефстроганов с картошечкой-пюре. Пароварка - это просто инструмент. Все заявления, что она позволит экономно и разнообразно питаться, почти не тратя время на это - чушь.
У девушки явно есть деньги, судя по "мимоходному" упоминанию о налогах в 40%. Я думаю, что ей вообще нет смысла пытаться экономить эту тысячу евро.
В первом предложении есть упоминание, что она работает в международной компании доставки еды. Наверное есть какие-то скидки для своих сотрудников
Существует мнение антропологов, что хомо сапиенс эволюционно приспособлен к потреблению алкоголя. Просто потому, что включение забродивших фруктов в рацион увеличило вероятность выживания. Однако те особи, которые могли перерабатывать алкоголь с равной скоростью, как и ацетальдегид, тоже не очень выжили. Это те, кто мог нажраться фруктами "в говно", а потом на утро не было похмелья. Наверное, их сожрали, даже не побрезговав запахом перегара.
Собственно, надо понимать, что алкоголь перерабатывается в печени в два захода. Сам алкоголь - не яд. Ацетальдегид - да.
С одной стороны - алкоголь есть продукт натуральный, к чему организм эволюционно приспособлен. С другой стороны - та же самая эволюция не очень заботилась о долгожительстве мозга. Не в её это интересах.
Десктоп мультиплатформ-натив приложение для работы с моделью БД. Умеет сравнивать модели из разных коннекшенов (локал, прод), создаёт DDL diff, сохраняет модель в xml (для версионирования), умеет редактировать данные в таблицах (даже заджойненных). Прикручен редактор питона для запуска скриптов-генераторов (текущая модель БД генерирует код для стандартной или кастомной ORM)
Там не только рендеринг. Это понятно, что виртуальность во все поля. Нейтив это не только рендеринг, это ещё мемори менеджмент. Собственно, держать данные так, чтобы int32 занимал 4 байта в памяти (ну чуть больше с учётом накладных), а не забоксенные 24 я знаю как в нейтиве, но не знаю, как в js
Я пишу db management tool нативно (ну почти), потому что электрон даже близко не может справиться с показом табличек в 100к строк и сотней столбцов. У меня можно и миллион записей смотреть. Оно не всем надо, но это просто гарантия, что оно не затормозит на жалких 10к.
DBeaver очень сильно перегружен, просто адовый интерфейс. DataGrip сильно платный и тоже не без недостатков. Помню, хотел его для Postgres использовать и не нашёл, как работать с комментами полей.
Я сейчас разрабатываю свою утилиту, но она отталкивается от модели данных, а не текущего соединения.
Писать про 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к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.
Мне кажется, что вы не там ищете ответы. Всё намного проще и если вооружиться бритвой Оккама, то места для когнитивных искажений не останется
Потому что на старте проекта разработчики представляли себе архитектуру иначе, а после многочисленных смен парадигм и требований не было выделено достаточного времени для рефакторинга архитектуры.
Потому что альтернативы несут в себе риски, которые сейчас не видны. Здесь есть другой ответ и он вам не понравится: потому что альтернативы не очень-то более эффективны.
Потому что он работает. Потому, что в него вложено очень много человеко-часов. В написание, переписывание, отладку.
Потому что реально можно оценить лишь видимую часть работы. Так получается, что сложные задачи имеют подводную часть. И какая она по объёму - предсказать невозможно.
Не знаю, актуально или нет. Только сейчас про вас вспомнил. Внедрил постгрес ещё в декабре, до SQLite пока не добрался
Никакая пароварка не сбегает в магазин за продуктами, не помоет их, не нарежет нужными по размеру кубиками. Никакая пароварка не приготовит борщ, гуляш по-венгерски, селёдочку с луком, да даже бефстроганов с картошечкой-пюре. Пароварка - это просто инструмент. Все заявления, что она позволит экономно и разнообразно питаться, почти не тратя время на это - чушь.
У девушки явно есть деньги, судя по "мимоходному" упоминанию о налогах в 40%. Я думаю, что ей вообще нет смысла пытаться экономить эту тысячу евро.
В первом предложении есть упоминание, что она работает в международной компании доставки еды. Наверное есть какие-то скидки для своих сотрудников
Существует мнение антропологов, что хомо сапиенс эволюционно приспособлен к потреблению алкоголя. Просто потому, что включение забродивших фруктов в рацион увеличило вероятность выживания. Однако те особи, которые могли перерабатывать алкоголь с равной скоростью, как и ацетальдегид, тоже не очень выжили. Это те, кто мог нажраться фруктами "в говно", а потом на утро не было похмелья. Наверное, их сожрали, даже не побрезговав запахом перегара.
Собственно, надо понимать, что алкоголь перерабатывается в печени в два захода. Сам алкоголь - не яд. Ацетальдегид - да.
С одной стороны - алкоголь есть продукт натуральный, к чему организм эволюционно приспособлен. С другой стороны - та же самая эволюция не очень заботилась о долгожительстве мозга. Не в её это интересах.
Так сони пытались доставщиков демократии жукам подсадить на этот злополучный PSN. Их правда только на три дня хватило, но всё же...
https://ormfactory.com/
Десктоп мультиплатформ-натив приложение для работы с моделью БД. Умеет сравнивать модели из разных коннекшенов (локал, прод), создаёт DDL diff, сохраняет модель в xml (для версионирования), умеет редактировать данные в таблицах (даже заджойненных). Прикручен редактор питона для запуска скриптов-генераторов (текущая модель БД генерирует код для стандартной или кастомной ORM)
Поддерживается MySql и PostgreSQL
Там не только рендеринг. Это понятно, что виртуальность во все поля. Нейтив это не только рендеринг, это ещё мемори менеджмент. Собственно, держать данные так, чтобы int32 занимал 4 байта в памяти (ну чуть больше с учётом накладных), а не забоксенные 24 я знаю как в нейтиве, но не знаю, как в js
Я пишу db management tool нативно (ну почти), потому что электрон даже близко не может справиться с показом табличек в 100к строк и сотней столбцов. У меня можно и миллион записей смотреть. Оно не всем надо, но это просто гарантия, что оно не затормозит на жалких 10к.
DBeaver очень сильно перегружен, просто адовый интерфейс. DataGrip сильно платный и тоже не без недостатков. Помню, хотел его для Postgres использовать и не нашёл, как работать с комментами полей.
Я сейчас разрабатываю свою утилиту, но она отталкивается от модели данных, а не текущего соединения.
https://habr.com/ru/companies/selectel/articles/664260/comments/#comment_24332758