Я один ничего не понял? А почему собственно это проблема в случае подряда? Вот тут все пишут, что одинаковые зарплаты, точнее часовые ставки, анти стимулируют к повышению производительности. Но ведь с точки зрения подрядчика это наоборот стимулирует к повышению производительности каждого своего работника. Смотрите когда заключается договор на подряд вам как заказчику фиолетово сколько подрядчик платит своим сотрудникам, вас грубо говоря интересует только время и деньги (при фиксированном минимальном качестве). А это значит что единственный способ конкуренции среди подрядчиков остаётся эффективность сотрудников -> уменьшение их числа при равных затратах материалов. Если раньше у подрядчика была возможность конкурировать и за счёт эффективности и за счёт зарплаты сотрудников, то с этим законом остаётся только эффективность (примем что материалы и так уже самые дешёвые).
Для сотрудников тоже есть стимул к повышению эффективности, вот смотрите вы можете пойти капать лопатой к одному подрядчику и сидеть в экскаваторе у другого при одинаковой часовой ставке, что вы выберите? Да конечно, это разница выбрана для иллюстрации и реальная разница в эффективности будет не такой большой и в общем то работнику по барабану на эффективность, ему только важен комфорт и прочие плюшки ставка то зафиксированна, но деньги на комфорт и плюшки подрядчик может взять только за счёт повышения эффективности, таким образом конечные исполнители тоже опосредованно, через плюшки, заинтересованны в повышении эффективности.
Я вообще не левак от слова совсем, и мое первое впечатление от прочтения было, чо за левацкая хрень, но потом я подумал немного больше и конкретно в этом случае мне кажется это дельный закон.
Я тоже зашёл поучиться как это должно быть и не нашел ответа. Я читал что есть 2 подхода энихау и зисэрор. Иделмптически энихау применяется в конечных приложениях, а зисэрор в библиотеках. У меня технически библиотека, длл, но по факту это миниприложение, плагин, в котором уже много бизнес логики и будет ещё больше. Я делаю так, у меня есть мой тип ошибки, что типа наивный энихау, но у меня 3 категории ошибок к которым я свожу все ошибки зависимостей. Я бы взял как раз энихау, но мне нужно 3 категории, а у него только 1. Мои категории это внутренняя логическая ошибка плагина - баг плагина, ошибка на стороне хоста не валидный ввод/прекандишен ваолэйшен - баг на стороне хоста/придожения, и ошибка среды/системная/рантайм, в общем все остальное, что не папало в первые 2 категории - не баг, а просто так звёзды сложились.
И все у меня в общем то хорошо получается, я в ручную доптсываю фром для новых ошибок когда надо, довольно редко, а дальше будет ещё реже.
Но есть одна проблема, которая меня беспокоит, но как ее решить я пока не знаю - у меня есть служебный/библиотечный крэйт который потенциально можно заопенсорсить и как раз в нем находиться определение моей ошибки, а бизнес логика живёт в другом крэйте. Проблема в том что при добавлении зависимости в бизнес крэйт мне приходиться ее также добавить и в служебный, что бы я мог написать реализацию фром трэйта для новой ошибки. Других причин для добавления зависимости в служебный крэйт нет и это напрягает.
Идеально было бы реализовать фром из одной ошибки в другую в бизнес крэйте, но это не возможно т.к. обе ошибки и конечно же сам трэйт внешние по отношению к бизнес крэйту.
Ну вот я и хочу поменять, взять и сначало сделать Дэйли асинхронным, в чате команды напиши все что хочешь сказать, ну а следующим этапом хочешь пиши хочешь не пиши, хочешь читай хочешь не читай, но как вы правильно заметили, аджайл это про гибкость и то что люди важнее чем процесс и поэтому обсалютно все подобные инициативы с любым уровнем глубины на любой работе отвергаются сразу и без апеляционно.
Когда я честно говорю, что мне ваши болабольства мешают, что я не хочу знать какие у вас там успехи проблемы интересные моменты, но при этом всегда готов помочь когда спрашивают по конкретной проблеме меня, мое мнение, мою экспертизу, то это почему то я не командный персонаж и вообще токсик. А когда я предлагаю команде обсудить устаявшиеся традиции путем принятого регламента / ретро, то внезапно оказывается что есть табу на обсуждение самого процесса/регламента. Можно обсуждать что угодно только не это.
Зато те кто созывает митинги, много говорит без конкретики, делает презентации хорошие ребята им даже можно простить не самые выдающиеся результаты, только я не понимаю как это связано с командой? Я если честно вообще не очень понимаю, что конкретно имеют ввиду когда говорят команда в контексте разработки софта. Чем команда отличается от не команды? Почему вы так думаете? А какой у вас реальный опыт работы в разных рабочих культурах? А как ваш опыт может быть применен без вас?
Короче, по моему, ценность так называемой командной разработки переоценена, настоящий аджайл это что то типа рая, никто не видел, но все туда хотят попасть, а вот хард скилы почему то объявляются не то что бы не нужными, но явно второстепенными. У меня есть анекдотический опыт, когда проблем в так называемой команде нет вообще никаких если уровень хард скилов у каждого выше среднего и много свободы, ну т.е. там где профессионалы работают по аджайлу только не знают об этом модном слове. Без дэйли, без ретро, без демо, без джиры, да даже почти без совещаний. Надо обсудить что то идёшь и обсуждаешь не важно утро это день или вечер. Не хватает двух голов зовут третью, а если надо то и четвертую. Без идеи решения митинг не заканчивается как это обычно бывает при аджайле/скраме. Если человеку не интересно или не может помочь, то он так и говорит а не трати время свое и чужое. Если есть какая-то общая проблема, то оказывается можно не ждать конца спринта и ныть на ретро всей командой, а обсудить проблему сразу как только о ней стало известно и делать не как по процессу, а как надо сразу, а если снова не так ну ещё раз все переобсудить.
Вот честно этот ваш аджайл как устав в армии, вроде все красиво и правильно написано только к реальности отношения не имеет.
Изначально, был подход в основе которого были юнит тесты, что выразилось в краш рэйте 70%. Это значит 3 из 10 запусков нашего приложения заканчивались крашем. К этому моменту кодовой базе было более 6 лет. С момента смены акцента в тестах на интеграционные и авто / енд то енд прошло почти 5 лет, за это время краш рэйт стал 99,95 это значит только 1 из 2000 запусков заканчивается крашем + функционал значительно вырос. Я обсалютно убежден, что наши пользователи довольны сменой акцента наших тестов. Юниты остались, как и люди которые все ещё продолжают не понимать когда юниты действительно нужны. Забавно, то что это почему то те же самые люди которые топят за слоистые архитектуры, ну те которые дядя боб описывал, все эти контролёры, модели, одна функция не больше вашего любимого магического числа, инверсии здравого смысла под видом зависимостей и обажатели прыжков по кодо базе. Я лично не фанатик и не трогал такого вида код который работал, он для меня просто не существует, но когда мне приходилось чинить один и тот же код раз за разом, то я выпиливал все это вместе с юнит тестами.
О подгоревшей пице мне скажут кастомеры (именно во множественном числе, суть уточнения в том, что одиночные подгорания меня не обеспокоят, у нас правило 10/10 юзеров/эвентов), я заведу баг и когда придет время его фиксить я напишу ещё один тест который будет воспроизводить условия при которых пица подгорает, таким образом я удостоверюсь, что тест полезный он бес фикса будет красным. Затем исправлю код и забуду об этом.
Вы можете не верить, но код покрытый интеграционными тестами тоже покрыт на ~85%, только это не спасает от багов почему то. Забавно то, что баги возникают в том числе и в том коде который покрыт от сюда и до забора.
Покрытие это не цель, особенно покрытие бессмысленно если оно достигается моками.
Мы все знаем, что зелёные тесты не значат, что в программе нет ошибок, при любом покрытии. Зачем же нам тогда тесты? Ну вам не знаю, а нам, что бы детектировать бизнес проблемы. Не любой баг это проблема. Ну и что что пица подгорает раз в пятилетку, у одного кастомера который заказывает голый корж? Из моего опыта, интеграционные тесты это самый экономичный способ мониторить проблемы бизнеса в коде. Когда то я тоже считал, что корректность кода должна быть пре выше всего, но это не всегда разумно.
Я с вами не согласен, бизнес логику на практике (а не в выдуманном примере) можно протестировать только интеграционным тестом, юнит тесты имеют смысл только для библиотечного кода, где бизнес логики нет от слова совсем.
Все те тесты, что мнят себе юнит и пытаются в бизнес логику, по факту тестируют моки. Удаляются пачками без сожалений, но самое главное (зависит от языка конечно) могут уродовать АПИ и усложняеть реализацию, только для того, что бы согласно идеологии, писать моки, без которых не получаются юнит тесты.
Ещё раз юнит тестами не надо тестировать бизнес логику они не для этого. Юнит тестами тестируют настоящую логику, математику/вычисления, универсальные алгоритмы и структуры данных, вот тут юнит тесты незаменимы. Юнит тестами тестируют код который может работать как есть в любой прикладной области.
Для тестирования бизнес логики пользуйтесь интеграционными тестами. Бизнес логика - это оксюморон, этими словами обычно именуется самая не логичная часть(и) кода. Правила, а чаще, просто желания людей, кодируются сразу во многих слоях приложения. Так происходит по многим причинам, девелоперы не понимают предметной области и/или языка бизнеса и/или бизнес сам не способен выразить свои хотелки понятными словами и что чаще бизнес не знает чего он хочет в конечном счёте и постоянно меняет правила и требует новой реализации уже позавчера.
Когда нужны моки? Ну когда написать фэйковые зависимости сильно сложнение чем применить моки и/или фэйки работают недостаточно быстро для теста, хотя я ни того ни другого пока не встречал.
Каюсь, я написал буквально тысячи бессмысленных и беспощадных юнит тестов бизнес логики с моками стабами и вот этим вот всем. Теперь почти все мои немногочисленные тесты это интеграционные тесты.
Я видел код мобильных игр на уже давно мертву(на телефонах) j2me. Вся довольно не маленькая игра типа Соника была ровно в 1 файле и ровно 2 функциях. Первая очень короткая функция вычитывала все события от пользователя и помешала их в главный цикл. Вторая собственно главный цикл, свитч на ~70 евентов, каждое плечо в среднем ~700 строк кода. И это была типичная структура для игр тех времён на Яве. Ну т.е. метод длинною ~50К строк я видел.
Моя задача была портирование игр, с Ява на с++ и/или с телефона одного размера экрана/вида кнопок на другой, называется пост продакшн.
Я с вами согласен, но вопрос был по сути не о том. Человек искренне не понимает, а как вообще такое надо тестировать.
@Hardcoin тест был бы, довольно прост. На вход подаем один из типичных заказов. На выходе проверяем соответствие размера, топинга, соуса заказу и опционально просто наличие сыра. Смотрим, что пица запеклась, как то порезана и не голая (в коробке). Степень запекания, цвет коробки, вид нарезки категорически игнорируем, а любое явное упоминание в коде теста печи и прочих инструментов, настоятельно требуем удаления на код ревью. Никаких моков, но если нужно пишем генератор заказов/кастомера, который тупо всегда возвращает один и тот же типичный заказ, и если нужно пишем официанта который только и умеет что взять в руки эту птицу.
Даже если позже мы вынесем код по нарезке, упаковке, то ничего в тестах менять не нужно. И даже, (берегись ерись!) для функции нарезки/упаковки я бы не писал теста т.к. этот код уже покрыт этим тестом.
Я считаю, что у каждого должно быть право уйти из жизни по любому (не логичному) мотиву, ну хотят они кого-то спасти, пусть спасают. Где только все они были с вакцинацией, не очень понятно. Хотя условия того эксперимента были другими, но он был реальным, а это все конечно упражнение в математику ничего общего с реальностью не имеющего.
Эмигрировать самому и сделать выбор за своих детей, и оставить родителей, сиблингов, в качестве вознаграждения дауншифт, потеря круга общения, все того ничего что было ну и какая то вера в более хорошее будущее
Остаться, тоже в чем то потерять, наблюдать повышение температуры котла, получить не нулевой шанс поучаствовать в шоу, отказываться экстраполировать, и надеется, что все скоро наладится
Этот выбор уже многие сделали, но ещё больше откладывают его на потом. Видите, в реальности вам не известны вероятности, вам вообще мало что достоверно известно, но выбор нужно сделать, даже если вы его откладываете, существуют неизвестная вероятность таймаута, которая приравняет ваше промедление к остаться. Уехать это красная таблетка, а все прочее синяя? Я хз, в этом и есть суть реальности, никто не знает, но выбор нужно делать.
Я с вами согласен, да существует, да я, в таком случае, буду рад повлиять на ситуацию. И как вы думаете, что я выбираю? Буду ли я хорошо после этого спать? Да как младенец.
Если бы не PVS-Studio, в коде так и осталась бы эта ошибка, приводящая к утечке памяти.
Все зависит от вашего определения утечки памяти. Если ваш синтетический тест повторяет структуру реального кода, то я бы не согласился с тем что это утечка, т.к. это уже конец мэйна - программа завершена. Опять же можно спорить об определениях и эта "утечка" может мешать анализу настоящих утечек с помощью дебажного алакатора, но по факту конкретно в этом случае это не утечка. Если уж совсем дотошно, то с точки зрения самого с++ это вообще не утечка при любом раскладе, т.к. утечкой язык называет аллоцированную память на которую нет ни единого валидного указателя, а тут он есть.
AMD, Intel и ARM от этого мне сразу диктует, с кем мне спать, как мне обороняться, делать ли мне аборты, идти ли мне воевать с соседом, и так далее?
А разве нет? Никогда такого не было, что бы большая компания манипулировала рынком используя свое положение, или никогда не заставляла соглашаться на кабальные условия предоставления услуг, или ни разу в истории человеку не отказывали в продаже товара потому, что он не рассово верной национальности, ну вы поняли о чем я. Что собственно помешает большим иерархиям навязывать свои кабальные условия? Свободный рынок, альтернативные компании? Вот я возьму под контроль единственный источник воды в регионе и стану требовать с вас предоставления сексуальных услуг за возможность не умереть с жажды, свободный рынок договор и все дела, не нравится ну так вон в Антарктике бесплатно напьешься. Не можешь добраться туда так обезвожен? Ахах сам себе злобный Буратино, нет серьезно что меня да и вас остановит, ну ладно у вас там в голове какие то моральные принципы, ну я то обезьяна лишённая этих когнитивных искажений, я то точно буду пытаться высушить вас до суха, и я уверен на 146% я смогу найти себе помощников, а вы не сможете это тоже гарантировано. Мне нет смысла изучать теоретические бредни, они все до единого ложные, что бы меня переубедить достаточно ровно 1 контрпримера успешного человеческого общества живущего без государства. Хотя бы исторического, но это уже не гарантия что я поменяю свое мнение. Если карта противоречит реальности то ну ее нахер такую реальность? Это похоже ваше жизненное кредо.
Я ж сказал что в сортах свободы не разбираюсь и не планирую это исправлять, меня обстрактные/идеальные идеи/утопии не увлекают, поэтому ничего посоветовать не могу. Но могу возразить вашему асампшену что люди говоря о проблемах свободы подразумевают ценность таковой. Есть и такие которым важно конкретное, а не обстрактное, ну например что бы налоги шли туда куда провозглашается они должны идти и т.д. Вы тут заливаете про какой то стартап свободы, где внезапно по какой то магии люди перестанут нарушать контракты. Вот даже ваш пример ниже про совместное решение реальных задач, все равно потребует какой то управляющей структуры иерархии, что есть суть государства, и с чего эта иерархия внезапно будет работать лучше чем текущая, а да потому что она маленькая и расти ей не выгодно - это ваще бред какой то. Иерархия возникает вследствие делегации, которая следствие специализации. Вы ж не умеете и вероятно не хотите М, а я не умею и не хочу учиться Н, вот я делегирую вам Н, а вы мне М, а потом наступает момент скэйлинга и мне нужна помощь с Н а вам с М, и мы организуем иерархии, все привет государство. Это объективная потребность для решения реальных проблем. Все известные нам формы свободных обществ застряли в доцивилизационном уровне, я там жить не хочу, и многие другие тоже. Люди жалуются и хотят одной простой вещи - соблюдения контрактов, остальное их устраивает, это по-вашему свободно заключеннный контракт на делегацию принятия решений и ответственности, все как вы любите, как я и сказал проблема в том что другая сторона систематически обманывает и что с этим делать не понятно. Ваш вариант заведомо мертво рождённый т.к. даже не признает существование проблемы не соблюдения контракта, а просто призывает заменить Х на У и получать профит.
То что бьют реже и похлёбка вкуснее уже само по себе ценность, а почему вы так про путь к свободе говорите, что у нас у всех должно возникнуть ощущение что это ценность? Не, серьезно кому эта свобода впилась? А на вашем языке, у вас пресуперпозиция о ценности свободы ничем не обоснованна. Я в сортах свободы не особо разбираюсь, но слышал что в Африке ее завались, ну т.е. есть реальные примеры того где люди стараются расправиться с государством изо всех сил, но чёт статей о переезде на ПМЖ в Сомали я как то не вижу.
И самое главное вы сами как то не стремитесь переехать туда где этой самой свободы побольше, ну например в какое нибудь экзотическое не признанное недогосударство на бывшей нефтяной платформе.
Мне кажется, те кто вас не знают, этими минусами вменяют вам скрытый призыв не раскачивать лодку, сидеть на попе ровно и не отсвечивать, короче совсем не то о чем вы пишите. Ну по простому, ваш саркастический комментарий остался не понятен массам.
Эта часть вашего языка классная, подумайте ещё об одном операторе - пайп. Пример:
fn getOptInt(x: int) -> ?int { x != 0 ? 42 / x }
x = getOptInt(42) ?| + 3; //x == 4
x = x ?| * 5 + 1 | getOptInt; //x == 2
x ?| == 2 : panic("фигня какая то")
Ну помимо сахара собственно от пайпа это ещё решает проблему _, оно становится не нужно. А если нужно (пере)именование, то можно так
x = x ? { |x; x + 5 }
Это если у вас нет аллергии на хайдинг, а если есть то вместо х придется что то другое. Поясню мысль здесь |х присваивает имя з рвалью от ?, для этого конечно блочный оператор должен иметь входной параметр, который по умолчанию юнит/войд. Много кто жалуется что оператор присваивания перевернут, вместо присваивания правой части левой он должен присваивать левую правой тогда выражения бес костылей можно делать, но это конечно радикально.
Хорошо, допустим вы правы, расскажите пожалуйста в чем смысл дэйли и как его нужно готовить, что бы меня от него не тошнило?
Я один ничего не понял? А почему собственно это проблема в случае подряда? Вот тут все пишут, что одинаковые зарплаты, точнее часовые ставки, анти стимулируют к повышению производительности. Но ведь с точки зрения подрядчика это наоборот стимулирует к повышению производительности каждого своего работника. Смотрите когда заключается договор на подряд вам как заказчику фиолетово сколько подрядчик платит своим сотрудникам, вас грубо говоря интересует только время и деньги (при фиксированном минимальном качестве). А это значит что единственный способ конкуренции среди подрядчиков остаётся эффективность сотрудников -> уменьшение их числа при равных затратах материалов. Если раньше у подрядчика была возможность конкурировать и за счёт эффективности и за счёт зарплаты сотрудников, то с этим законом остаётся только эффективность (примем что материалы и так уже самые дешёвые).
Для сотрудников тоже есть стимул к повышению эффективности, вот смотрите вы можете пойти капать лопатой к одному подрядчику и сидеть в экскаваторе у другого при одинаковой часовой ставке, что вы выберите? Да конечно, это разница выбрана для иллюстрации и реальная разница в эффективности будет не такой большой и в общем то работнику по барабану на эффективность, ему только важен комфорт и прочие плюшки ставка то зафиксированна, но деньги на комфорт и плюшки подрядчик может взять только за счёт повышения эффективности, таким образом конечные исполнители тоже опосредованно, через плюшки, заинтересованны в повышении эффективности.
Я вообще не левак от слова совсем, и мое первое впечатление от прочтения было, чо за левацкая хрень, но потом я подумал немного больше и конкретно в этом случае мне кажется это дельный закон.
Я тоже зашёл поучиться как это должно быть и не нашел ответа. Я читал что есть 2 подхода энихау и зисэрор. Иделмптически энихау применяется в конечных приложениях, а зисэрор в библиотеках. У меня технически библиотека, длл, но по факту это миниприложение, плагин, в котором уже много бизнес логики и будет ещё больше. Я делаю так, у меня есть мой тип ошибки, что типа наивный энихау, но у меня 3 категории ошибок к которым я свожу все ошибки зависимостей. Я бы взял как раз энихау, но мне нужно 3 категории, а у него только 1. Мои категории это внутренняя логическая ошибка плагина - баг плагина, ошибка на стороне хоста не валидный ввод/прекандишен ваолэйшен - баг на стороне хоста/придожения, и ошибка среды/системная/рантайм, в общем все остальное, что не папало в первые 2 категории - не баг, а просто так звёзды сложились.
И все у меня в общем то хорошо получается, я в ручную доптсываю фром для новых ошибок когда надо, довольно редко, а дальше будет ещё реже.
Но есть одна проблема, которая меня беспокоит, но как ее решить я пока не знаю - у меня есть служебный/библиотечный крэйт который потенциально можно заопенсорсить и как раз в нем находиться определение моей ошибки, а бизнес логика живёт в другом крэйте. Проблема в том что при добавлении зависимости в бизнес крэйт мне приходиться ее также добавить и в служебный, что бы я мог написать реализацию фром трэйта для новой ошибки. Других причин для добавления зависимости в служебный крэйт нет и это напрягает.
Идеально было бы реализовать фром из одной ошибки в другую в бизнес крэйте, но это не возможно т.к. обе ошибки и конечно же сам трэйт внешние по отношению к бизнес крэйту.
Ну вот я и хочу поменять, взять и сначало сделать Дэйли асинхронным, в чате команды напиши все что хочешь сказать, ну а следующим этапом хочешь пиши хочешь не пиши, хочешь читай хочешь не читай, но как вы правильно заметили, аджайл это про гибкость и то что люди важнее чем процесс и поэтому обсалютно все подобные инициативы с любым уровнем глубины на любой работе отвергаются сразу и без апеляционно.
Когда я честно говорю, что мне ваши болабольства мешают, что я не хочу знать какие у вас там успехи проблемы интересные моменты, но при этом всегда готов помочь когда спрашивают по конкретной проблеме меня, мое мнение, мою экспертизу, то это почему то я не командный персонаж и вообще токсик. А когда я предлагаю команде обсудить устаявшиеся традиции путем принятого регламента / ретро, то внезапно оказывается что есть табу на обсуждение самого процесса/регламента. Можно обсуждать что угодно только не это.
Зато те кто созывает митинги, много говорит без конкретики, делает презентации хорошие ребята им даже можно простить не самые выдающиеся результаты, только я не понимаю как это связано с командой? Я если честно вообще не очень понимаю, что конкретно имеют ввиду когда говорят команда в контексте разработки софта. Чем команда отличается от не команды? Почему вы так думаете? А какой у вас реальный опыт работы в разных рабочих культурах? А как ваш опыт может быть применен без вас?
Короче, по моему, ценность так называемой командной разработки переоценена, настоящий аджайл это что то типа рая, никто не видел, но все туда хотят попасть, а вот хард скилы почему то объявляются не то что бы не нужными, но явно второстепенными. У меня есть анекдотический опыт, когда проблем в так называемой команде нет вообще никаких если уровень хард скилов у каждого выше среднего и много свободы, ну т.е. там где профессионалы работают по аджайлу только не знают об этом модном слове. Без дэйли, без ретро, без демо, без джиры, да даже почти без совещаний. Надо обсудить что то идёшь и обсуждаешь не важно утро это день или вечер. Не хватает двух голов зовут третью, а если надо то и четвертую. Без идеи решения митинг не заканчивается как это обычно бывает при аджайле/скраме. Если человеку не интересно или не может помочь, то он так и говорит а не трати время свое и чужое. Если есть какая-то общая проблема, то оказывается можно не ждать конца спринта и ныть на ретро всей командой, а обсудить проблему сразу как только о ней стало известно и делать не как по процессу, а как надо сразу, а если снова не так ну ещё раз все переобсудить.
Вот честно этот ваш аджайл как устав в армии, вроде все красиво и правильно написано только к реальности отношения не имеет.
У нас десктоп + эмбед на с++. Это значит любое не тривиальное приложение на плюсах падает без исключений, таков с++ с этим ничего не поделаешь.
Программист даже не догадывается, что новый код приводит к падениям, это нормально.
Магическое число к вам не имеет отношение, это отсылка к правилу где произвольным образом выбирается "правильная" длина функции в строках кода.
Изначально, был подход в основе которого были юнит тесты, что выразилось в краш рэйте 70%. Это значит 3 из 10 запусков нашего приложения заканчивались крашем. К этому моменту кодовой базе было более 6 лет. С момента смены акцента в тестах на интеграционные и авто / енд то енд прошло почти 5 лет, за это время краш рэйт стал 99,95 это значит только 1 из 2000 запусков заканчивается крашем + функционал значительно вырос. Я обсалютно убежден, что наши пользователи довольны сменой акцента наших тестов. Юниты остались, как и люди которые все ещё продолжают не понимать когда юниты действительно нужны. Забавно, то что это почему то те же самые люди которые топят за слоистые архитектуры, ну те которые дядя боб описывал, все эти контролёры, модели, одна функция не больше вашего любимого магического числа, инверсии здравого смысла под видом зависимостей и обажатели прыжков по кодо базе. Я лично не фанатик и не трогал такого вида код который работал, он для меня просто не существует, но когда мне приходилось чинить один и тот же код раз за разом, то я выпиливал все это вместе с юнит тестами.
О подгоревшей пице мне скажут кастомеры (именно во множественном числе, суть уточнения в том, что одиночные подгорания меня не обеспокоят, у нас правило 10/10 юзеров/эвентов), я заведу баг и когда придет время его фиксить я напишу ещё один тест который будет воспроизводить условия при которых пица подгорает, таким образом я удостоверюсь, что тест полезный он бес фикса будет красным. Затем исправлю код и забуду об этом.
Вы можете не верить, но код покрытый интеграционными тестами тоже покрыт на ~85%, только это не спасает от багов почему то. Забавно то, что баги возникают в том числе и в том коде который покрыт от сюда и до забора.
Покрытие это не цель, особенно покрытие бессмысленно если оно достигается моками.
Мы все знаем, что зелёные тесты не значат, что в программе нет ошибок, при любом покрытии. Зачем же нам тогда тесты? Ну вам не знаю, а нам, что бы детектировать бизнес проблемы. Не любой баг это проблема. Ну и что что пица подгорает раз в пятилетку, у одного кастомера который заказывает голый корж? Из моего опыта, интеграционные тесты это самый экономичный способ мониторить проблемы бизнеса в коде. Когда то я тоже считал, что корректность кода должна быть пре выше всего, но это не всегда разумно.
Я с вами не согласен, бизнес логику на практике (а не в выдуманном примере) можно протестировать только интеграционным тестом, юнит тесты имеют смысл только для библиотечного кода, где бизнес логики нет от слова совсем.
Все те тесты, что мнят себе юнит и пытаются в бизнес логику, по факту тестируют моки. Удаляются пачками без сожалений, но самое главное (зависит от языка конечно) могут уродовать АПИ и усложняеть реализацию, только для того, что бы согласно идеологии, писать моки, без которых не получаются юнит тесты.
Ещё раз юнит тестами не надо тестировать бизнес логику они не для этого. Юнит тестами тестируют настоящую логику, математику/вычисления, универсальные алгоритмы и структуры данных, вот тут юнит тесты незаменимы. Юнит тестами тестируют код который может работать как есть в любой прикладной области.
Для тестирования бизнес логики пользуйтесь интеграционными тестами. Бизнес логика - это оксюморон, этими словами обычно именуется самая не логичная часть(и) кода. Правила, а чаще, просто желания людей, кодируются сразу во многих слоях приложения. Так происходит по многим причинам, девелоперы не понимают предметной области и/или языка бизнеса и/или бизнес сам не способен выразить свои хотелки понятными словами и что чаще бизнес не знает чего он хочет в конечном счёте и постоянно меняет правила и требует новой реализации уже позавчера.
Когда нужны моки? Ну когда написать фэйковые зависимости сильно сложнение чем применить моки и/или фэйки работают недостаточно быстро для теста, хотя я ни того ни другого пока не встречал.
Каюсь, я написал буквально тысячи бессмысленных и беспощадных юнит тестов бизнес логики с моками стабами и вот этим вот всем. Теперь почти все мои немногочисленные тесты это интеграционные тесты.
Я видел код мобильных игр на уже давно мертву(на телефонах) j2me. Вся довольно не маленькая игра типа Соника была ровно в 1 файле и ровно 2 функциях. Первая очень короткая функция вычитывала все события от пользователя и помешала их в главный цикл. Вторая собственно главный цикл, свитч на ~70 евентов, каждое плечо в среднем ~700 строк кода. И это была типичная структура для игр тех времён на Яве. Ну т.е. метод длинною ~50К строк я видел.
Моя задача была портирование игр, с Ява на с++ и/или с телефона одного размера экрана/вида кнопок на другой, называется пост продакшн.
Я с вами согласен, но вопрос был по сути не о том. Человек искренне не понимает, а как вообще такое надо тестировать.
@Hardcoin тест был бы, довольно прост. На вход подаем один из типичных заказов. На выходе проверяем соответствие размера, топинга, соуса заказу и опционально просто наличие сыра. Смотрим, что пица запеклась, как то порезана и не голая (в коробке). Степень запекания, цвет коробки, вид нарезки категорически игнорируем, а любое явное упоминание в коде теста печи и прочих инструментов, настоятельно требуем удаления на код ревью. Никаких моков, но если нужно пишем генератор заказов/кастомера, который тупо всегда возвращает один и тот же типичный заказ, и если нужно пишем официанта который только и умеет что взять в руки эту птицу.
Даже если позже мы вынесем код по нарезке, упаковке, то ничего в тестах менять не нужно. И даже, (берегись ерись!) для функции нарезки/упаковки я бы не писал теста т.к. этот код уже покрыт этим тестом.
Может быть.
Я считаю, что у каждого должно быть право уйти из жизни по любому (не логичному) мотиву, ну хотят они кого-то спасти, пусть спасают. Где только все они были с вакцинацией, не очень понятно. Хотя условия того эксперимента были другими, но он был реальным, а это все конечно упражнение в математику ничего общего с реальностью не имеющего.
Вот вам реальный выбор:
Эмигрировать самому и сделать выбор за своих детей, и оставить родителей, сиблингов, в качестве вознаграждения дауншифт, потеря круга общения, все того ничего что было ну и какая то вера в более хорошее будущее
Остаться, тоже в чем то потерять, наблюдать повышение температуры котла, получить не нулевой шанс поучаствовать в шоу, отказываться экстраполировать, и надеется, что все скоро наладится
Этот выбор уже многие сделали, но ещё больше откладывают его на потом. Видите, в реальности вам не известны вероятности, вам вообще мало что достоверно известно, но выбор нужно сделать, даже если вы его откладываете, существуют неизвестная вероятность таймаута, которая приравняет ваше промедление к остаться. Уехать это красная таблетка, а все прочее синяя? Я хз, в этом и есть суть реальности, никто не знает, но выбор нужно делать.
Я с вами согласен, да существует, да я, в таком случае, буду рад повлиять на ситуацию. И как вы думаете, что я выбираю? Буду ли я хорошо после этого спать? Да как младенец.
Все зависит от вашего определения утечки памяти. Если ваш синтетический тест повторяет структуру реального кода, то я бы не согласился с тем что это утечка, т.к. это уже конец мэйна - программа завершена. Опять же можно спорить об определениях и эта "утечка" может мешать анализу настоящих утечек с помощью дебажного алакатора, но по факту конкретно в этом случае это не утечка. Если уж совсем дотошно, то с точки зрения самого с++ это вообще не утечка при любом раскладе, т.к. утечкой язык называет аллоцированную память на которую нет ни единого валидного указателя, а тут он есть.
А разве нет? Никогда такого не было, что бы большая компания манипулировала рынком используя свое положение, или никогда не заставляла соглашаться на кабальные условия предоставления услуг, или ни разу в истории человеку не отказывали в продаже товара потому, что он не рассово верной национальности, ну вы поняли о чем я. Что собственно помешает большим иерархиям навязывать свои кабальные условия? Свободный рынок, альтернативные компании? Вот я возьму под контроль единственный источник воды в регионе и стану требовать с вас предоставления сексуальных услуг за возможность не умереть с жажды, свободный рынок договор и все дела, не нравится ну так вон в Антарктике бесплатно напьешься. Не можешь добраться туда так обезвожен? Ахах сам себе злобный Буратино, нет серьезно что меня да и вас остановит, ну ладно у вас там в голове какие то моральные принципы, ну я то обезьяна лишённая этих когнитивных искажений, я то точно буду пытаться высушить вас до суха, и я уверен на 146% я смогу найти себе помощников, а вы не сможете это тоже гарантировано. Мне нет смысла изучать теоретические бредни, они все до единого ложные, что бы меня переубедить достаточно ровно 1 контрпримера успешного человеческого общества живущего без государства. Хотя бы исторического, но это уже не гарантия что я поменяю свое мнение. Если карта противоречит реальности то ну ее нахер такую реальность? Это похоже ваше жизненное кредо.
Я ж сказал что в сортах свободы не разбираюсь и не планирую это исправлять, меня обстрактные/идеальные идеи/утопии не увлекают, поэтому ничего посоветовать не могу. Но могу возразить вашему асампшену что люди говоря о проблемах свободы подразумевают ценность таковой. Есть и такие которым важно конкретное, а не обстрактное, ну например что бы налоги шли туда куда провозглашается они должны идти и т.д. Вы тут заливаете про какой то стартап свободы, где внезапно по какой то магии люди перестанут нарушать контракты. Вот даже ваш пример ниже про совместное решение реальных задач, все равно потребует какой то управляющей структуры иерархии, что есть суть государства, и с чего эта иерархия внезапно будет работать лучше чем текущая, а да потому что она маленькая и расти ей не выгодно - это ваще бред какой то. Иерархия возникает вследствие делегации, которая следствие специализации. Вы ж не умеете и вероятно не хотите М, а я не умею и не хочу учиться Н, вот я делегирую вам Н, а вы мне М, а потом наступает момент скэйлинга и мне нужна помощь с Н а вам с М, и мы организуем иерархии, все привет государство. Это объективная потребность для решения реальных проблем. Все известные нам формы свободных обществ застряли в доцивилизационном уровне, я там жить не хочу, и многие другие тоже. Люди жалуются и хотят одной простой вещи - соблюдения контрактов, остальное их устраивает, это по-вашему свободно заключеннный контракт на делегацию принятия решений и ответственности, все как вы любите, как я и сказал проблема в том что другая сторона систематически обманывает и что с этим делать не понятно. Ваш вариант заведомо мертво рождённый т.к. даже не признает существование проблемы не соблюдения контракта, а просто призывает заменить Х на У и получать профит.
То что бьют реже и похлёбка вкуснее уже само по себе ценность, а почему вы так про путь к свободе говорите, что у нас у всех должно возникнуть ощущение что это ценность? Не, серьезно кому эта свобода впилась? А на вашем языке, у вас пресуперпозиция о ценности свободы ничем не обоснованна. Я в сортах свободы не особо разбираюсь, но слышал что в Африке ее завались, ну т.е. есть реальные примеры того где люди стараются расправиться с государством изо всех сил, но чёт статей о переезде на ПМЖ в Сомали я как то не вижу.
И самое главное вы сами как то не стремитесь переехать туда где этой самой свободы побольше, ну например в какое нибудь экзотическое не признанное недогосударство на бывшей нефтяной платформе.
Мне кажется, те кто вас не знают, этими минусами вменяют вам скрытый призыв не раскачивать лодку, сидеть на попе ровно и не отсвечивать, короче совсем не то о чем вы пишите. Ну по простому, ваш саркастический комментарий остался не понятен массам.
Эта часть вашего языка классная, подумайте ещё об одном операторе - пайп. Пример:
fn getOptInt(x: int) -> ?int { x != 0 ? 42 / x }
x = getOptInt(42) ?| + 3; //x == 4
x = x ?| * 5 + 1 | getOptInt; //x == 2
x ?| == 2 : panic("фигня какая то")
Ну помимо сахара собственно от пайпа это ещё решает проблему _, оно становится не нужно. А если нужно (пере)именование, то можно так
x = x ? { |x; x + 5 }
Это если у вас нет аллергии на хайдинг, а если есть то вместо х придется что то другое. Поясню мысль здесь |х присваивает имя з рвалью от ?, для этого конечно блочный оператор должен иметь входной параметр, который по умолчанию юнит/войд. Много кто жалуется что оператор присваивания перевернут, вместо присваивания правой части левой он должен присваивать левую правой тогда выражения бес костылей можно делать, но это конечно радикально.
x ? { | = x; x + 5 } = x;