Честно говоря не могу согласиться. Выглядит как большая подмена понятий.
Во первых частное против частного и частное против государственного это перпендикулярные правовые сферы. Частные лица не имеют законной возможности повлиять на ситуацию силовыми методами. В отличае от государственного. До определенного момента можно бороться самим но дальше придется решать через обращение соответствующие органы. Только вот мало кто хочет действительно в это ввязываться потому что все сделано для того чтобы ни у кого не возникло такого желания. Разве что анонимные доносы. Вот даже закон подъехал разрешающий силовикам вламываться куда угодно при достойной причине.
Во вторых это в конце концов ваш личный выбор. Пока ещё, мы живём в свободной стране и вы вольны выбирать где жить. Если вы живёте в доме где одни наркоманы то вам стоит задуматься о своей жизни. Вероятно пришло время что то поменять.
В третьих любой человек с определенного возраста является потенциальной причиной возникновения ЧС. К сожалению старость нас не счадит. Так и что? По вашему нужно всех потенциально опасных людей сигрегировать? Позвольте. Но ведь мы ничего не знаем и о вашем ментальном состоянии. А может вы тоже опасный? Может и вас тоже надо? Надеюсь мысль донес. Ничего личного.
То что вы предложили как ситуацию является классическим способом государства бороться с попытками народа преодолеть барьер беспомощности и побороться за власть через разделение и стравливание. Вместо того чтобы бороться люди начинают грызться друг с другом по порой надуманным причинам. Рассовым, сексуальным, половым, религиозным. И посредством подобных ситуаций оправдывать свое насилие против граждан. Потому что всегда найдется группа людей которая ненавидит опального по одной из вышесказанных причин и будет поддерживать действия государства создавая положительное инфополе. Посмотрите на Хованского.
Пример сетеров и гетеров для входных параметров. В тестах вы обычно создаёте значения параметров через сетеры и через гетеры получаете значения при выполнении->Они покрываются тестами автоматически при покрытии тестами самого реквеста. Магия.
Вы описали обычный реквест со стороны фронта к нашему бекенду. Приблизительно 20 параметров с огромным разбросом значений для многих из них. С параметрами пагинации со скрытой зависимостью от конкретного пользователя делающего запрос и общего состояния системы зависящего ещё много от чего.
Никто, находящийся в здравом уме, не будет тестировать каждый реквест для каждого значения входящего int double etc параметров. Вы будете тестировать функцию вычисления чисел Фибоначчи для каждого n ? Ну тогда вы сам себе Злостный Буратино.
Если вы не знаете какие значения важны значит вы не понимаете что делаете. Это часть искусства разработки тестов - умение определять важные пограничные условия.
Вы путаете. Тестирование всех комбинаций параметров и покрытие тестами.
Я не собираюсь гарантировать перебор всех возможных комбинаций потому что это глупость и трата времени. Я желаю гарантировать актуальные для приложения кейсы и дополнять кейсы в случае появления новых (тдд).
Это работа инженера гарантировать что он выполнил работы по внедрению нового функционала без регрессии на имевшийся ранее функционал.
100% покрытия говорит о выполнении всех веток а не всех теоретически возможных комбинаций. Ещё раз, потому что это бессмысленно и бывает только в теории. В крайне редких случаях на практике. Лично я с таким не сталкивался, но не отрицаю возможности таких случаев. Просто для них необходимо разрабатывать соответствующий подход в тестировании. Например крутящиеся вечно мутационные тесты с логированием падений и дальнейшем разборе, фиксации в тестах падающих кейсов. Даже нейронные сети с миллионами параметров умудряются тестировать вероятностными моделями. Ошибки первого/второго рода.
Пишите чистые функции. Детерминируйте состояния. Разбиваете сложные системы на независимые и простые. Разбиваете стейт машины на непересекающиеся простые.
Это все большое имхо, но в мире где 99% новых приложений это spa - аргументы о сложности и принципиальной невозможности покрывать функционал тестами малоубедительны. Ещё раз, это имхо.
Лично я не сторонник тдд и более того во многом его презираю. Особенно прицел на покрытие в 100%. Просто не нужно мешать холодное и мягкое.
Честно говоря, мне кажется я не до конца понимаю. Если разговор о том что есть глобальный контекст который неявно влияет на b и с, а так же неявно изменяется внутри то это уже само по себе 'запах' 'не идеального' архетиктурного решения. Если мы говорим что у b и с есть большой набор параметров то это совсем не проблема. Оформите несколько тест кейсов на функции со всеми пограничными условиями и просто проверяйте верное ли состояние у вас будет в результате выполнения.
Грубо говоря, у вас рекурентный алгоритм который на вход получается параметры настроек и предыдущее состояние. Оценить юнит тестами работоспособность такого, как мне кажется, не сложно.
Внутри юнит теста вы можете легко задать начальное состояние системы, выполнить функцию и оценить состояние системы после.
В рамках текущего проекта в интеграционных тестах мы используем in memory db. В базе могут быть десятки различные сетов данных (а могут и не быть например). Этим мы задаём начальное состояние системы. Далее запускаем выполнение некой функции и проверяем конечное состояние в bd. С учётом что есть множество параметров которые для системы в целом могут быть заданы через конфиги и подсасывается например из переменных окружения.
Не совсем понимаю чем мой кейс принципиально отличается от вашего. Разве что уровнем исследуемых абстракций. У вас нужно протестировать функцию изменяющую состояние чего-то. У нас нужно проверить влияние/работу апи многослойного приложения.
Справедливости ради. Проектировать нужно так чтобы реализации, конфигурации и абстракции лежали отдельно и не были жёстко связаны. Конкретно в вашем случае нужно стремиться к тому чтобы тесты было возможно независимо реализовать для c f I и отдельно для b e h и тогда ни какие комбинации вам не будут страшны. Удивитесь, но степень покрытия при этом будет те же 100%
Это под водой то и в -40? Ну как скажете товарищ. Только видится мне, что при исходных данных оценка займет по времени ровно столько же (если не больше) сколько и сама реализация. И что то мне подсказывает, что через пару месяцев менеджмент начнет подозревать что то не ладное.
Спрятав говно в другое место, и обернув его для вызова в одну строку, ситуация ни как не изменится.
Ну, начнем с того, что если писать говно то его хоть как размазывай, а суть не изменится.
Я видел контроллеры с большим и кол-вом кода, разделив его на несколько контроллеров, проблема решается.
Аналогично, могу сказать что такой подход совершенно не решает проблемы. Не то что видел такое, я с таким работаю в данный конкретный момент. Один метод может занимать по четыре сотни строк кода и это при учете что внутри вызывается пара десятков других сервисов. Что уже используется валидация через FluentValidator. Что логирование и обработка ошибок централировано вынесена в filters. Что используется мапер.
Я в свою очередь сомневаюсь в том, что польза от этого так уж велика
Мы как инженеры работаем со сложностью от которой невозможно избавиться. Ей можно пытаться манипулировать. Можно написать один метод на тысячу строк, а можно структурировать код на уровни. Вынести логику работы с базой, выделить бизнес логику, подготовку данных для отображение и закрыть все это абстракциями. Поддерживать общность и консистенцию кода, слабую связность между реализациями различных уровней. Что бы каждый кусок был прост в понимании и редактировании, но разобрав как работает один контроллер было легко понять как работают остальные.
Первый способ работы с которым учат работать в любом вузе — декомпозиция. Потому что работать с большим количеством простых вещей гораздо проще чем с чем то одним но переусложненным.
Действительно. Если проект будет жить месяц, если его не планируется поддерживать и развивать то конечно проще и целесообразнее описать весь код в контроллере и не париться. Но если планируется расширение то очень скоро вы придете к тому что разница между реализациями отдельных контроллеров начнет душить вашу архитекруту. Потому что не будет единства, не будет возможности легко вносить общность в код. Понимать каждый контролер придется с нуля потому что каждый член команды пишет по своему и смотря с какой ноги встал сегодня утром. И поверьте мне, люди чаще всего встают не с той ноги.
Личный опыт в подобных вопросах это все равно что «Синдром выжившего». И до тех пор пока вы не сталкнетесь с бизнес логикой уровня чуть выше чем «за что купил — за то продал» вряд ли удастся осознать зачем напридумали всяких там шаблонов, SOLID и написали несколько толстых книжек такие товариши как Макконел, Фаулер, Мартин.
Еще раз подчеркну: Много простого — хорошо! Сложно, но Мало — очень очень плохо! В первом случае каждый конкретный момент вы будете работать с емкой, конкретной функциональностью отдельного уровня абстрации. Во втором случае в любой момент вы будете иметь честь по локоть возиться в том самом, что вы так настойчиво не хотели скрыть за абстракциями.
В том то и дело что виноват не сам смартфон и его экран, а его «не правильное» использование. Кроме того, очень важен поглощаемый контент. Если вы играете в динамичные игры, способные вызвать у вас состояние «потока», то оторваться от них и переключить себя на что то расслабляющее будет довольно сложно.
Интересная точка зрения. Но не могу с вами согласиться, по крайней мере полностью) У китов есть язык, а гориллы, в принципе, могут понимать язык жестов. Но по какой то причине именно человек обладает сознанием способным на, казалось бы, не естественные вещи, противоречащие «относительной простоте» его мозга. Хотя конечно в живом организме нет ни чего простого) Ну если совсем грубо изложить мою мысль: табун табуреток ни когда не обретут самосознания)
Либо они очень хорошо шифруются)
как котики)
Интересен не сколько временной промежуток сколько именно формальная достаточность: какие части системы должны были появиться для успешного формирования самосознания. Собственно зная это можно будет посадить дюжину таких для общения и… пожинать плоды…
Кстати очень рекомендую филосовский роман «Генезис-2075». Довольно короткий, но очень увлекательный.
Если же придерживаться вашей точки зрения (если я все правильно понял), то сам по себе наш мозг действительно не много «круче» «СЛАБОГО» ИИ и все что мы делаем обусловлено внешними факторами влияющими на «весовые коэффициенты» наших реальных нейронов) Гены, социум и огромное количество прочих внешних факторов формирует личность как некий набор установок. Хм, в таком ключе идея уже не видится мне такой уж фантастичной.
Извиняюсь за несколько сумбурный поток сознания) Конечно я совершенно не разбираюсь в теме и кому то мои мысли могут показаться глупостью. Может быть это и правда так) Но тема довольно интересная и я не смог отказать себе в удовольствии.
Офтоп: Пойду спать с горькой мыслью что я есть всего лишь запрограммированный био-робот.
Не являюсь специалистом, но имел опыт работы с простыми нейронными сетями. Не понимаю такого восторга и сравнения с ИИ. Прежде всего «СИЛЬНЫЙ» ИИ я ассоциирую с самосознанием, а его у существующих (любых на данный момент; насколько я знаю) реализаций ИИ нет и в помине. Все это — всего лишь методы аппроксимации плотностей вероятности в некотором многомерном пространстве признаков. Все это, ну максимум, «СЛАБЫЙ» ИИ. В таком случае недалеко от тех же «ближайших соседей». Просто точность несколько выше. Тут ведь более интересный вопрос. Вот наш мог состоит казалось бы из простых клеток. Ну чего там? Аксоны, дендриты, тельце. Но в какой то момент система стала настолько сложной, что смогла осознать сама себя. Внимание вопрос: В какой момент это произошло? То есть в какой момент система становится достаточно сложной для подобного? Было бы интересно спросить у сведущих в этом людей.
Большое имхо, но… Не взлетит ибо сложно. Очень сложная концепция. Рядовой пользователь (Я) не любит напрягаться. Чем проще тем лучше! А тут столько всего… покупать однозначно не буду.
Я не спец, и ни в коем случае не утверждаю что ИНС работает так же как реальный мозг, но, вроде бы, есть такое понятие как «связность нейронов». Так что скорее согласен с товарищем vmchaz
Честно говоря не могу согласиться. Выглядит как большая подмена понятий.
Во первых частное против частного и частное против государственного это перпендикулярные правовые сферы. Частные лица не имеют законной возможности повлиять на ситуацию силовыми методами. В отличае от государственного. До определенного момента можно бороться самим но дальше придется решать через обращение соответствующие органы. Только вот мало кто хочет действительно в это ввязываться потому что все сделано для того чтобы ни у кого не возникло такого желания. Разве что анонимные доносы. Вот даже закон подъехал разрешающий силовикам вламываться куда угодно при достойной причине.
Во вторых это в конце концов ваш личный выбор. Пока ещё, мы живём в свободной стране и вы вольны выбирать где жить. Если вы живёте в доме где одни наркоманы то вам стоит задуматься о своей жизни. Вероятно пришло время что то поменять.
В третьих любой человек с определенного возраста является потенциальной причиной возникновения ЧС. К сожалению старость нас не счадит. Так и что? По вашему нужно всех потенциально опасных людей сигрегировать? Позвольте. Но ведь мы ничего не знаем и о вашем ментальном состоянии. А может вы тоже опасный? Может и вас тоже надо? Надеюсь мысль донес. Ничего личного.
То что вы предложили как ситуацию является классическим способом государства бороться с попытками народа преодолеть барьер беспомощности и побороться за власть через разделение и стравливание. Вместо того чтобы бороться люди начинают грызться друг с другом по порой надуманным причинам. Рассовым, сексуальным, половым, религиозным. И посредством подобных ситуаций оправдывать свое насилие против граждан. Потому что всегда найдется группа людей которая ненавидит опального по одной из вышесказанных причин и будет поддерживать действия государства создавая положительное инфополе. Посмотрите на Хованского.
Ответил выше.
Добавлю про сетеры и гетеры.
Пример сетеров и гетеров для входных параметров. В тестах вы обычно создаёте значения параметров через сетеры и через гетеры получаете значения при выполнении->Они покрываются тестами автоматически при покрытии тестами самого реквеста. Магия.
Вы описали обычный реквест со стороны фронта к нашему бекенду. Приблизительно 20 параметров с огромным разбросом значений для многих из них. С параметрами пагинации со скрытой зависимостью от конкретного пользователя делающего запрос и общего состояния системы зависящего ещё много от чего.
Никто, находящийся в здравом уме, не будет тестировать каждый реквест для каждого значения входящего int double etc параметров. Вы будете тестировать функцию вычисления чисел Фибоначчи для каждого n ? Ну тогда вы сам себе Злостный Буратино.
Если вы не знаете какие значения важны значит вы не понимаете что делаете. Это часть искусства разработки тестов - умение определять важные пограничные условия.
Вы путаете. Тестирование всех комбинаций параметров и покрытие тестами.
Я не собираюсь гарантировать перебор всех возможных комбинаций потому что это глупость и трата времени. Я желаю гарантировать актуальные для приложения кейсы и дополнять кейсы в случае появления новых (тдд).
Это работа инженера гарантировать что он выполнил работы по внедрению нового функционала без регрессии на имевшийся ранее функционал.
100% покрытия говорит о выполнении всех веток а не всех теоретически возможных комбинаций. Ещё раз, потому что это бессмысленно и бывает только в теории. В крайне редких случаях на практике. Лично я с таким не сталкивался, но не отрицаю возможности таких случаев. Просто для них необходимо разрабатывать соответствующий подход в тестировании. Например крутящиеся вечно мутационные тесты с логированием падений и дальнейшем разборе, фиксации в тестах падающих кейсов. Даже нейронные сети с миллионами параметров умудряются тестировать вероятностными моделями. Ошибки первого/второго рода.
Пишите чистые функции. Детерминируйте состояния. Разбиваете сложные системы на независимые и простые. Разбиваете стейт машины на непересекающиеся простые.
Это все большое имхо, но в мире где 99% новых приложений это spa - аргументы о сложности и принципиальной невозможности покрывать функционал тестами малоубедительны. Ещё раз, это имхо.
Лично я не сторонник тдд и более того во многом его презираю. Особенно прицел на покрытие в 100%. Просто не нужно мешать холодное и мягкое.
Честно говоря, мне кажется я не до конца понимаю. Если разговор о том что есть глобальный контекст который неявно влияет на b и с, а так же неявно изменяется внутри то это уже само по себе 'запах' 'не идеального' архетиктурного решения. Если мы говорим что у b и с есть большой набор параметров то это совсем не проблема. Оформите несколько тест кейсов на функции со всеми пограничными условиями и просто проверяйте верное ли состояние у вас будет в результате выполнения.
Грубо говоря, у вас рекурентный алгоритм который на вход получается параметры настроек и предыдущее состояние. Оценить юнит тестами работоспособность такого, как мне кажется, не сложно.
Внутри юнит теста вы можете легко задать начальное состояние системы, выполнить функцию и оценить состояние системы после.
В рамках текущего проекта в интеграционных тестах мы используем in memory db. В базе могут быть десятки различные сетов данных (а могут и не быть например). Этим мы задаём начальное состояние системы. Далее запускаем выполнение некой функции и проверяем конечное состояние в bd. С учётом что есть множество параметров которые для системы в целом могут быть заданы через конфиги и подсасывается например из переменных окружения.
Не совсем понимаю чем мой кейс принципиально отличается от вашего. Разве что уровнем исследуемых абстракций. У вас нужно протестировать функцию изменяющую состояние чего-то. У нас нужно проверить влияние/работу апи многослойного приложения.
1)unit test for real_implementation_b
2)unit test for real_implementation_c
3)unit test for a == true if(a) stub_implementation_b(); else wrong_way_implementation_c();
4)unit test for a == false if(a) wrong_way_implementation_b(); stub_implementation_c();
Справедливости ради. Проектировать нужно так чтобы реализации, конфигурации и абстракции лежали отдельно и не были жёстко связаны. Конкретно в вашем случае нужно стремиться к тому чтобы тесты было возможно независимо реализовать для c f I и отдельно для b e h и тогда ни какие комбинации вам не будут страшны. Удивитесь, но степень покрытия при этом будет те же 100%
Это под водой то и в -40? Ну как скажете товарищ. Только видится мне, что при исходных данных оценка займет по времени ровно столько же (если не больше) сколько и сама реализация. И что то мне подсказывает, что через пару месяцев менеджмент начнет подозревать что то не ладное.
Надеюсь это сарказм. Опыт более 6+ лет. Я дно. Знаю очень много примеров когда все ещё хуже.
Аналогично, могу сказать что такой подход совершенно не решает проблемы. Не то что видел такое, я с таким работаю в данный конкретный момент. Один метод может занимать по четыре сотни строк кода и это при учете что внутри вызывается пара десятков других сервисов. Что уже используется валидация через FluentValidator. Что логирование и обработка ошибок централировано вынесена в filters. Что используется мапер.
Мы как инженеры работаем со сложностью от которой невозможно избавиться. Ей можно пытаться манипулировать. Можно написать один метод на тысячу строк, а можно структурировать код на уровни. Вынести логику работы с базой, выделить бизнес логику, подготовку данных для отображение и закрыть все это абстракциями. Поддерживать общность и консистенцию кода, слабую связность между реализациями различных уровней. Что бы каждый кусок был прост в понимании и редактировании, но разобрав как работает один контроллер было легко понять как работают остальные.
Первый способ работы с которым учат работать в любом вузе — декомпозиция. Потому что работать с большим количеством простых вещей гораздо проще чем с чем то одним но переусложненным.
Действительно. Если проект будет жить месяц, если его не планируется поддерживать и развивать то конечно проще и целесообразнее описать весь код в контроллере и не париться. Но если планируется расширение то очень скоро вы придете к тому что разница между реализациями отдельных контроллеров начнет душить вашу архитекруту. Потому что не будет единства, не будет возможности легко вносить общность в код. Понимать каждый контролер придется с нуля потому что каждый член команды пишет по своему и смотря с какой ноги встал сегодня утром. И поверьте мне, люди чаще всего встают не с той ноги.
Личный опыт в подобных вопросах это все равно что «Синдром выжившего». И до тех пор пока вы не сталкнетесь с бизнес логикой уровня чуть выше чем «за что купил — за то продал» вряд ли удастся осознать зачем напридумали всяких там шаблонов, SOLID и написали несколько толстых книжек такие товариши как Макконел, Фаулер, Мартин.
Еще раз подчеркну: Много простого — хорошо! Сложно, но Мало — очень очень плохо! В первом случае каждый конкретный момент вы будете работать с емкой, конкретной функциональностью отдельного уровня абстрации. Во втором случае в любой момент вы будете иметь честь по локоть возиться в том самом, что вы так настойчиво не хотели скрыть за абстракциями.
Тут интереснее что будет если user = null? Что скажет стектрейс?
Интересен не сколько временной промежуток сколько именно формальная достаточность: какие части системы должны были появиться для успешного формирования самосознания. Собственно зная это можно будет посадить дюжину таких для общения и… пожинать плоды…
Кстати очень рекомендую филосовский роман «Генезис-2075». Довольно короткий, но очень увлекательный.
Если же придерживаться вашей точки зрения (если я все правильно понял), то сам по себе наш мозг действительно не много «круче» «СЛАБОГО» ИИ и все что мы делаем обусловлено внешними факторами влияющими на «весовые коэффициенты» наших реальных нейронов) Гены, социум и огромное количество прочих внешних факторов формирует личность как некий набор установок. Хм, в таком ключе идея уже не видится мне такой уж фантастичной.
Извиняюсь за несколько сумбурный поток сознания) Конечно я совершенно не разбираюсь в теме и кому то мои мысли могут показаться глупостью. Может быть это и правда так) Но тема довольно интересная и я не смог отказать себе в удовольствии.
Офтоп: Пойду спать с горькой мыслью что я есть всего лишь запрограммированный био-робот.