В команде из 20 человек у вас один дежурный превращается в продвинутый линтер скорее всего. Он не знает архитектуры этой части системы с высокой долей вероятности, он не знает подводных камней и нюансов, он не понимает этого фрагмента предметной области как следует. В итоге либо он на всё это забивает и проверяет код по чеклисту; либо автор кода ему всё это рассказывает долго и мучительно (другие авторы в это время ждут) - и хорошо если ревьюер честно просит это сделать, а не начинает выдавать замечания одно бесячее другого; либо если автор примерно таким же уровнем знаний обладает, то они совместно демонстрируют пример эффекта Даннинга-Крюгера и плохой код улетает в продакшен
Ревью кода - конечно несовершенный процесс, но его не сделаешь лучше, выплеснув вместе с его недостатками его достоинства
В маленькой команде, где у всех относительно неплохие знания обо всём (4, максимум 5 человек), такая схема будет работать, но будет обходиться очень дорого, потому что "дежурный по ревью" - это будет 20-25% ресурса; если не предполагать, что в большинстве случаев никаких доработок и не потребуется и большинство времени человек будет не ревьюить, а заниматься какими-то своими задачами - но в этом случае и никакой страшно нарисованной проблемы задержек и бесконечных циклов не будет - проверяющий быстро посмотрит, скажет ок и вернется к своим делам. Ревью откладывается на потом именно в командах, где в большинстве случаев это трудный, долгий и мучительный процесс с большим количеством итераций.
А в большой команде, где ревью много, а знания о системе распределены неравномерно, процесс, построенный по описанию в статье, выродится в одну из двух сторон в зависимости от степени добросовестности ревьюера. Либо это будет чисто формальная процедура, которая никаких багов конечно не предотвратит, кроме самых явных и тупых - будет проверено соответствие кода формальным критериям, имен переменных соглашениям и т.п.: то, что мог бы сделать линтер и человек для этого не нужен. Либо ревьюер, сидя над кодом часами - сначала сам разбираясь в нём, потом разбираясь вместе с автором, как его исправить - сам станет узким место процесса, потому что пока он ковыряется в одном реквесте, там его уже ждут ещё 5, а он должен закончить этот, чтобы бесконечных циклов и вываливаний из потока не произошло
В общем, там где описанное выглядит хорошо - нет проблемы, которую надо решать, а там где есть проблема - там оно хорошо не выглядит
Потому возможно и нет академических исследований, что когда базовые задачи в области NP-полные - никому туда лезть не хочется. Голову сложишь ни за что и никакой карьеры научной на этом не построишь
Так может между курсом доллара и сезонной миграцией журавлей действительно существует связь, только она слишком сложна, чтобы мы её аналитически установили, и поэтому мы опасаемся её использовать?
В это случае "тупой" AI может оказаться умнее "умного" человека просто за счет того, что может проанализировать огромный объем данных и чисто статистически установить действительность этой связи, не задаваясь вопросом почему эта связь вообще существует, а просто используя её в практических целях
Сборная Уэльса вышла в финал чемпионата мира во второй раз в истории, а первый был в 1958. Получается, что её выход в плэй-офф предсказан на основании того, что 64 года назад они сыграли довольно хорошо. Если бы они тогда проиграли все 3 матча - они бы и по этой модели должны были бы сыграть плохо. Очевидно, что это не имеет никакого отношения к реальной их силе
Уже из этого примера понятно, что эта модель никуда не годится
И действительно неудивительно, что чемпионом по ней стала Бразилия - это единственная сборная, которая участвовала абсолютно во всех финальных турнирах ЧМ в истории
Это скорее яркий антипаттерн - когда берется модель, неплохо подошедшая к одной задаче, и механически применяется к другой похожей, но на самом деле по сути абсолютно другой
Потому что для него разрыв строки несет смысловое значение - для него это начало нового предложения.
Видимо, авторы решили, что пользователи чаще вставляют абзацы без точки в конце, чем цельное предложение, разбитое на отдельные строки. Поскольку у них для принятия таких решений есть статистика, я бы им поверил
Тут работает принцип Парето - 80% работы занимает 20% времени. Все те 80% фич, которые можно было сделать быстро, уже давно сделали, и нынешним разработчикам достались сложные фичи, которые надо еще и накладывать на код, написанный давно и другими людьми
Ну это если не поддаваться ощущениям, что раньше трава была зеленее
По всей видимости, эта мышца не очень эффективно устроена и именно за счет этого сжигает много калорий относительно объема выполняемой работы
Меня правда ужасно смущает с точки зрения качества информации вот эта фраза "Вместо расщепления гликогена она предпочитает использовать другие виды топлива, такие как глюкоза и холестерины ". Любая мышца вместо расщепления гликогена предпочитает использовать глюкозу, потому что расщепление гликогена происходит именно с целью получить глюкозу. Это как любой человек предпочтет съесть вареные пельмени, если они есть, а не достать их из холодильника и варить.
И вот эта "А какие у вас ноги будут прокачанные". Камбаловидная мышца находится в глубине тела и сколько ее не качай - видно ее не станет
И возможно есть еще другие перлы, которые пропустил
Проблема с масштабированием в том, что разные части монолита испытывают разную нагрузку. И когда у вас какая-то часть прекрасно справляется в одном экземпляре, а другой надо сто инстансов - начинаются танцы с бубном
Потому что все боятся cookie theft. И не зря боятся в мире, где куча народу куда угодно заходят удаленно из Бог знает каких публичных сетей не особо парясь на тему того, что они в этой публичной сети в первый раз в жизни работают и ничего не знают про её владельцев.
Архитектура (которая дома строит из дерева, камня, стекла и бетона) - искусство, наука или ремесло?
Написание битов на продажу - искусства, наука (ну это вряд ли конечно, но там тоже есть свои закономерности, которые если уловить, то будешь успешнее) или ремесло?
Анализатор крови создать, который будет делать анализы в 2 раза быстрее и/или в 2 раза точнее - искусство, наука или ремесло?
Ну и так далее
Любая классификация придумывается для упрощения. Когда что-то не лезет в классификацию - надо просто спокойно признать, что для этого "что-то" эта классификация не годится и не надо её использовать, а не впихивать невпихуемое. Потому что это не даст в данном случае никакого упрощения, следовательно непонятно, зачем на это тратить силы и время
Доллар не рос с такой скоростью, потому что его курс ещё не был достаточно свободным от регулирования и потому что инфляция была не чисто монетарной, её вызывала структурная перестройка экономики. Годовая инфляция в феврале 1994 была 600%, а курс доллара за год с февраля 1993 вырос не в 7 раз, а примерно в 3.5
Так что те, когда тогда спокойно накапливали валюту под подушкой, потеряли за год половину накопленного
Я если честно не знаю тех, кто тогда деньги спокойно складывал в тумбочку (впрочем, о наличии денег в тумбочке тогда никто и не горел желанием рассказывать по понятным причинам). Все, у кого появлялись какие-то деньги, тут же стремились их на что-нибудь потратить. Что угодно - машина, квартира, вставить зубы, вложить в какой-то бизнес. Но не спокойно сидеть на них
Люди понесли свои деньги в МММ не из-за отсутствия уроков финансовой грамотности. Вообще, чтобы догадаться, что люди, которым ты отдаешь свои деньги, могут тебя обмануть и деньги не вернуть, никакого образования не нужно, достаточно не быть кретином. Причины были совершенно в другом, я это могу оценить это как наблюдавший своими глазами - в моем окружении было очень много людей, отдававших деньги во Властилину (потому что она территориально находилась близко)
Во-первых, только что произошел ряд событий, превративший многолетние накопления в прах и продолжавший любые накопления в прах превращать: МММ начал собирать деньги в феврале 1994 года, когда годовая инфляция составляла 600%. Поэтому все искали возможность получить быстрые доходы - деньги, ни во что не вложенные, сгорали на глазах
Во-вторых, отсутствовало какое-то внятное регулирование финансовой отрасли в принципе - старое исчезло, новое ещё не выросло. Отнеся деньги в банк, вы точно так же могли через полгода этого банка уже не обнаружить.
В-третьих, отсутствовало хоть какое-то понятие деловой репутации, потому что любая фирма, которую вы могли найти, ещё три года назад точно не существовала (кроме предельных случаев вроде Сбербанка). Вы не могли сказать, что вот эта фирма ненадежна, потому что она открыта год назад - все фирмы были открыты год назад
В-четвертых, все эти МММ и Властилины реально выплачивали деньги какое-то время. И в условиях первых трех пунктов это было в принципе уже немало, потому что на порядок больше было ситуаций, когда с людей тупо собирали деньги на что-то сколько могли и с ними исчезали
Я понимаю, что сейчас очень трудно это себе представить, но это было очень своеобразное время. И легко считать тех вкладчиков невежественными идиотами, но это будет очень упрощенная картина
Из статьи совершенно непонятно, почему дятлы не получают сотрясения мозга. Понятно только, что предыдущая гипотеза была неверна, но в чем заключается нынешняя - неясно. Они по факту просто построили модель внутричерепного давления (причем с некоторыми довольно сильными допущениями, если вчитаться), получили результат, что давление в 2 раза меньше того, которое принято считать стандартным у человека (не у дятла) для сотрясения мозга, и всё. За счет чего это достигается - форма черепа, его размер, ещё что-то, такие же ли реально пределы травмы у дятла, будет ли иметь для дятла сотрясение мозга такие же, или более тяжелые, или более легкие последствия - они либо не смогли понять, либо даже и не пытались
Если дятлы вдруг будут сильно долбить металл, прежде чем сотрясти себе мозг, они скорее повредят себе клюв. В статье кстати про металл ничего и нет. Там упоминается только влияние твердости породы дерева на величину давления, и что её увеличение может привести к травме мозга - на качественном уровне это очевидная мысль, а никакой количественной информации там не приводится
Так всё же придумано - надо писать такой код, чтобы его могли поддерживать и другие люди помимо автора. Жесткие стандарты, отказ от велосипедов там, где это возможно, документирование архитектурных решений (хотя бы при уходе автора этих решений, в процессе разработки это я понимаю утопия). Ну и какой-то костяк должен быть, если у вас команда меняется полностью за два года - конечно, никакая документация и никакие стандарты не поможет, просто потому что не будет стимулов это поддерживать ни у одного члена команды
Если вы на любом месте работы первым делом ищете, где заменить ручной труд на автоматизацию - вы уже в IT, причем с точки зрения бизнеса в большой степени, чем большинство программистов (которые занимаются абсолютно непонятными для бизнеса вещами, и только авторитет IT-директора заставляет верить, что так надо). Хоть ваша должность этого и не предполагает.
Вам осталось только найти место, где ваш склад мыслей будет важнее, чем ваш набор скиллов. В 45 лет это непросто, но вполне возможно.
Вдобавок к тем советам, что давали выше, я бы порекомендовал вам попробовать поискать позицию владельца небольшого (для начала) продукта в области, где вы разбираетесь в предметке. Там нужно будет не писать макросы (хотя если небольшого, то и это возможно тоже), а в первую очередь понимать, какие макросы нужно написать и в какой последовательности. Мне кажется, вам интересно именно это, а не сам процесс написания, хотя возможно я и неправильно вас понял.
В команде из 20 человек у вас один дежурный превращается в продвинутый линтер скорее всего. Он не знает архитектуры этой части системы с высокой долей вероятности, он не знает подводных камней и нюансов, он не понимает этого фрагмента предметной области как следует. В итоге либо он на всё это забивает и проверяет код по чеклисту; либо автор кода ему всё это рассказывает долго и мучительно (другие авторы в это время ждут) - и хорошо если ревьюер честно просит это сделать, а не начинает выдавать замечания одно бесячее другого; либо если автор примерно таким же уровнем знаний обладает, то они совместно демонстрируют пример эффекта Даннинга-Крюгера и плохой код улетает в продакшен
Ревью кода - конечно несовершенный процесс, но его не сделаешь лучше, выплеснув вместе с его недостатками его достоинства
В маленькой команде, где у всех относительно неплохие знания обо всём (4, максимум 5 человек), такая схема будет работать, но будет обходиться очень дорого, потому что "дежурный по ревью" - это будет 20-25% ресурса; если не предполагать, что в большинстве случаев никаких доработок и не потребуется и большинство времени человек будет не ревьюить, а заниматься какими-то своими задачами - но в этом случае и никакой страшно нарисованной проблемы задержек и бесконечных циклов не будет - проверяющий быстро посмотрит, скажет ок и вернется к своим делам. Ревью откладывается на потом именно в командах, где в большинстве случаев это трудный, долгий и мучительный процесс с большим количеством итераций.
А в большой команде, где ревью много, а знания о системе распределены неравномерно, процесс, построенный по описанию в статье, выродится в одну из двух сторон в зависимости от степени добросовестности ревьюера. Либо это будет чисто формальная процедура, которая никаких багов конечно не предотвратит, кроме самых явных и тупых - будет проверено соответствие кода формальным критериям, имен переменных соглашениям и т.п.: то, что мог бы сделать линтер и человек для этого не нужен. Либо ревьюер, сидя над кодом часами - сначала сам разбираясь в нём, потом разбираясь вместе с автором, как его исправить - сам станет узким место процесса, потому что пока он ковыряется в одном реквесте, там его уже ждут ещё 5, а он должен закончить этот, чтобы бесконечных циклов и вываливаний из потока не произошло
В общем, там где описанное выглядит хорошо - нет проблемы, которую надо решать, а там где есть проблема - там оно хорошо не выглядит
Потому возможно и нет академических исследований, что когда базовые задачи в области NP-полные - никому туда лезть не хочется. Голову сложишь ни за что и никакой карьеры научной на этом не построишь
Так что придется индустрии самой разбираться
Так может между курсом доллара и сезонной миграцией журавлей действительно существует связь, только она слишком сложна, чтобы мы её аналитически установили, и поэтому мы опасаемся её использовать?
В это случае "тупой" AI может оказаться умнее "умного" человека просто за счет того, что может проанализировать огромный объем данных и чисто статистически установить действительность этой связи, не задаваясь вопросом почему эта связь вообще существует, а просто используя её в практических целях
Сборная Уэльса вышла в финал чемпионата мира во второй раз в истории, а первый был в 1958. Получается, что её выход в плэй-офф предсказан на основании того, что 64 года назад они сыграли довольно хорошо. Если бы они тогда проиграли все 3 матча - они бы и по этой модели должны были бы сыграть плохо. Очевидно, что это не имеет никакого отношения к реальной их силе
Уже из этого примера понятно, что эта модель никуда не годится
И действительно неудивительно, что чемпионом по ней стала Бразилия - это единственная сборная, которая участвовала абсолютно во всех финальных турнирах ЧМ в истории
Это скорее яркий антипаттерн - когда берется модель, неплохо подошедшая к одной задаче, и механически применяется к другой похожей, но на самом деле по сути абсолютно другой
Потому что для него разрыв строки несет смысловое значение - для него это начало нового предложения.
Видимо, авторы решили, что пользователи чаще вставляют абзацы без точки в конце, чем цельное предложение, разбитое на отдельные строки. Поскольку у них для принятия таких решений есть статистика, я бы им поверил
Тут работает принцип Парето - 80% работы занимает 20% времени. Все те 80% фич, которые можно было сделать быстро, уже давно сделали, и нынешним разработчикам достались сложные фичи, которые надо еще и накладывать на код, написанный давно и другими людьми
Ну это если не поддаваться ощущениям, что раньше трава была зеленее
По всей видимости, эта мышца не очень эффективно устроена и именно за счет этого сжигает много калорий относительно объема выполняемой работы
Меня правда ужасно смущает с точки зрения качества информации вот эта фраза "Вместо расщепления гликогена она предпочитает использовать другие виды топлива, такие как глюкоза и холестерины ". Любая мышца вместо расщепления гликогена предпочитает использовать глюкозу, потому что расщепление гликогена происходит именно с целью получить глюкозу. Это как любой человек предпочтет съесть вареные пельмени, если они есть, а не достать их из холодильника и варить.
И вот эта "А какие у вас ноги будут прокачанные". Камбаловидная мышца находится в глубине тела и сколько ее не качай - видно ее не станет
И возможно есть еще другие перлы, которые пропустил
Проблема с масштабированием в том, что разные части монолита испытывают разную нагрузку. И когда у вас какая-то часть прекрасно справляется в одном экземпляре, а другой надо сто инстансов - начинаются танцы с бубном
Я всю статью ждал, когда упомянут никарагуанскую систему адресов, но до неё так и не добрались
Кому интересно, вот здесь например есть описание
https://vianica.com/nicaragua/practical-info/14-addresses.html
Потому что все боятся cookie theft. И не зря боятся в мире, где куча народу куда угодно заходят удаленно из Бог знает каких публичных сетей не особо парясь на тему того, что они в этой публичной сети в первый раз в жизни работают и ничего не знают про её владельцев.
Судов. Суден - это так говорят про то, что лежачему больному подносят. Извините )
Архитектура (которая дома строит из дерева, камня, стекла и бетона) - искусство, наука или ремесло?
Написание битов на продажу - искусства, наука (ну это вряд ли конечно, но там тоже есть свои закономерности, которые если уловить, то будешь успешнее) или ремесло?
Анализатор крови создать, который будет делать анализы в 2 раза быстрее и/или в 2 раза точнее - искусство, наука или ремесло?
Ну и так далее
Любая классификация придумывается для упрощения. Когда что-то не лезет в классификацию - надо просто спокойно признать, что для этого "что-то" эта классификация не годится и не надо её использовать, а не впихивать невпихуемое. Потому что это не даст в данном случае никакого упрощения, следовательно непонятно, зачем на это тратить силы и время
Доллар не рос с такой скоростью, потому что его курс ещё не был достаточно свободным от регулирования и потому что инфляция была не чисто монетарной, её вызывала структурная перестройка экономики. Годовая инфляция в феврале 1994 была 600%, а курс доллара за год с февраля 1993 вырос не в 7 раз, а примерно в 3.5
Так что те, когда тогда спокойно накапливали валюту под подушкой, потеряли за год половину накопленного
Я если честно не знаю тех, кто тогда деньги спокойно складывал в тумбочку (впрочем, о наличии денег в тумбочке тогда никто и не горел желанием рассказывать по понятным причинам). Все, у кого появлялись какие-то деньги, тут же стремились их на что-нибудь потратить. Что угодно - машина, квартира, вставить зубы, вложить в какой-то бизнес. Но не спокойно сидеть на них
Люди понесли свои деньги в МММ не из-за отсутствия уроков финансовой грамотности. Вообще, чтобы догадаться, что люди, которым ты отдаешь свои деньги, могут тебя обмануть и деньги не вернуть, никакого образования не нужно, достаточно не быть кретином. Причины были совершенно в другом, я это могу оценить это как наблюдавший своими глазами - в моем окружении было очень много людей, отдававших деньги во Властилину (потому что она территориально находилась близко)
Во-первых, только что произошел ряд событий, превративший многолетние накопления в прах и продолжавший любые накопления в прах превращать: МММ начал собирать деньги в феврале 1994 года, когда годовая инфляция составляла 600%. Поэтому все искали возможность получить быстрые доходы - деньги, ни во что не вложенные, сгорали на глазах
Во-вторых, отсутствовало какое-то внятное регулирование финансовой отрасли в принципе - старое исчезло, новое ещё не выросло. Отнеся деньги в банк, вы точно так же могли через полгода этого банка уже не обнаружить.
В-третьих, отсутствовало хоть какое-то понятие деловой репутации, потому что любая фирма, которую вы могли найти, ещё три года назад точно не существовала (кроме предельных случаев вроде Сбербанка). Вы не могли сказать, что вот эта фирма ненадежна, потому что она открыта год назад - все фирмы были открыты год назад
В-четвертых, все эти МММ и Властилины реально выплачивали деньги какое-то время. И в условиях первых трех пунктов это было в принципе уже немало, потому что на порядок больше было ситуаций, когда с людей тупо собирали деньги на что-то сколько могли и с ними исчезали
Я понимаю, что сейчас очень трудно это себе представить, но это было очень своеобразное время. И легко считать тех вкладчиков невежественными идиотами, но это будет очень упрощенная картина
Из статьи совершенно непонятно, почему дятлы не получают сотрясения мозга. Понятно только, что предыдущая гипотеза была неверна, но в чем заключается нынешняя - неясно. Они по факту просто построили модель внутричерепного давления (причем с некоторыми довольно сильными допущениями, если вчитаться), получили результат, что давление в 2 раза меньше того, которое принято считать стандартным у человека (не у дятла) для сотрясения мозга, и всё. За счет чего это достигается - форма черепа, его размер, ещё что-то, такие же ли реально пределы травмы у дятла, будет ли иметь для дятла сотрясение мозга такие же, или более тяжелые, или более легкие последствия - они либо не смогли понять, либо даже и не пытались
Если дятлы вдруг будут сильно долбить металл, прежде чем сотрясти себе мозг, они скорее повредят себе клюв. В статье кстати про металл ничего и нет. Там упоминается только влияние твердости породы дерева на величину давления, и что её увеличение может привести к травме мозга - на качественном уровне это очевидная мысль, а никакой количественной информации там не приводится
Так всё же придумано - надо писать такой код, чтобы его могли поддерживать и другие люди помимо автора. Жесткие стандарты, отказ от велосипедов там, где это возможно, документирование архитектурных решений (хотя бы при уходе автора этих решений, в процессе разработки это я понимаю утопия). Ну и какой-то костяк должен быть, если у вас команда меняется полностью за два года - конечно, никакая документация и никакие стандарты не поможет, просто потому что не будет стимулов это поддерживать ни у одного члена команды
Если вы на любом месте работы первым делом ищете, где заменить ручной труд на автоматизацию - вы уже в IT, причем с точки зрения бизнеса в большой степени, чем большинство программистов (которые занимаются абсолютно непонятными для бизнеса вещами, и только авторитет IT-директора заставляет верить, что так надо). Хоть ваша должность этого и не предполагает.
Вам осталось только найти место, где ваш склад мыслей будет важнее, чем ваш набор скиллов. В 45 лет это непросто, но вполне возможно.
Вдобавок к тем советам, что давали выше, я бы порекомендовал вам попробовать поискать позицию владельца небольшого (для начала) продукта в области, где вы разбираетесь в предметке. Там нужно будет не писать макросы (хотя если небольшого, то и это возможно тоже), а в первую очередь понимать, какие макросы нужно написать и в какой последовательности. Мне кажется, вам интересно именно это, а не сам процесс написания, хотя возможно я и неправильно вас понял.