проблема не в дейли, а в том, что вы не слушаете, что говорят ваши коллеги, а ваши коллеги не прислушиваются к тому, что говорите вы.
Я почти согласен с этим, за исключением того, что я не считаю это проблемой, а скорее нормой. Почему вы считаете что это проблема?
Как вы считаете, что больше соответствует заявленным принципам аджайла (я напомню - люди важнее процессов)
Кто хочет приходит на дэйли слушает, если есть что сказать говорит, кто не хочет не участвуют/приходит, кто считает более удобным пишет в чат, что хотел сказать и читает автоматически сгенерированную стенограмму онлайн собрания.
Все ходят на дэйли, хотят не хотят не важно, все что то говорят есть что сказать или нет не важно, все хотя бы делают вид что слушает интересно или нет не важно
Не так, что кто-то делится проблемой когда он зашёл в тупик и всрал уже немало времени на безуспешные попытки решения, а сильно заранее, ещё на этапе начала решения проблемы.
Ну на самом деле, людям не очевидно, что чей либо совет сработает лучше чем их собственные идеи. Я наблюдал это неоднократно. А ещё это довольно редкая ситуация когда совет действительно дельный, а не бестолковый, собственно поэтому и не очевидно, что лучше последовать чьему то совету, а не сразу делать по своему.
Я склонен считать, что дэйли это форма микороменеджмента, которая может быть полезна если у вас в команде превалируют люди с недостатком опыта и/или у кого сложности с тайм менеджментом.
Мне кажется как то получше чем то что есть. + это должно работать как то так для присваивания
ExList = { 1, 2 } =>
if ExList.IsNull () { ExList = new() { 1, 2 } }
else { ExList.Clear(); ExList = { 1, 2 } }
И как то так для добавления
if ExList.IsNull() { ExList = new() {1, 2 } }
else { ExList.Add(1); ExList(2); }
Я не очень представляю в каком случае будет иметь смысл НЕ инициализировать объект заданными значениями если он нулл, а кидать исключение как сейчас делает такой синтаксис, ну и явный += как то заметней чем разное поведение в зависимости от отсутвия наличия new ()
Вообще как раз мнение людей не пишущих на этом языке о синтаксисе часто менее предвзяты чем мнение тех кто пишет на нем каждый день, так что зря товарища выше минусят.
Компиляторы почему-то предпочитают второе, поэтому объект мьютекса никогда не блокируется.
Ну это не так. Тот код эквивалентен
{ auto _ = std::unique_lock(m);}
Мьютекс блокируется и сразу разблокируется и это не то же самое, что он вообще не блокируется.
Формально ошибки нет, мы можем вызывать функции класса, не обращаясь к данным экземпляра этого класса. В этом конкретном случае у нас получается вырожденная функция класса.
Это тоже не верно, формальная ошибка заключается в том, что нельзя разыменовывать нулевой указатель. Мало того, современный приличный компилятор вот такой код (вместе с телом ифа) просто удалит ни на секунду не задумываясь как заведомое УБ.
Ну у нас все так и было, команда где 6-7 человек, дэйли ~10 минут, в одно и тоже время. А теперь почему я нахожу это бесполезным:
вот те советы которые мне изредка давали коллеги были не просто нейтральными, а почти всегда вредными, потому что за несколько секунд они не понимали тех проблем о которых я говорил, а мои проблемы всегда сложные, лёгкие я и так быстро решаю
Мои редкие советы, когда я точно знал в чем у них проблема, игнорировались что потом приводило к дискашенам на ревью и не понимаем зачем что то менять если и так зашибись
Большая часть того потока слов которые попадали в мои уши была обсалютно бесполезна для меня
Никакое дэйли никогда не спасет вас от вопросов от менеджера потому что у него нет времени читать джиру или спросить то же самое у ПО он просто напрямую у вас спросит все что хочет знать и не один раз и не один менеджер, правда это не часто и менеджеров не много, но бывает
Я сначало следовал ритуалу делал как говорили, смотрел как это работает и только потом меня начало от этого тошнить когда я увидел, что это не работает как минимум для меня. Но я не припомню что бы советы других членов команды не мне кому то помогали, никто не вспоминал о том что было сказано на дэйли после дэйли, я пару раз на это натыкался когда напоминал, что другой человек это уже говорил на дэйли.
Ваши описания тоже выглядят как маркетинг они обезличены, в них только положительные гипотетические кейсы - как в теории это может помочь, как из буклета по скраму, в них нет вашего личного опыта, что ещё больше заставляет меня сомневаться в них.
Как конкретно вам помогает дэйли? Почему вы верите, что другим членам команды это помогает, как вы об этом узнаете? Почему по вашему тоже самое не сработает если делать это асинхронно в общем чате, который не обязателен для немедленного чтения? А вы так пробовали? А вы пробовали вообще без дэйли? У вас есть базавая линия с которой нужно сравнивать?
Если одна сторона стучит кулаком и ставит условия в ультимативной форме, то хорошего сотрудничества не выйдет.
Так команда это те кто собственно и делает дело, при этом все обязательства никуда не уходят. Ну это как вы придёте к хирургу и начнёте с его командой (а у него команда) договариваться не о том что вам нужно, а о том как они это будет делать. Только потому что вы деньги платите.
Какая вам(как тому кто платит деньги) разница есть у них дэйли ретро и демки и какой длины спринт, если проекты движутся в правильном направлении с удовлетворительной скоростью? Это по сути аналог микороменеджмента на уровне команды. Да иногда надо, если есть проблемы и команда не может их решить сама, но если проблем нет зачем это?
есть отдельный трехнедельный спринт именно на разгребание техдолга
Я не могу говорить за всех, но у меня сложилось впечатление, что многим разработчикам на самом деле пофигу хороший код плохой код, к тому же очень часто критерий хорошести произвольный. У нас есть определение тех долга, это проблемы которые не видны пользователям, но замедляют разработку.
Дело в том, что то что замедляет меня не замедляет Васю, а то что замедляет Васю не беспокоит меня. Раньше у нас было много крашей и я починил ключевые системные вещи, это не значит что я в одиночку все починил, но я сделал то что никто другой не смог. Краши теперь редкость и я больше не вижу особого смысла что то менять фиксить тот самый долг. Да очевидно я фиксил не тех долг а краши, они по определению не тех долг, хотя все называли это тех долгом. А теперь остался тех долг и мне все равно как его будут или не будут фиксить. Оно работает, люди привыкли к тому что есть и они не хотят перепривыкать.
Да оно кривое, но работает. Да там много табличек туда не ходи этого не делай ну и что? Ну переделаем на другое и что? Будут другие таблички и по началу даже снова краши пока люди привыкнут к новому, да и самое главное я (могу ошибаться) не вижу желание у людей что то менять - работает же.
Есть конечно популисты которые мыслят лозунгами (хотя на практике свою экспертизу не подтвердили) которые готовы менять одно на другое согласно лозунгу. И мне приходиться тратить время на демократию, на разоблачение этих лозунгов в нашем случае. А когда речь идёт о действительно потенциально разумных изменениях то понимают это единицы у остальных нету хард скилов и для них это не убедительно. Это очень похоже на религиозные споры креаценистов со сторонниками эволюции.
Это я к чему, хард скилы решают, есть ли смысл в том что бы что то менять на другое или нет. При недостатке хард скилов любая элегантная система может и будет использована не так как задумывалось.
Тимлид отправился договариваться со стейкхолдерами что теперь мы им будем демонстрировать сделанное не каждые две недели, а раз в полтора месяца
Ключевая часть, для меня, в этом предложении - пошел договариваться, т.е. не проинформировал о смене спринта по решению команды, а пошел на поклон с прошением. Это конечно лучше чем бан на обсуждение, но все же до заявленных ценностей аджайла не дотягивает.
Да, сейчас много где есть перекос в обратную сторону ("софт важнее хард"), это просто вопрос времени, рано или поздно нормализуется.
Я бы хотел разделять с вами этот оптимистичный взгляд как я делал это раньше, но у меня все больше свидетельств тому, что этого не произойдет. Ну например, этот перекос начинается уже с младшей школы. С одной стороны я не против, что детей учат договариваться друг с другом да и вообще общаться, с другой стороны их забывают научить собственно дело делать и вот это мне уже не нравится. А происходит так потому что учить дело делать оказывается сложнее чем учить догавариваться, КПИ по делу выглядят сильно хуже чем КПИ по болталогии. Т.е. как раньше уже не будет, никакого баланса не будет, но это не значит, что это проблема или плохо, может быть уровень хард скилов закастылюет АИ когда нибудь, но мне это не нравится, потому что здесь и сейчас мне приходиться периодически страдать из за этого.
Бегите оттуда
Ну нет, я в полне доволен своей конторой и моим положением в ней. К тому же недавно произошли изменения в этом плане, у нас появился процес по изменению процесса, но я пока не в курсе работает это или нет. Но мне это уже мало интересно, я сменил роль с члена команды на роль свободного самурая - стаф девелопер, я теперь вне команды, у меня нет дэйли, спринтов, демо, минимум митингов и я наконец-то просто занят делом без лишних присяданий. Время от времени меня отвлекают от построения космических кораблей когда надо что то починить, а у других почему то не получается (подозреваю недостаток тех самых хард скилов), но в целом я нахожу это даже полезной сменой деятельности.
Вот чем я не доволен так это попытками сделать из меня я даже не знаю кого полу менеджера полу тех лида - у нас это называется тех домэйн гардиан. Человек который определяет курс партии по какому то широкому тех вопросу ( ну например вопрос многопоточности/асинхронщины или управления памятью или гуй и т.д.) и заодно менеджерит список тех долга тасков по этому вопросу. Болтавни очень много и меня это напрягает, а толку я пока не увидел - тех долг не уменьшается. Какая то смесь демократии (условием становления гардионом является убеждение других в верности курса) с отсутствием власти, я не смогу прийти на планирование к команде и сказать вы берете этот тикет в спринт. Я только должен грумить этот бэклог и ждать как с моря погоды, что тикеты будут браться в спринт и делаться, сам при этом я их делать не должен - передача знаний и вообще скэйлинг моих возможностей с одного юнита - меня, на много юнитов которые мне при этом не подчиняются. Я вообще не хочу вот в это все, но меня зачем то туда пихают.
Короче какая то очередная хрень из мира эффективного менеджмента в которую я не верю, но посмотрю как пойдет, может это я не прав, хорошо хоть есть с кем сравнивать, у других пока что тоже 0 результатов, так что может это все таки хрень, а не я дурак.
Я один ничего не понял? А почему собственно это проблема в случае подряда? Вот тут все пишут, что одинаковые зарплаты, точнее часовые ставки, анти стимулируют к повышению производительности. Но ведь с точки зрения подрядчика это наоборот стимулирует к повышению производительности каждого своего работника. Смотрите когда заключается договор на подряд вам как заказчику фиолетово сколько подрядчик платит своим сотрудникам, вас грубо говоря интересует только время и деньги (при фиксированном минимальном качестве). А это значит что единственный способ конкуренции среди подрядчиков остаётся эффективность сотрудников -> уменьшение их числа при равных затратах материалов. Если раньше у подрядчика была возможность конкурировать и за счёт эффективности и за счёт зарплаты сотрудников, то с этим законом остаётся только эффективность (примем что материалы и так уже самые дешёвые).
Для сотрудников тоже есть стимул к повышению эффективности, вот смотрите вы можете пойти капать лопатой к одному подрядчику и сидеть в экскаваторе у другого при одинаковой часовой ставке, что вы выберите? Да конечно, это разница выбрана для иллюстрации и реальная разница в эффективности будет не такой большой и в общем то работнику по барабану на эффективность, ему только важен комфорт и прочие плюшки ставка то зафиксированна, но деньги на комфорт и плюшки подрядчик может взять только за счёт повышения эффективности, таким образом конечные исполнители тоже опосредованно, через плюшки, заинтересованны в повышении эффективности.
Я вообще не левак от слова совсем, и мое первое впечатление от прочтения было, чо за левацкая хрень, но потом я подумал немного больше и конкретно в этом случае мне кажется это дельный закон.
Я тоже зашёл поучиться как это должно быть и не нашел ответа. Я читал что есть 2 подхода энихау и зисэрор. Иделмптически энихау применяется в конечных приложениях, а зисэрор в библиотеках. У меня технически библиотека, длл, но по факту это миниприложение, плагин, в котором уже много бизнес логики и будет ещё больше. Я делаю так, у меня есть мой тип ошибки, что типа наивный энихау, но у меня 3 категории ошибок к которым я свожу все ошибки зависимостей. Я бы взял как раз энихау, но мне нужно 3 категории, а у него только 1. Мои категории это внутренняя логическая ошибка плагина - баг плагина, ошибка на стороне хоста не валидный ввод/прекандишен ваолэйшен - баг на стороне хоста/придожения, и ошибка среды/системная/рантайм, в общем все остальное, что не папало в первые 2 категории - не баг, а просто так звёзды сложились.
И все у меня в общем то хорошо получается, я в ручную доптсываю фром для новых ошибок когда надо, довольно редко, а дальше будет ещё реже.
Но есть одна проблема, которая меня беспокоит, но как ее решить я пока не знаю - у меня есть служебный/библиотечный крэйт который потенциально можно заопенсорсить и как раз в нем находиться определение моей ошибки, а бизнес логика живёт в другом крэйте. Проблема в том что при добавлении зависимости в бизнес крэйт мне приходиться ее также добавить и в служебный, что бы я мог написать реализацию фром трэйта для новой ошибки. Других причин для добавления зависимости в служебный крэйт нет и это напрягает.
Идеально было бы реализовать фром из одной ошибки в другую в бизнес крэйте, но это не возможно т.к. обе ошибки и конечно же сам трэйт внешние по отношению к бизнес крэйту.
Ну вот я и хочу поменять, взять и сначало сделать Дэйли асинхронным, в чате команды напиши все что хочешь сказать, ну а следующим этапом хочешь пиши хочешь не пиши, хочешь читай хочешь не читай, но как вы правильно заметили, аджайл это про гибкость и то что люди важнее чем процесс и поэтому обсалютно все подобные инициативы с любым уровнем глубины на любой работе отвергаются сразу и без апеляционно.
Когда я честно говорю, что мне ваши болабольства мешают, что я не хочу знать какие у вас там успехи проблемы интересные моменты, но при этом всегда готов помочь когда спрашивают по конкретной проблеме меня, мое мнение, мою экспертизу, то это почему то я не командный персонаж и вообще токсик. А когда я предлагаю команде обсудить устаявшиеся традиции путем принятого регламента / ретро, то внезапно оказывается что есть табу на обсуждение самого процесса/регламента. Можно обсуждать что угодно только не это.
Зато те кто созывает митинги, много говорит без конкретики, делает презентации хорошие ребята им даже можно простить не самые выдающиеся результаты, только я не понимаю как это связано с командой? Я если честно вообще не очень понимаю, что конкретно имеют ввиду когда говорят команда в контексте разработки софта. Чем команда отличается от не команды? Почему вы так думаете? А какой у вас реальный опыт работы в разных рабочих культурах? А как ваш опыт может быть применен без вас?
Короче, по моему, ценность так называемой командной разработки переоценена, настоящий аджайл это что то типа рая, никто не видел, но все туда хотят попасть, а вот хард скилы почему то объявляются не то что бы не нужными, но явно второстепенными. У меня есть анекдотический опыт, когда проблем в так называемой команде нет вообще никаких если уровень хард скилов у каждого выше среднего и много свободы, ну т.е. там где профессионалы работают по аджайлу только не знают об этом модном слове. Без дэйли, без ретро, без демо, без джиры, да даже почти без совещаний. Надо обсудить что то идёшь и обсуждаешь не важно утро это день или вечер. Не хватает двух голов зовут третью, а если надо то и четвертую. Без идеи решения митинг не заканчивается как это обычно бывает при аджайле/скраме. Если человеку не интересно или не может помочь, то он так и говорит а не трати время свое и чужое. Если есть какая-то общая проблема, то оказывается можно не ждать конца спринта и ныть на ретро всей командой, а обсудить проблему сразу как только о ней стало известно и делать не как по процессу, а как надо сразу, а если снова не так ну ещё раз все переобсудить.
Вот честно этот ваш аджайл как устав в армии, вроде все красиво и правильно написано только к реальности отношения не имеет.
Изначально, был подход в основе которого были юнит тесты, что выразилось в краш рэйте 70%. Это значит 3 из 10 запусков нашего приложения заканчивались крашем. К этому моменту кодовой базе было более 6 лет. С момента смены акцента в тестах на интеграционные и авто / енд то енд прошло почти 5 лет, за это время краш рэйт стал 99,95 это значит только 1 из 2000 запусков заканчивается крашем + функционал значительно вырос. Я обсалютно убежден, что наши пользователи довольны сменой акцента наших тестов. Юниты остались, как и люди которые все ещё продолжают не понимать когда юниты действительно нужны. Забавно, то что это почему то те же самые люди которые топят за слоистые архитектуры, ну те которые дядя боб описывал, все эти контролёры, модели, одна функция не больше вашего любимого магического числа, инверсии здравого смысла под видом зависимостей и обажатели прыжков по кодо базе. Я лично не фанатик и не трогал такого вида код который работал, он для меня просто не существует, но когда мне приходилось чинить один и тот же код раз за разом, то я выпиливал все это вместе с юнит тестами.
О подгоревшей пице мне скажут кастомеры (именно во множественном числе, суть уточнения в том, что одиночные подгорания меня не обеспокоят, у нас правило 10/10 юзеров/эвентов), я заведу баг и когда придет время его фиксить я напишу ещё один тест который будет воспроизводить условия при которых пица подгорает, таким образом я удостоверюсь, что тест полезный он бес фикса будет красным. Затем исправлю код и забуду об этом.
Вы можете не верить, но код покрытый интеграционными тестами тоже покрыт на ~85%, только это не спасает от багов почему то. Забавно то, что баги возникают в том числе и в том коде который покрыт от сюда и до забора.
Покрытие это не цель, особенно покрытие бессмысленно если оно достигается моками.
Мы все знаем, что зелёные тесты не значат, что в программе нет ошибок, при любом покрытии. Зачем же нам тогда тесты? Ну вам не знаю, а нам, что бы детектировать бизнес проблемы. Не любой баг это проблема. Ну и что что пица подгорает раз в пятилетку, у одного кастомера который заказывает голый корж? Из моего опыта, интеграционные тесты это самый экономичный способ мониторить проблемы бизнеса в коде. Когда то я тоже считал, что корректность кода должна быть пре выше всего, но это не всегда разумно.
Я с вами не согласен, бизнес логику на практике (а не в выдуманном примере) можно протестировать только интеграционным тестом, юнит тесты имеют смысл только для библиотечного кода, где бизнес логики нет от слова совсем.
Все те тесты, что мнят себе юнит и пытаются в бизнес логику, по факту тестируют моки. Удаляются пачками без сожалений, но самое главное (зависит от языка конечно) могут уродовать АПИ и усложняеть реализацию, только для того, что бы согласно идеологии, писать моки, без которых не получаются юнит тесты.
Ещё раз юнит тестами не надо тестировать бизнес логику они не для этого. Юнит тестами тестируют настоящую логику, математику/вычисления, универсальные алгоритмы и структуры данных, вот тут юнит тесты незаменимы. Юнит тестами тестируют код который может работать как есть в любой прикладной области.
Для тестирования бизнес логики пользуйтесь интеграционными тестами. Бизнес логика - это оксюморон, этими словами обычно именуется самая не логичная часть(и) кода. Правила, а чаще, просто желания людей, кодируются сразу во многих слоях приложения. Так происходит по многим причинам, девелоперы не понимают предметной области и/или языка бизнеса и/или бизнес сам не способен выразить свои хотелки понятными словами и что чаще бизнес не знает чего он хочет в конечном счёте и постоянно меняет правила и требует новой реализации уже позавчера.
Когда нужны моки? Ну когда написать фэйковые зависимости сильно сложнение чем применить моки и/или фэйки работают недостаточно быстро для теста, хотя я ни того ни другого пока не встречал.
Каюсь, я написал буквально тысячи бессмысленных и беспощадных юнит тестов бизнес логики с моками стабами и вот этим вот всем. Теперь почти все мои немногочисленные тесты это интеграционные тесты.
Я видел код мобильных игр на уже давно мертву(на телефонах) j2me. Вся довольно не маленькая игра типа Соника была ровно в 1 файле и ровно 2 функциях. Первая очень короткая функция вычитывала все события от пользователя и помешала их в главный цикл. Вторая собственно главный цикл, свитч на ~70 евентов, каждое плечо в среднем ~700 строк кода. И это была типичная структура для игр тех времён на Яве. Ну т.е. метод длинною ~50К строк я видел.
Моя задача была портирование игр, с Ява на с++ и/или с телефона одного размера экрана/вида кнопок на другой, называется пост продакшн.
Я с вами согласен, но вопрос был по сути не о том. Человек искренне не понимает, а как вообще такое надо тестировать.
@Hardcoin тест был бы, довольно прост. На вход подаем один из типичных заказов. На выходе проверяем соответствие размера, топинга, соуса заказу и опционально просто наличие сыра. Смотрим, что пица запеклась, как то порезана и не голая (в коробке). Степень запекания, цвет коробки, вид нарезки категорически игнорируем, а любое явное упоминание в коде теста печи и прочих инструментов, настоятельно требуем удаления на код ревью. Никаких моков, но если нужно пишем генератор заказов/кастомера, который тупо всегда возвращает один и тот же типичный заказ, и если нужно пишем официанта который только и умеет что взять в руки эту птицу.
Даже если позже мы вынесем код по нарезке, упаковке, то ничего в тестах менять не нужно. И даже, (берегись ерись!) для функции нарезки/упаковки я бы не писал теста т.к. этот код уже покрыт этим тестом.
Я считаю, что у каждого должно быть право уйти из жизни по любому (не логичному) мотиву, ну хотят они кого-то спасти, пусть спасают. Где только все они были с вакцинацией, не очень понятно. Хотя условия того эксперимента были другими, но он был реальным, а это все конечно упражнение в математику ничего общего с реальностью не имеющего.
Эмигрировать самому и сделать выбор за своих детей, и оставить родителей, сиблингов, в качестве вознаграждения дауншифт, потеря круга общения, все того ничего что было ну и какая то вера в более хорошее будущее
Остаться, тоже в чем то потерять, наблюдать повышение температуры котла, получить не нулевой шанс поучаствовать в шоу, отказываться экстраполировать, и надеется, что все скоро наладится
Этот выбор уже многие сделали, но ещё больше откладывают его на потом. Видите, в реальности вам не известны вероятности, вам вообще мало что достоверно известно, но выбор нужно сделать, даже если вы его откладываете, существуют неизвестная вероятность таймаута, которая приравняет ваше промедление к остаться. Уехать это красная таблетка, а все прочее синяя? Я хз, в этом и есть суть реальности, никто не знает, но выбор нужно делать.
Я с вами согласен, да существует, да я, в таком случае, буду рад повлиять на ситуацию. И как вы думаете, что я выбираю? Буду ли я хорошо после этого спать? Да как младенец.
Я почти согласен с этим, за исключением того, что я не считаю это проблемой, а скорее нормой. Почему вы считаете что это проблема?
Как вы считаете, что больше соответствует заявленным принципам аджайла (я напомню - люди важнее процессов)
Кто хочет приходит на дэйли слушает, если есть что сказать говорит, кто не хочет не участвуют/приходит, кто считает более удобным пишет в чат, что хотел сказать и читает автоматически сгенерированную стенограмму онлайн собрания.
Все ходят на дэйли, хотят не хотят не важно, все что то говорят есть что сказать или нет не важно, все хотя бы делают вид что слушает интересно или нет не важно
Ну на самом деле, людям не очевидно, что чей либо совет сработает лучше чем их собственные идеи. Я наблюдал это неоднократно. А ещё это довольно редкая ситуация когда совет действительно дельный, а не бестолковый, собственно поэтому и не очевидно, что лучше последовать чьему то совету, а не сразу делать по своему.
Я склонен считать, что дэйли это форма микороменеджмента, которая может быть полезна если у вас в команде превалируют люди с недостатком опыта и/или у кого сложности с тайм менеджментом.
ExList += { 1, 2 } // add semantic
ExList = { 1, 2 } // assign semantic
Мне кажется как то получше чем то что есть. + это должно работать как то так для присваивания
ExList = { 1, 2 } =>
if ExList.IsNull () { ExList = new() { 1, 2 } }
else { ExList.Clear(); ExList = { 1, 2 } }
И как то так для добавления
if ExList.IsNull() { ExList = new() {1, 2 } }
else { ExList.Add(1); ExList(2); }
Я не очень представляю в каком случае будет иметь смысл НЕ инициализировать объект заданными значениями если он нулл, а кидать исключение как сейчас делает такой синтаксис, ну и явный += как то заметней чем разное поведение в зависимости от отсутвия наличия new ()
Вообще как раз мнение людей не пишущих на этом языке о синтаксисе часто менее предвзяты чем мнение тех кто пишет на нем каждый день, так что зря товарища выше минусят.
Ну это не так. Тот код эквивалентен
Мьютекс блокируется и сразу разблокируется и это не то же самое, что он вообще не блокируется.
Это тоже не верно, формальная ошибка заключается в том, что нельзя разыменовывать нулевой указатель. Мало того, современный приличный компилятор вот такой код (вместе с телом ифа) просто удалит ни на секунду не задумываясь как заведомое УБ.
Ну у нас все так и было, команда где 6-7 человек, дэйли ~10 минут, в одно и тоже время. А теперь почему я нахожу это бесполезным:
вот те советы которые мне изредка давали коллеги были не просто нейтральными, а почти всегда вредными, потому что за несколько секунд они не понимали тех проблем о которых я говорил, а мои проблемы всегда сложные, лёгкие я и так быстро решаю
Мои редкие советы, когда я точно знал в чем у них проблема, игнорировались что потом приводило к дискашенам на ревью и не понимаем зачем что то менять если и так зашибись
Большая часть того потока слов которые попадали в мои уши была обсалютно бесполезна для меня
Никакое дэйли никогда не спасет вас от вопросов от менеджера потому что у него нет времени читать джиру или спросить то же самое у ПО он просто напрямую у вас спросит все что хочет знать и не один раз и не один менеджер, правда это не часто и менеджеров не много, но бывает
Я сначало следовал ритуалу делал как говорили, смотрел как это работает и только потом меня начало от этого тошнить когда я увидел, что это не работает как минимум для меня. Но я не припомню что бы советы других членов команды не мне кому то помогали, никто не вспоминал о том что было сказано на дэйли после дэйли, я пару раз на это натыкался когда напоминал, что другой человек это уже говорил на дэйли.
Ваши описания тоже выглядят как маркетинг они обезличены, в них только положительные гипотетические кейсы - как в теории это может помочь, как из буклета по скраму, в них нет вашего личного опыта, что ещё больше заставляет меня сомневаться в них.
Как конкретно вам помогает дэйли? Почему вы верите, что другим членам команды это помогает, как вы об этом узнаете? Почему по вашему тоже самое не сработает если делать это асинхронно в общем чате, который не обязателен для немедленного чтения? А вы так пробовали? А вы пробовали вообще без дэйли? У вас есть базавая линия с которой нужно сравнивать?
Так команда это те кто собственно и делает дело, при этом все обязательства никуда не уходят. Ну это как вы придёте к хирургу и начнёте с его командой (а у него команда) договариваться не о том что вам нужно, а о том как они это будет делать. Только потому что вы деньги платите.
Какая вам(как тому кто платит деньги) разница есть у них дэйли ретро и демки и какой длины спринт, если проекты движутся в правильном направлении с удовлетворительной скоростью? Это по сути аналог микороменеджмента на уровне команды. Да иногда надо, если есть проблемы и команда не может их решить сама, но если проблем нет зачем это?
Я не могу говорить за всех, но у меня сложилось впечатление, что многим разработчикам на самом деле пофигу хороший код плохой код, к тому же очень часто критерий хорошести произвольный. У нас есть определение тех долга, это проблемы которые не видны пользователям, но замедляют разработку.
Дело в том, что то что замедляет меня не замедляет Васю, а то что замедляет Васю не беспокоит меня. Раньше у нас было много крашей и я починил ключевые системные вещи, это не значит что я в одиночку все починил, но я сделал то что никто другой не смог. Краши теперь редкость и я больше не вижу особого смысла что то менять фиксить тот самый долг. Да очевидно я фиксил не тех долг а краши, они по определению не тех долг, хотя все называли это тех долгом. А теперь остался тех долг и мне все равно как его будут или не будут фиксить. Оно работает, люди привыкли к тому что есть и они не хотят перепривыкать.
Да оно кривое, но работает. Да там много табличек туда не ходи этого не делай ну и что? Ну переделаем на другое и что? Будут другие таблички и по началу даже снова краши пока люди привыкнут к новому, да и самое главное я (могу ошибаться) не вижу желание у людей что то менять - работает же.
Есть конечно популисты которые мыслят лозунгами (хотя на практике свою экспертизу не подтвердили) которые готовы менять одно на другое согласно лозунгу. И мне приходиться тратить время на демократию, на разоблачение этих лозунгов в нашем случае. А когда речь идёт о действительно потенциально разумных изменениях то понимают это единицы у остальных нету хард скилов и для них это не убедительно. Это очень похоже на религиозные споры креаценистов со сторонниками эволюции.
Это я к чему, хард скилы решают, есть ли смысл в том что бы что то менять на другое или нет. При недостатке хард скилов любая элегантная система может и будет использована не так как задумывалось.
Не угадали, это был сарказм.
Ключевая часть, для меня, в этом предложении - пошел договариваться, т.е. не проинформировал о смене спринта по решению команды, а пошел на поклон с прошением. Это конечно лучше чем бан на обсуждение, но все же до заявленных ценностей аджайла не дотягивает.
Я бы хотел разделять с вами этот оптимистичный взгляд как я делал это раньше, но у меня все больше свидетельств тому, что этого не произойдет. Ну например, этот перекос начинается уже с младшей школы. С одной стороны я не против, что детей учат договариваться друг с другом да и вообще общаться, с другой стороны их забывают научить собственно дело делать и вот это мне уже не нравится. А происходит так потому что учить дело делать оказывается сложнее чем учить догавариваться, КПИ по делу выглядят сильно хуже чем КПИ по болталогии. Т.е. как раньше уже не будет, никакого баланса не будет, но это не значит, что это проблема или плохо, может быть уровень хард скилов закастылюет АИ когда нибудь, но мне это не нравится, потому что здесь и сейчас мне приходиться периодически страдать из за этого.
Ну нет, я в полне доволен своей конторой и моим положением в ней. К тому же недавно произошли изменения в этом плане, у нас появился процес по изменению процесса, но я пока не в курсе работает это или нет. Но мне это уже мало интересно, я сменил роль с члена команды на роль свободного самурая - стаф девелопер, я теперь вне команды, у меня нет дэйли, спринтов, демо, минимум митингов и я наконец-то просто занят делом без лишних присяданий. Время от времени меня отвлекают от построения космических кораблей когда надо что то починить, а у других почему то не получается (подозреваю недостаток тех самых хард скилов), но в целом я нахожу это даже полезной сменой деятельности.
Вот чем я не доволен так это попытками сделать из меня я даже не знаю кого полу менеджера полу тех лида - у нас это называется тех домэйн гардиан. Человек который определяет курс партии по какому то широкому тех вопросу ( ну например вопрос многопоточности/асинхронщины или управления памятью или гуй и т.д.) и заодно менеджерит список тех долга тасков по этому вопросу. Болтавни очень много и меня это напрягает, а толку я пока не увидел - тех долг не уменьшается. Какая то смесь демократии (условием становления гардионом является убеждение других в верности курса) с отсутствием власти, я не смогу прийти на планирование к команде и сказать вы берете этот тикет в спринт. Я только должен грумить этот бэклог и ждать как с моря погоды, что тикеты будут браться в спринт и делаться, сам при этом я их делать не должен - передача знаний и вообще скэйлинг моих возможностей с одного юнита - меня, на много юнитов которые мне при этом не подчиняются. Я вообще не хочу вот в это все, но меня зачем то туда пихают.
Короче какая то очередная хрень из мира эффективного менеджмента в которую я не верю, но посмотрю как пойдет, может это я не прав, хорошо хоть есть с кем сравнивать, у других пока что тоже 0 результатов, так что может это все таки хрень, а не я дурак.
Хорошо, допустим вы правы, расскажите пожалуйста в чем смысл дэйли и как его нужно готовить, что бы меня от него не тошнило?
Я один ничего не понял? А почему собственно это проблема в случае подряда? Вот тут все пишут, что одинаковые зарплаты, точнее часовые ставки, анти стимулируют к повышению производительности. Но ведь с точки зрения подрядчика это наоборот стимулирует к повышению производительности каждого своего работника. Смотрите когда заключается договор на подряд вам как заказчику фиолетово сколько подрядчик платит своим сотрудникам, вас грубо говоря интересует только время и деньги (при фиксированном минимальном качестве). А это значит что единственный способ конкуренции среди подрядчиков остаётся эффективность сотрудников -> уменьшение их числа при равных затратах материалов. Если раньше у подрядчика была возможность конкурировать и за счёт эффективности и за счёт зарплаты сотрудников, то с этим законом остаётся только эффективность (примем что материалы и так уже самые дешёвые).
Для сотрудников тоже есть стимул к повышению эффективности, вот смотрите вы можете пойти капать лопатой к одному подрядчику и сидеть в экскаваторе у другого при одинаковой часовой ставке, что вы выберите? Да конечно, это разница выбрана для иллюстрации и реальная разница в эффективности будет не такой большой и в общем то работнику по барабану на эффективность, ему только важен комфорт и прочие плюшки ставка то зафиксированна, но деньги на комфорт и плюшки подрядчик может взять только за счёт повышения эффективности, таким образом конечные исполнители тоже опосредованно, через плюшки, заинтересованны в повышении эффективности.
Я вообще не левак от слова совсем, и мое первое впечатление от прочтения было, чо за левацкая хрень, но потом я подумал немного больше и конкретно в этом случае мне кажется это дельный закон.
Я тоже зашёл поучиться как это должно быть и не нашел ответа. Я читал что есть 2 подхода энихау и зисэрор. Иделмптически энихау применяется в конечных приложениях, а зисэрор в библиотеках. У меня технически библиотека, длл, но по факту это миниприложение, плагин, в котором уже много бизнес логики и будет ещё больше. Я делаю так, у меня есть мой тип ошибки, что типа наивный энихау, но у меня 3 категории ошибок к которым я свожу все ошибки зависимостей. Я бы взял как раз энихау, но мне нужно 3 категории, а у него только 1. Мои категории это внутренняя логическая ошибка плагина - баг плагина, ошибка на стороне хоста не валидный ввод/прекандишен ваолэйшен - баг на стороне хоста/придожения, и ошибка среды/системная/рантайм, в общем все остальное, что не папало в первые 2 категории - не баг, а просто так звёзды сложились.
И все у меня в общем то хорошо получается, я в ручную доптсываю фром для новых ошибок когда надо, довольно редко, а дальше будет ещё реже.
Но есть одна проблема, которая меня беспокоит, но как ее решить я пока не знаю - у меня есть служебный/библиотечный крэйт который потенциально можно заопенсорсить и как раз в нем находиться определение моей ошибки, а бизнес логика живёт в другом крэйте. Проблема в том что при добавлении зависимости в бизнес крэйт мне приходиться ее также добавить и в служебный, что бы я мог написать реализацию фром трэйта для новой ошибки. Других причин для добавления зависимости в служебный крэйт нет и это напрягает.
Идеально было бы реализовать фром из одной ошибки в другую в бизнес крэйте, но это не возможно т.к. обе ошибки и конечно же сам трэйт внешние по отношению к бизнес крэйту.
Ну вот я и хочу поменять, взять и сначало сделать Дэйли асинхронным, в чате команды напиши все что хочешь сказать, ну а следующим этапом хочешь пиши хочешь не пиши, хочешь читай хочешь не читай, но как вы правильно заметили, аджайл это про гибкость и то что люди важнее чем процесс и поэтому обсалютно все подобные инициативы с любым уровнем глубины на любой работе отвергаются сразу и без апеляционно.
Когда я честно говорю, что мне ваши болабольства мешают, что я не хочу знать какие у вас там успехи проблемы интересные моменты, но при этом всегда готов помочь когда спрашивают по конкретной проблеме меня, мое мнение, мою экспертизу, то это почему то я не командный персонаж и вообще токсик. А когда я предлагаю команде обсудить устаявшиеся традиции путем принятого регламента / ретро, то внезапно оказывается что есть табу на обсуждение самого процесса/регламента. Можно обсуждать что угодно только не это.
Зато те кто созывает митинги, много говорит без конкретики, делает презентации хорошие ребята им даже можно простить не самые выдающиеся результаты, только я не понимаю как это связано с командой? Я если честно вообще не очень понимаю, что конкретно имеют ввиду когда говорят команда в контексте разработки софта. Чем команда отличается от не команды? Почему вы так думаете? А какой у вас реальный опыт работы в разных рабочих культурах? А как ваш опыт может быть применен без вас?
Короче, по моему, ценность так называемой командной разработки переоценена, настоящий аджайл это что то типа рая, никто не видел, но все туда хотят попасть, а вот хард скилы почему то объявляются не то что бы не нужными, но явно второстепенными. У меня есть анекдотический опыт, когда проблем в так называемой команде нет вообще никаких если уровень хард скилов у каждого выше среднего и много свободы, ну т.е. там где профессионалы работают по аджайлу только не знают об этом модном слове. Без дэйли, без ретро, без демо, без джиры, да даже почти без совещаний. Надо обсудить что то идёшь и обсуждаешь не важно утро это день или вечер. Не хватает двух голов зовут третью, а если надо то и четвертую. Без идеи решения митинг не заканчивается как это обычно бывает при аджайле/скраме. Если человеку не интересно или не может помочь, то он так и говорит а не трати время свое и чужое. Если есть какая-то общая проблема, то оказывается можно не ждать конца спринта и ныть на ретро всей командой, а обсудить проблему сразу как только о ней стало известно и делать не как по процессу, а как надо сразу, а если снова не так ну ещё раз все переобсудить.
Вот честно этот ваш аджайл как устав в армии, вроде все красиво и правильно написано только к реальности отношения не имеет.
У нас десктоп + эмбед на с++. Это значит любое не тривиальное приложение на плюсах падает без исключений, таков с++ с этим ничего не поделаешь.
Программист даже не догадывается, что новый код приводит к падениям, это нормально.
Магическое число к вам не имеет отношение, это отсылка к правилу где произвольным образом выбирается "правильная" длина функции в строках кода.
Изначально, был подход в основе которого были юнит тесты, что выразилось в краш рэйте 70%. Это значит 3 из 10 запусков нашего приложения заканчивались крашем. К этому моменту кодовой базе было более 6 лет. С момента смены акцента в тестах на интеграционные и авто / енд то енд прошло почти 5 лет, за это время краш рэйт стал 99,95 это значит только 1 из 2000 запусков заканчивается крашем + функционал значительно вырос. Я обсалютно убежден, что наши пользователи довольны сменой акцента наших тестов. Юниты остались, как и люди которые все ещё продолжают не понимать когда юниты действительно нужны. Забавно, то что это почему то те же самые люди которые топят за слоистые архитектуры, ну те которые дядя боб описывал, все эти контролёры, модели, одна функция не больше вашего любимого магического числа, инверсии здравого смысла под видом зависимостей и обажатели прыжков по кодо базе. Я лично не фанатик и не трогал такого вида код который работал, он для меня просто не существует, но когда мне приходилось чинить один и тот же код раз за разом, то я выпиливал все это вместе с юнит тестами.
О подгоревшей пице мне скажут кастомеры (именно во множественном числе, суть уточнения в том, что одиночные подгорания меня не обеспокоят, у нас правило 10/10 юзеров/эвентов), я заведу баг и когда придет время его фиксить я напишу ещё один тест который будет воспроизводить условия при которых пица подгорает, таким образом я удостоверюсь, что тест полезный он бес фикса будет красным. Затем исправлю код и забуду об этом.
Вы можете не верить, но код покрытый интеграционными тестами тоже покрыт на ~85%, только это не спасает от багов почему то. Забавно то, что баги возникают в том числе и в том коде который покрыт от сюда и до забора.
Покрытие это не цель, особенно покрытие бессмысленно если оно достигается моками.
Мы все знаем, что зелёные тесты не значат, что в программе нет ошибок, при любом покрытии. Зачем же нам тогда тесты? Ну вам не знаю, а нам, что бы детектировать бизнес проблемы. Не любой баг это проблема. Ну и что что пица подгорает раз в пятилетку, у одного кастомера который заказывает голый корж? Из моего опыта, интеграционные тесты это самый экономичный способ мониторить проблемы бизнеса в коде. Когда то я тоже считал, что корректность кода должна быть пре выше всего, но это не всегда разумно.
Я с вами не согласен, бизнес логику на практике (а не в выдуманном примере) можно протестировать только интеграционным тестом, юнит тесты имеют смысл только для библиотечного кода, где бизнес логики нет от слова совсем.
Все те тесты, что мнят себе юнит и пытаются в бизнес логику, по факту тестируют моки. Удаляются пачками без сожалений, но самое главное (зависит от языка конечно) могут уродовать АПИ и усложняеть реализацию, только для того, что бы согласно идеологии, писать моки, без которых не получаются юнит тесты.
Ещё раз юнит тестами не надо тестировать бизнес логику они не для этого. Юнит тестами тестируют настоящую логику, математику/вычисления, универсальные алгоритмы и структуры данных, вот тут юнит тесты незаменимы. Юнит тестами тестируют код который может работать как есть в любой прикладной области.
Для тестирования бизнес логики пользуйтесь интеграционными тестами. Бизнес логика - это оксюморон, этими словами обычно именуется самая не логичная часть(и) кода. Правила, а чаще, просто желания людей, кодируются сразу во многих слоях приложения. Так происходит по многим причинам, девелоперы не понимают предметной области и/или языка бизнеса и/или бизнес сам не способен выразить свои хотелки понятными словами и что чаще бизнес не знает чего он хочет в конечном счёте и постоянно меняет правила и требует новой реализации уже позавчера.
Когда нужны моки? Ну когда написать фэйковые зависимости сильно сложнение чем применить моки и/или фэйки работают недостаточно быстро для теста, хотя я ни того ни другого пока не встречал.
Каюсь, я написал буквально тысячи бессмысленных и беспощадных юнит тестов бизнес логики с моками стабами и вот этим вот всем. Теперь почти все мои немногочисленные тесты это интеграционные тесты.
Я видел код мобильных игр на уже давно мертву(на телефонах) j2me. Вся довольно не маленькая игра типа Соника была ровно в 1 файле и ровно 2 функциях. Первая очень короткая функция вычитывала все события от пользователя и помешала их в главный цикл. Вторая собственно главный цикл, свитч на ~70 евентов, каждое плечо в среднем ~700 строк кода. И это была типичная структура для игр тех времён на Яве. Ну т.е. метод длинною ~50К строк я видел.
Моя задача была портирование игр, с Ява на с++ и/или с телефона одного размера экрана/вида кнопок на другой, называется пост продакшн.
Я с вами согласен, но вопрос был по сути не о том. Человек искренне не понимает, а как вообще такое надо тестировать.
@Hardcoin тест был бы, довольно прост. На вход подаем один из типичных заказов. На выходе проверяем соответствие размера, топинга, соуса заказу и опционально просто наличие сыра. Смотрим, что пица запеклась, как то порезана и не голая (в коробке). Степень запекания, цвет коробки, вид нарезки категорически игнорируем, а любое явное упоминание в коде теста печи и прочих инструментов, настоятельно требуем удаления на код ревью. Никаких моков, но если нужно пишем генератор заказов/кастомера, который тупо всегда возвращает один и тот же типичный заказ, и если нужно пишем официанта который только и умеет что взять в руки эту птицу.
Даже если позже мы вынесем код по нарезке, упаковке, то ничего в тестах менять не нужно. И даже, (берегись ерись!) для функции нарезки/упаковки я бы не писал теста т.к. этот код уже покрыт этим тестом.
Может быть.
Я считаю, что у каждого должно быть право уйти из жизни по любому (не логичному) мотиву, ну хотят они кого-то спасти, пусть спасают. Где только все они были с вакцинацией, не очень понятно. Хотя условия того эксперимента были другими, но он был реальным, а это все конечно упражнение в математику ничего общего с реальностью не имеющего.
Вот вам реальный выбор:
Эмигрировать самому и сделать выбор за своих детей, и оставить родителей, сиблингов, в качестве вознаграждения дауншифт, потеря круга общения, все того ничего что было ну и какая то вера в более хорошее будущее
Остаться, тоже в чем то потерять, наблюдать повышение температуры котла, получить не нулевой шанс поучаствовать в шоу, отказываться экстраполировать, и надеется, что все скоро наладится
Этот выбор уже многие сделали, но ещё больше откладывают его на потом. Видите, в реальности вам не известны вероятности, вам вообще мало что достоверно известно, но выбор нужно сделать, даже если вы его откладываете, существуют неизвестная вероятность таймаута, которая приравняет ваше промедление к остаться. Уехать это красная таблетка, а все прочее синяя? Я хз, в этом и есть суть реальности, никто не знает, но выбор нужно делать.
Я с вами согласен, да существует, да я, в таком случае, буду рад повлиять на ситуацию. И как вы думаете, что я выбираю? Буду ли я хорошо после этого спать? Да как младенец.