Оль, привет. Рад видеть тебя и ваш опыт на Хабре! "Жги" еще!
По поводу проблемы мажорных версий и того, что разработчики с трудом их накатывают. Инструкция по обновлению – это круто, это слегка снимает проблему, но лишь слегка. Имхо, эффективнее научить разработчиков принципу Open/Closed и заставлять без особой необходимости не ломать контракты. Например, как мы это описываем вот тут. Мы просто для каждого изменения нашли аналоги, которые позволяют производить то же изменение, но минорным образом, не ломая контракт. Мы перечислили самые частые случаи, создали библиотеку. Теперь, если разработчик ломает контракт (а робот у нас это подсвечивает автоматически), то он просто заглядывает в библиотеку и заменяет свое мажорное изменение на минорное с таким же смыслом и результатом. Результат этой практики значительный - ранее у нас мажорные версии поднимались каждый релиз, причем сразу по нескольким причинам от разных разработчиков. Теперь парни поднимают мажорные версии у общего кода (например, у ДС) лишь раз в год. Т.е. мы убрали саму корневую причину ненависти от разработчиков - мажоров тупо стало на порядок меньше.
По поводу монорепозитория. Снова заглядывайте глубже - в корень проблемы. А корень в двух вещах:
в нарушении Open/Closed (описанном выше) - если не нарушать, то обратная совместимость не нарушается, контракты не нарушаются, а значит, не провоцируется каскад изменений в разных модулях. В твоем примере AST меняем по Open/Closed и ни генератор, ни валидатор переизбирать не нужно – они будут работать по старому контракту с новым AST. В этом суть модуляризации. Она не работает без OCP и обратной совместимости.
пример с AST очень прост. В реальной разработке дерево зависимостей сильно сложнее. И возникает проблема неправильного разбиения ответственностей между модулями. Но даже в этом простом примере видно еще одну большую проблему: осталась зависимость от Валидатора на Генератор. Вы вынесли некую общую часть, которая нужна обоим в AST, но при этом все равно зависимость Генератора от Валидатора осталась – ошибка разбиения ответственностей. Все зависимости Генератора от Валидатора, похоже, нужно выносить в AST, чтоб граф лишился третьей стрелки стла таким: Генератор -> AST <- Валидатор. Неправильное разделение ответственностей по модулям тоже приводит к каскадному увеличению спровоцированных ненужных изменений.
Лечите оба корня вашей проблемы и жить с мултирепами вам будет в счастье... А монорепы... в большом проекте от них проблем больше. Вы про них, видимо, уже забыли, пока жили в мультирепах, но активно в них скатываетесь :)
О! Вы знаете, про "врут быстрее, увереннее и чаще" хочется с Вами и не согласиться 😁 У меня прям коллекция "доказательств" про вред модульных тестов, про необходимость "переписывания", про спасительный рефакторинг, про х10 результат любой новой хайповой технологии, про жизненную необходимость core-команды, про ... Естественно, все – заблуждения.
В общем, книгу написать можно... А Вы говорите, только нейронки на это способны. Увы... У кого-то ж они этому научились...
Как же с этим менеджеры-то справлялись в человеческом сетапе? А еще говорят, что менеджеры бесполезны 😁
«Он потерялся и начал ходить по кругу, часами полируя какой-то один файл.» Человеки тоже любят в такое сваливаться. Они это умным словом «рефакторинг» называют. Могут и сильно дольше полировать одни и те же места 😁
Статья понравилась. 🥰
Любо-дорого смотреть, как индустрия к контролю качества несется как паровоз. Узкое горлышко будет расширено…
Подсветить пробелы – это хорошо. Но для подсвечивания недостающих тестов или наоборот излишних, используется мутационное тестирование в модульных тестах... Да, тяжелый инструмент, медленный, дорогой. Но зато опять же надежный.
Пойдет ли мутационное тестирование в скриншот-тестах – вопрос, на который я пока не искал ответа. Но в интеграционных тестах должен. Вопрос с ними будет только в цене, из-за наличия интеграций и нелинейного возрастания цены от числа связей инструмент упрется в ресурсы очень быстро...
Да, возможно, ваш инструмент тут как раз и найдет свою узкую нишу. Подсвечивать недостающее или наоборот лишнее.
Ну, ждем вторую часть! Держите в курсе, очень интересно!
Ну, и предложение дружбы финтехами все еще в силе :)
Если контракт не затронут, то тест по соответствующей строчке и не пробежит. И наоборот, если тест пробежал по строчке контракта, то он затронут. Дело не в покрытии как в единственной цифре. Дело в том, какие строчки затронуты изменением и бегает ли тест по затронутым строчкам. Если ваш тест не трогает ни одну затронутую строчку, то смысла запускать этот тест нет никакого, в нем ничего не изменилось!
Да, покрытие замеряется транзитивно: Если вьюха А, использует вьюху Б, та использует вьюху С, и если были изменения во вьюхе С, и если мой тест А затронет измененную строчку во вьюхе С, то такой тест должен быть перезапущен. (да, много если, знаю, но мысль должна быть понятна). Если же ни одна измененная транзитивно строчка не затронута – выкидываем тест из прогона. Вот вам легкая и надежная! проверка контрактов между А, Б и С через покрытие кодом.
Юнит-тесты, кстати, обязаны быть изолированы от всего, что только может быть. Поэтому в них как раз связи будут изолированы, контракты обрублены, поэтому очень большое число тестов будет отваливаться. В интеграционных и скриншот-тестах изоляции меньше, но все равно это правило работает. Оно просто будет сильно меньше отрубать тестов из прогона.
Вполне серьезно. Цена акции отражает не только прибыль, но стоимость активов. У.Баффет так свои миллиарды заработал. Он покупал компании, владеющие дорогими активами, но не генерирующие прибыль. Рыночек при этом акции оценивал дешево, т.к.не оценивал активы. Баффет после покупки компании её закрывал, а активы продавал по рыночной цене, которая превышала стоимость акций. Иногда кратно.
Поэтому, да. Построенные датацентры и атомные электростанции однозначно попадут в цену акции. И да, за это заплатят акционеры и инвесторы в том числе. Пользователи вряд ли за это будут платить.
Я думаю, что для описываемого случая в Uber не нужны ни дата-центры, ни ядерные реакторы. Это все мечты отдельных товарищей о некоем будущем, которое может и не состояться. Просто сейчас под шумиху они могут себе позволить обложить необоснованной данью первых клиентов. Налог на хайп, так сказать. Первые клиенты заплатили кучу бабла и призадумались.
Справедливости ради, тут надо отметить еще один момент. Токены сейчас стоят сильно дороже, чем они есть. На несколько порядков. Возможно, на очень много порядков.
Обусловлено это тем, что «техно-бро» (термин из соседней статьи) нужно срубить бабла поскорее и слинять. Возможно, им даже нужно построить дата-центры, закупить видео-карты (или построить собственные заводы по их производству), построить атомные электростанции и т.д. Но это все лишь для того, чтоб срубить еще больше бабла и все равно слинять.
А по факту, все использованные за 4 месяца токены стоят по цене мощности потребленной за время генерации ответа + амортизация инфраструктуры + разумный процент прибыли. Очевидно ж, что это время — копеечное. Мощность — тоже. Даже умноженная на тысячи сотрудников и на 4 месяца. Амортизация — копеечная.
Сейчас начнут в это влетать конкуренты, стоимость токенов сильно начнет падать до разумных значений.
Может все же пойти и разобраться, а удалось ли за 4 месяца освоить инструмент. А если не удалось, то почему. А если удалось и он не дал результатов, то снова почему?
Верно, а я и не говорил, что я умею. Я точно не умею.
Но утверждать, что 5 месяцев было достаточно, тоже не стоит. Может достаточно, а может на освоение этого инструмента уйдут долгие десятилетия, даже сотня лет. Как например на квантовую механику, которую докручивают и все никак не могут докрутить уже сотню лет.
Любым инструментом можно пользоваться неправильно. Любым инструментом надо учиться пользоваться. Первые попытки пользования инструментом (до освоения инструмента и правильного использования) — всегда неверные. Как долго Вы будете не попадать из лука в мишень?
Я правильно понял, что идея в том, чтобы строить науку одновременно и из постулата, что скорость света постоянна в вакууме и не зависит от скорости ни приемника, ни источника, и одновременно из отсутствия этого постулата? Т.е.мы должны строить доказательства, одновременно удовлетворяющие двум противоположным утверждениям? Это вообще возможно? 🤔
Посоветуйте, пожалуйста, вразумительную православную точку входа в эту зубодробильню. Стало интересно.
Спасибо. Да, именно так работает установка на данность. Да, это доказано. Да, в указанной мной книжке это описано. Да, люди меньше стараются, если верят, что интеллект наследуется на 80%. Где-то выше я это указывал.
По рекомендуемой Вами книге. Спасибо, ознакомлюсь. Вы не просили, но раз зашла речь, то в книге «ДНК — не приговор» Стивена Хейне аналогично приводится огромное количество исследований, которые показывают, что гены работают ооооочень по разному. Лишь крайне малая их часть работает, как переключатель «есть-нет». Львиная же доля зависят от всего, от чего угодно: от окружающей среды, от культуры, от образования, от других генов… что там было конкретно про интеллект уже не вспомню… но даже если интеллект наследуется на 80%, то остается еще 20%, за счет которых можно как Мохаммед Али хакнуть систему и обойти всех унаследованных. Мотивация для этого есть. Это доказано, как Вы сами и сказали. 🤷♂️
Возвращаем Ваш вывод про Али на Вашего Петю. Не повезло Пете, худощав он, но если он вдруг найдет ошибку в том, как все тягают веса, то он запросто поднимет больше Васи. Если Али смог хакнуть систему и законы данности, почему это не выйдет у Васи?
Оль, привет. Рад видеть тебя и ваш опыт на Хабре! "Жги" еще!
По поводу проблемы мажорных версий и того, что разработчики с трудом их накатывают. Инструкция по обновлению – это круто, это слегка снимает проблему, но лишь слегка. Имхо, эффективнее научить разработчиков принципу Open/Closed и заставлять без особой необходимости не ломать контракты. Например, как мы это описываем вот тут. Мы просто для каждого изменения нашли аналоги, которые позволяют производить то же изменение, но минорным образом, не ломая контракт. Мы перечислили самые частые случаи, создали библиотеку. Теперь, если разработчик ломает контракт (а робот у нас это подсвечивает автоматически), то он просто заглядывает в библиотеку и заменяет свое мажорное изменение на минорное с таким же смыслом и результатом.
Результат этой практики значительный - ранее у нас мажорные версии поднимались каждый релиз, причем сразу по нескольким причинам от разных разработчиков. Теперь парни поднимают мажорные версии у общего кода (например, у ДС) лишь раз в год. Т.е. мы убрали саму корневую причину ненависти от разработчиков - мажоров тупо стало на порядок меньше.
По поводу монорепозитория. Снова заглядывайте глубже - в корень проблемы. А корень в двух вещах:
в нарушении Open/Closed (описанном выше) - если не нарушать, то обратная совместимость не нарушается, контракты не нарушаются, а значит, не провоцируется каскад изменений в разных модулях. В твоем примере AST меняем по Open/Closed и ни генератор, ни валидатор переизбирать не нужно – они будут работать по старому контракту с новым AST. В этом суть модуляризации. Она не работает без OCP и обратной совместимости.
пример с AST очень прост. В реальной разработке дерево зависимостей сильно сложнее. И возникает проблема неправильного разбиения ответственностей между модулями. Но даже в этом простом примере видно еще одну большую проблему: осталась зависимость от Валидатора на Генератор. Вы вынесли некую общую часть, которая нужна обоим в AST, но при этом все равно зависимость Генератора от Валидатора осталась – ошибка разбиения ответственностей. Все зависимости Генератора от Валидатора, похоже, нужно выносить в AST, чтоб граф лишился третьей стрелки стла таким: Генератор -> AST <- Валидатор. Неправильное разделение ответственностей по модулям тоже приводит к каскадному увеличению спровоцированных ненужных изменений.
Лечите оба корня вашей проблемы и жить с мултирепами вам будет в счастье... А монорепы... в большом проекте от них проблем больше. Вы про них, видимо, уже забыли, пока жили в мультирепах, но активно в них скатываетесь :)
Голосом могу рассказать больше, если интересно.
Observer
Вспомнилось.
О! Вы знаете, про "врут быстрее, увереннее и чаще" хочется с Вами и не согласиться 😁 У меня прям коллекция "доказательств" про вред модульных тестов, про необходимость "переписывания", про спасительный рефакторинг, про х10 результат любой новой хайповой технологии, про жизненную необходимость core-команды, про ... Естественно, все – заблуждения.
В общем, книгу написать можно... А Вы говорите, только нейронки на это способны. Увы... У кого-то ж они этому научились...
Как же с этим менеджеры-то справлялись в человеческом сетапе? А еще говорят, что менеджеры бесполезны 😁
«Он потерялся и начал ходить по кругу, часами полируя какой-то один файл.» Человеки тоже любят в такое сваливаться. Они это умным словом «рефакторинг» называют. Могут и сильно дольше полировать одни и те же места 😁
Статья понравилась. 🥰
Любо-дорого смотреть, как индустрия к контролю качества несется как паровоз. Узкое горлышко будет расширено…
Спасибо, теперь понятно.
Подсветить пробелы – это хорошо. Но для подсвечивания недостающих тестов или наоборот излишних, используется мутационное тестирование в модульных тестах... Да, тяжелый инструмент, медленный, дорогой. Но зато опять же надежный.
Пойдет ли мутационное тестирование в скриншот-тестах – вопрос, на который я пока не искал ответа. Но в интеграционных тестах должен. Вопрос с ними будет только в цене, из-за наличия интеграций и нелинейного возрастания цены от числа связей инструмент упрется в ресурсы очень быстро...
Да, возможно, ваш инструмент тут как раз и найдет свою узкую нишу. Подсвечивать недостающее или наоборот лишнее.
Ну, ждем вторую часть! Держите в курсе, очень интересно!
Ну, и предложение дружбы финтехами все еще в силе :)
Но подождите...
Если контракт не затронут, то тест по соответствующей строчке и не пробежит. И наоборот, если тест пробежал по строчке контракта, то он затронут. Дело не в покрытии как в единственной цифре. Дело в том, какие строчки затронуты изменением и бегает ли тест по затронутым строчкам. Если ваш тест не трогает ни одну затронутую строчку, то смысла запускать этот тест нет никакого, в нем ничего не изменилось!
Да, покрытие замеряется транзитивно: Если вьюха А, использует вьюху Б, та использует вьюху С, и если были изменения во вьюхе С, и если мой тест А затронет измененную строчку во вьюхе С, то такой тест должен быть перезапущен. (да, много если, знаю, но мысль должна быть понятна). Если же ни одна измененная транзитивно строчка не затронута – выкидываем тест из прогона. Вот вам легкая и надежная! проверка контрактов между А, Б и С через покрытие кодом.
Юнит-тесты, кстати, обязаны быть изолированы от всего, что только может быть. Поэтому в них как раз связи будут изолированы, контракты обрублены, поэтому очень большое число тестов будет отваливаться. В интеграционных и скриншот-тестах изоляции меньше, но все равно это правило работает. Оно просто будет сильно меньше отрубать тестов из прогона.
Но дело ваше...
Так завышены или занижены? ☺️
А сами проверить?
Вот первое, что мне удалось найти из перечисленного списка…
Было бы желание. Удастся найти под Ваши запросы любой случай. Жизнь чертовски разнообразна. 🤷♂️
Вполне серьезно. Цена акции отражает не только прибыль, но стоимость активов. У.Баффет так свои миллиарды заработал. Он покупал компании, владеющие дорогими активами, но не генерирующие прибыль. Рыночек при этом акции оценивал дешево, т.к.не оценивал активы. Баффет после покупки компании её закрывал, а активы продавал по рыночной цене, которая превышала стоимость акций. Иногда кратно.
Поэтому, да. Построенные датацентры и атомные электростанции однозначно попадут в цену акции. И да, за это заплатят акционеры и инвесторы в том числе. Пользователи вряд ли за это будут платить.
Просто давайте будем понаблюдать 😉
Я думаю, что для описываемого случая в Uber не нужны ни дата-центры, ни ядерные реакторы. Это все мечты отдельных товарищей о некоем будущем, которое может и не состояться. Просто сейчас под шумиху они могут себе позволить обложить необоснованной данью первых клиентов. Налог на хайп, так сказать. Первые клиенты заплатили кучу бабла и призадумались.
Справедливости ради, тут надо отметить еще один момент. Токены сейчас стоят сильно дороже, чем они есть. На несколько порядков. Возможно, на очень много порядков.
Обусловлено это тем, что «техно-бро» (термин из соседней статьи) нужно срубить бабла поскорее и слинять. Возможно, им даже нужно построить дата-центры, закупить видео-карты (или построить собственные заводы по их производству), построить атомные электростанции и т.д. Но это все лишь для того, чтоб срубить еще больше бабла и все равно слинять.
А по факту, все использованные за 4 месяца токены стоят по цене мощности потребленной за время генерации ответа + амортизация инфраструктуры + разумный процент прибыли. Очевидно ж, что это время — копеечное. Мощность — тоже. Даже умноженная на тысячи сотрудников и на 4 месяца. Амортизация — копеечная.
Сейчас начнут в это влетать конкуренты, стоимость токенов сильно начнет падать до разумных значений.
Простите, а как заранее понять, достижима цель или нет, если её никто ранее не достигал?
И что окажется, если вдруг её когда-нибудь кто-нибудь все-таки достигнет?
Кого-то бить ногами тоже такое себе.
Может все же пойти и разобраться, а удалось ли за 4 месяца освоить инструмент. А если не удалось, то почему. А если удалось и он не дал результатов, то снова почему?
Верно, а я и не говорил, что я умею. Я точно не умею.
Но утверждать, что 5 месяцев было достаточно, тоже не стоит. Может достаточно, а может на освоение этого инструмента уйдут долгие десятилетия, даже сотня лет. Как например на квантовую механику, которую докручивают и все никак не могут докрутить уже сотню лет.
Любым инструментом можно пользоваться неправильно. Любым инструментом надо учиться пользоваться. Первые попытки пользования инструментом (до освоения инструмента и правильного использования) — всегда неверные. Как долго Вы будете не попадать из лука в мишень?
Зубодробительно, спасибо. ☺️
Ссылка из-под белых списков не открывается.
Я правильно понял, что идея в том, чтобы строить науку одновременно и из постулата, что скорость света постоянна в вакууме и не зависит от скорости ни приемника, ни источника, и одновременно из отсутствия этого постулата? Т.е.мы должны строить доказательства, одновременно удовлетворяющие двум противоположным утверждениям? Это вообще возможно? 🤔
Посоветуйте, пожалуйста, вразумительную православную точку входа в эту зубодробильню. Стало интересно.
Что ж ты, фраер, сдал назад?.. (с)
Ах, да — IPO!
Спасибо. Да, именно так работает установка на данность. Да, это доказано. Да, в указанной мной книжке это описано. Да, люди меньше стараются, если верят, что интеллект наследуется на 80%. Где-то выше я это указывал.
По рекомендуемой Вами книге. Спасибо, ознакомлюсь. Вы не просили, но раз зашла речь, то в книге «ДНК — не приговор» Стивена Хейне аналогично приводится огромное количество исследований, которые показывают, что гены работают ооооочень по разному. Лишь крайне малая их часть работает, как переключатель «есть-нет». Львиная же доля зависят от всего, от чего угодно: от окружающей среды, от культуры, от образования, от других генов… что там было конкретно про интеллект уже не вспомню… но даже если интеллект наследуется на 80%, то остается еще 20%, за счет которых можно как Мохаммед Али хакнуть систему и обойти всех унаследованных. Мотивация для этого есть. Это доказано, как Вы сами и сказали. 🤷♂️
Именно. Так и работает установка на рост.
Возвращаем Ваш вывод про Али на Вашего Петю. Не повезло Пете, худощав он, но если он вдруг найдет ошибку в том, как все тягают веса, то он запросто поднимет больше Васи. Если Али смог хакнуть систему и законы данности, почему это не выйдет у Васи?