Такой дисбаланс не может накапливаться вечно: рано или поздно потребуется некая коррекция траектории.
Может. Америка - постиндустриальная страна. Она в основном экспортирует не товары, а услуги. Майкрософт, гугл, оракл, нетфликс практически ничего не производят (у первых есть surface, но это капля в море). Даже железячники вроде nvidia, amd и apple, если уж очень грубо, закупают готовые изделия у подрядчиков и продают по всему миру. Их прибыль в корне постиндустриальная. Голливуд экспортирует фильмы на весь мир и получает прибыль со всего мира.
Смотреть баланс страны только по обороту товара для этой экономики в высшей степени некорректно.
Эта статья о другом. Кстати, у этой статьи есть перевод на хабре. Эта статья о том, что не надо использовать данные внешних ИС для ключа. Даже если внешняя система объявляет их уникальными.
В моём случае не все сущности имеют интовые ключи, для некоторых сущностей были использованы композитные ключи. Да, это другое.
Насчёт IEntity. Мысль понятна, я сам сталкивался с тем, что при дальнейшем развитии системы новые сущности не укладываются в казавшуюся изначально универсальной схему.
Но. Наступает момент, когда приходится сравнивать объекты по ключу, апдейтить их и делать другие нехорошие вещи, которые без primary key делать невозможно. И тут просходит пришествие IEntity 2.0. Точнее, IEntity<TKey> или что-то похитрее в случае композитных PK.
Для себя я отказался от интерфейса в общем случае, но те части системы, которым требуется доступ к PK сущности, требуют наличия у этой сущности генерик-наследования IEntity<TKey>
Это плохо завуалированное послание "сперва сам добейся". Это очень некрасивый ход. Я бы сказал, что недостойный.
Писать статью, чтобы убедить одного анонима в интернете? Я слишком рационален для того, чтобы тратить столько усилий впустую.
Тем более, что свою точку зрения я высказал и Вы её услышали.
вы общаетесь с каждым разрабом, анализируете его труд за полгода/год, в общем, подходите к каждому максимально индивидуально
Так и должно быть. Это называется работа. У программистов индивидуальные задачи, индивидуальные способности, индивидуальные области знаний. Оценки тоже должны быть индивидуальными.
Программисты - это не рота солдат. Они должны работать небольшими командами и в каждой команде должны быть свои тимлиды, ПМ, аналитики и другие ответственные лица.
Если вы не понимаете, что делает человек - вы не в праве оценивать его труд. Точка.
Перекладывание ответственности на метрики сделает хуже в первую очередь именно вам. Или сами углубляйтесь в детали работы каждого, либо доверьтесь ответственным лицам за каждое направление.
А как вы понимаете что каждый человек делает?
Вообще не понимаю, откуда такие вопросы могут взяться. Вы не пробовали поговорить с сотрудником, с его командой? Вникнуть в пул его задач?
Я считаю что команды должны знать что их работа анализируется
Вот именно, что работа должна анализироваться. Внедрение KPI - это не анализ, это попытка отмахнуться навсегда от анализа, т.е. совершенно противоположное.
Без хоть какой-то метрики сложно оценивать результаты разработчиков
Если вы не понимаете, что каждый человек делает - да. Только в этом случае метрики вас не спасут. Как я уже сказал, метрики покажут тех, кто лучше приспособился к метрикам.
Я бы к вам на работу не пошёл. Начнём с того, что с момента, как вы формализуете метрики, программисты начинают работать на метрики, а не на результат.
Будут драки за код-ревью, потому что ревьюить выгодно, а писать код - нет. И закрывать тикеты не выгодно, потому что их могут переоткрыть, а это сразу минус пять тысяч написанных строк кода. И не важно потом, правильно ли был тикет заведён, правильно ли был переоткрыт.
У меня был период, когда я за пару месяцев снёс около 6к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.
Мне кажется, что вы не там ищете ответы. Всё намного проще и если вооружиться бритвой Оккама, то места для когнитивных искажений не останется
Почему опытные разработчики создают переусложненные системы, которые никто не может поддерживать?
Потому что на старте проекта разработчики представляли себе архитектуру иначе, а после многочисленных смен парадигм и требований не было выделено достаточного времени для рефакторинга архитектуры.
Почему команды упорно продолжают использовать устаревшие технологии, когда существуют более эффективные альтернативы?
Потому что альтернативы несут в себе риски, которые сейчас не видны. Здесь есть другой ответ и он вам не понравится: потому что альтернативы не очень-то более эффективны.
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Потому что он работает. Потому, что в него вложено очень много человеко-часов. В написание, переписывание, отладку.
Почему 90% команд разработки регулярно не укладываются в сроки, несмотря на всё более изощренные методологии планирования?
Потому что реально можно оценить лишь видимую часть работы. Так получается, что сложные задачи имеют подводную часть. И какая она по объёму - предсказать невозможно.
Никакая пароварка не сбегает в магазин за продуктами, не помоет их, не нарежет нужными по размеру кубиками. Никакая пароварка не приготовит борщ, гуляш по-венгерски, селёдочку с луком, да даже бефстроганов с картошечкой-пюре. Пароварка - это просто инструмент. Все заявления, что она позволит экономно и разнообразно питаться, почти не тратя время на это - чушь.
У девушки явно есть деньги, судя по "мимоходному" упоминанию о налогах в 40%. Я думаю, что ей вообще нет смысла пытаться экономить эту тысячу евро.
В первом предложении есть упоминание, что она работает в международной компании доставки еды. Наверное есть какие-то скидки для своих сотрудников
Существует мнение антропологов, что хомо сапиенс эволюционно приспособлен к потреблению алкоголя. Просто потому, что включение забродивших фруктов в рацион увеличило вероятность выживания. Однако те особи, которые могли перерабатывать алкоголь с равной скоростью, как и ацетальдегид, тоже не очень выжили. Это те, кто мог нажраться фруктами "в говно", а потом на утро не было похмелья. Наверное, их сожрали, даже не побрезговав запахом перегара.
Собственно, надо понимать, что алкоголь перерабатывается в печени в два захода. Сам алкоголь - не яд. Ацетальдегид - да.
С одной стороны - алкоголь есть продукт натуральный, к чему организм эволюционно приспособлен. С другой стороны - та же самая эволюция не очень заботилась о долгожительстве мозга. Не в её это интересах.
Господам сливающим напоминаю: если вы будете бороться с критикой таким способом, то всё, что изменится - вы не увидите критики. Значит, не будете видеть, что можно исправить.
Классический N+1 может быть на порядки быстрее, чем O(1)
О-нотация - это не про скорость. Это про зависимость времени выполнения алгоритма от объёма входных данных.
Это значит, что при увеличении данных в 1000 раз выбор из кэша затормозит тоже примерно в 1000 раз. А запрос из Тайваня будет выполняться примерно столько же, сколько и выполнялся.
Все эти О-нотации нужны исключительно олимпиадникам
Нет. Это было бы так в идеальном мире, где джуны не вставляют цикл в цикл и потом ещё и защищают конструкцию: "ну ведь работает же". А оно работает на тестовых 10 записях.
Может. Америка - постиндустриальная страна. Она в основном экспортирует не товары, а услуги. Майкрософт, гугл, оракл, нетфликс практически ничего не производят (у первых есть 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к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.
Мне кажется, что вы не там ищете ответы. Всё намного проще и если вооружиться бритвой Оккама, то места для когнитивных искажений не останется
Потому что на старте проекта разработчики представляли себе архитектуру иначе, а после многочисленных смен парадигм и требований не было выделено достаточного времени для рефакторинга архитектуры.
Потому что альтернативы несут в себе риски, которые сейчас не видны. Здесь есть другой ответ и он вам не понравится: потому что альтернативы не очень-то более эффективны.
Потому что он работает. Потому, что в него вложено очень много человеко-часов. В написание, переписывание, отладку.
Потому что реально можно оценить лишь видимую часть работы. Так получается, что сложные задачи имеют подводную часть. И какая она по объёму - предсказать невозможно.
Не знаю, актуально или нет. Только сейчас про вас вспомнил. Внедрил постгрес ещё в декабре, до SQLite пока не добрался
Никакая пароварка не сбегает в магазин за продуктами, не помоет их, не нарежет нужными по размеру кубиками. Никакая пароварка не приготовит борщ, гуляш по-венгерски, селёдочку с луком, да даже бефстроганов с картошечкой-пюре. Пароварка - это просто инструмент. Все заявления, что она позволит экономно и разнообразно питаться, почти не тратя время на это - чушь.
У девушки явно есть деньги, судя по "мимоходному" упоминанию о налогах в 40%. Я думаю, что ей вообще нет смысла пытаться экономить эту тысячу евро.
В первом предложении есть упоминание, что она работает в международной компании доставки еды. Наверное есть какие-то скидки для своих сотрудников
Существует мнение антропологов, что хомо сапиенс эволюционно приспособлен к потреблению алкоголя. Просто потому, что включение забродивших фруктов в рацион увеличило вероятность выживания. Однако те особи, которые могли перерабатывать алкоголь с равной скоростью, как и ацетальдегид, тоже не очень выжили. Это те, кто мог нажраться фруктами "в говно", а потом на утро не было похмелья. Наверное, их сожрали, даже не побрезговав запахом перегара.
Собственно, надо понимать, что алкоголь перерабатывается в печени в два захода. Сам алкоголь - не яд. Ацетальдегид - да.
С одной стороны - алкоголь есть продукт натуральный, к чему организм эволюционно приспособлен. С другой стороны - та же самая эволюция не очень заботилась о долгожительстве мозга. Не в её это интересах.
Так сони пытались доставщиков демократии жукам подсадить на этот злополучный PSN. Их правда только на три дня хватило, но всё же...
Да, за него. Тут было всего два комментария, но именно у первого появилось -8 одновременно с минусами в карму. У второго +9/-1, он не кандидат.
Нормально мне так карму слили за комментарий
Скрытый текст
Господам сливающим напоминаю: если вы будете бороться с критикой таким способом, то всё, что изменится - вы не увидите критики. Значит, не будете видеть, что можно исправить.
О-нотация - это не про скорость. Это про зависимость времени выполнения алгоритма от объёма входных данных.
Это значит, что при увеличении данных в 1000 раз выбор из кэша затормозит тоже примерно в 1000 раз. А запрос из Тайваня будет выполняться примерно столько же, сколько и выполнялся.
Нет. Это было бы так в идеальном мире, где джуны не вставляют цикл в цикл и потом ещё и защищают конструкцию: "ну ведь работает же". А оно работает на тестовых 10 записях.