Довольно странно сравнивать заводы в СССР и ИТ-шников сейчас. Сравните тогда нынешнее положение работников на заводе со временами СССР.
Кроме того надо понимать какие времена сравниваем - позднего СССР, времен Андропова и Горбачева или СССР на пике развития - после войны.
Но суть капитализма не во времени в пути на работу, а в том что расходы на поддержание бренного тела работника в трудоспособном состоянии перекладываются на самого работника. Поэтому работник, который меньше времени и денег на это тратит, оказывается выгоднее капиталисту. Несмотря на все высокопарные заявления руководителей крупных компаний о заботе о работниках, выбор всегда будет в пользу условного Миши.
Поэтому единственный вариант поддержания и развития человеческого капитала в масштабах страны или отрасли - социализм, то есть отъем часть прибыли капиталистов и распределение её в пользу работников.
Расскажите пожалуйста как в вашем примере не продать дважды один товар?
Если вы считаете остатки по таблице Events, то у вас не будет преимущества в скорости работы. Если вы остатки пересчитываете асинхронно, то вы сможете продать то, чего нет. Если вы остатки пересчитываете синхронно, то смысл в отдельной write-модели пропадает.
Объем оценить легче чем срок и гораздо точнее. Срок зависит от объема, продуктивности и нагрузки исполнителей, ожиданий, связи и параллелизма задач.
В принципе вся наука типа PERT и сетевого планирования придумана чтобы объемы превратить в сроки.
Собственно проблема всех научных методов в том, что они требуют детальную декомпозицию задач и исполнителей на весь срок планирования, что зачастую сделать невозможно, ибо мы не знаем чего мы не знаем. Но даже на старте проекта мы можем оценить относительные объемы-сложности фич в условных попугаях стори поинтах, а потом, в процессе, считать коэффициенты перевода стори-поинтов в сроки и получать предсказуемые сроки реализации фич.
Научная ценность отрицательная, достижения автора сомнительны, история неинтересная.
В реальности причины могут быть как в психике (депрессия), так и состоянии гормональной, сердечно-сосудистой системы, в лишнем весе и\или неправильном питании. Да в чем угодно, и на входе информации нет.
Задача-то проверить на этапе компиляции, что все случаи обрабатываются.
Как всегда есть нюанс. В C# используются C_style enums. То есть (Foo)25 это тоже корректное значение и компилятор проверяет что и его тоже покрывает switch-expression.
Чтобы при появлении новых случаев компилятор предупредил если их забыли добавить в switch.
Ну конечно нет.
Так вот, эту задачу связка enum+switch в C# не решает. Можно сколько угодно говорить что программист дурак и не понимает как работают enum, а компилятор делает всё правильно, но задача от этого не решится.
Программист-дурак это тот, кто думает что знает как должно работать, но не читал спецификацию.
Если анализ гитхаба и другого опенсорса говорит, что ничего не сломается от такого изменения, то ничего страшного.
На собеседовании: систем дизайн, архитектура, алгоритмы.
На практике: перекладывание json и сборка страничек из готовых реакт компонентов.
ИМХО все эти вопросы на собеседовании нужны чтобы делать вид, что компания на уровне Гугла или фейсбука.
Довольно странно сравнивать заводы в СССР и ИТ-шников сейчас. Сравните тогда нынешнее положение работников на заводе со временами СССР.
Кроме того надо понимать какие времена сравниваем - позднего СССР, времен Андропова и Горбачева или СССР на пике развития - после войны.
Но суть капитализма не во времени в пути на работу, а в том что расходы на поддержание бренного тела работника в трудоспособном состоянии перекладываются на самого работника. Поэтому работник, который меньше времени и денег на это тратит, оказывается выгоднее капиталисту. Несмотря на все высокопарные заявления руководителей крупных компаний о заботе о работниках, выбор всегда будет в пользу условного Миши.
Поэтому единственный вариант поддержания и развития человеческого капитала в масштабах страны или отрасли - социализм, то есть отъем часть прибыли капиталистов и распределение её в пользу работников.
Добро пожаловать в капитализм
Решение абсолютно любых задач постоянно возрастающей сложности в течение года приведет к тем же результатам.
Правда на работе можно 10 лет перекладывать json и фактически ничему не научиться.
Это первый вариант, по блокировкам и скорости работы он эквивалентен просто хранению остатков в таблице и транзакционном обновлении.
Расскажите пожалуйста как в вашем примере не продать дважды один товар?
Если вы считаете остатки по таблице Events, то у вас не будет преимущества в скорости работы. Если вы остатки пересчитываете асинхронно, то вы сможете продать то, чего нет. Если вы остатки пересчитываете синхронно, то смысл в отдельной write-модели пропадает.
Два раза не получилось, на третий раз сделали нормально. Хорошо бы как-то заранее научиться делать с первого раза хотя бы приемлемо.
вообще-то их нет
некоторые программисты родились позже
Объем оценить легче чем срок и гораздо точнее. Срок зависит от объема, продуктивности и нагрузки исполнителей, ожиданий, связи и параллелизма задач.
В принципе вся наука типа PERT и сетевого планирования придумана чтобы объемы превратить в сроки.
Собственно проблема всех научных методов в том, что они требуют детальную декомпозицию задач и исполнителей на весь срок планирования, что зачастую сделать невозможно, ибо мы не знаем чего мы не знаем. Но даже на старте проекта мы можем оценить относительные объемы-сложности фич в
условных попугаяхстори поинтах, а потом, в процессе, считать коэффициенты перевода стори-поинтов в сроки и получать предсказуемые сроки реализации фич.СП нужны для двух вещей:
отделить оценку срока от оценки объема
сделать интегральную оценку затрат команды, а не планировать работу каждого специалиста
И обе цели индуцируют недостатки:
бизнесу нужны сроки, так как зарплаты не зависят от трудозатрат и объема работ
бизнесу нужна максимальная утилизация каждого сотрудника, а не высокий velocity
бизнес хочет объективные величины сроков\затрат\результата, а не абстрактные
Поэтому проблема не в самих СП, а в разрыве между бизнесом и процессом разработки.
И?
Надо использовать или не надо? Если надо, то каких ограничений придерживаться?
Или использовать что-то другое?
Интересно кто плюсует такие статьи?
Научная ценность отрицательная, достижения автора сомнительны, история неинтересная.
В реальности причины могут быть как в психике (депрессия), так и состоянии гормональной, сердечно-сосудистой системы, в лишнем весе и\или неправильном питании. Да в чем угодно, и на входе информации нет.
При чем тут Go?
Как всегда есть нюанс. В C# используются C_style enums. То есть (Foo)25 это тоже корректное значение и компилятор проверяет что и его тоже покрывает switch-expression.
Ну конечно нет.
Программист-дурак это тот, кто думает что знает как должно работать, но не читал спецификацию.
Как работают enum в C#
Ну это если не читать спецификацию языка
С#, Kotlin и даже, внезапно, Python. Но у последнего сложнее с completeness и redundancy check.
Чем вы ифы замените в таком случае?