мне бросилось в глаза, что...
Алла, я не знаю, конечно, как у вас работа поставлена. У нас проверка на ту же перфомантность - стандарт. Все остальное тоже проверяется.
Алла имеет в виду автоматизированные проверки
измерить производительность там уже не получится, ее даже живым людям не так легко оценить
Настя, что означает "нормально"?
Программа работает без видимых ошибок и выдаёт в конце: тёплое и мягкое?
Да может в конце кода просто написано:
Print тёплое мягкое;
😎😎
Алла вероятно имела в виду нечто вроде http://swreflections.blogspot.de/2015/01/we-cant-measure-p... http://dev9.com/article/2015/1/the-myth-of-developer-produ...
Но большая часть этих попыток осталась в 90-х. Тогда же возникли такие бестселлеры как "Death March" и "Herding Cats". Типа попытки оценивать программера по количеству написанного кода. Но да, есть и метрики типа качества. Вроде test coverage.
измерить производительность там уже не получится, ее даже живым людям не так легко оценить
Конечно же есть много инструментов для автоматизированного измерения производительности софта. У нас например response time для бекенда мониторится круглосуточно и в случае выпадения за установленные границы все заинтересованные люди моментально получают уведомления.
то, о чем ты пишешь, это уже не разработка, а maintenance
я о производительности написанного кода, а не моментальных величинах в бою.
Ну так и перед релизом производительность меряется автоматизированными средствами тоже. Это как контрпример тому, что ты написал, что мол нет такого.
И? Ну я писал какие-то вещи с откликом в 5мс, где другим требовалось 140мс. И как мы узнаем, что можно сделать 5, если люди всегда видели 140? Ну да, поставим автомат с рассылкой на 150мс, и никогда не узнаем, что можно было сделать 5.
дело даже не в этом.
откуда берутся 140? 140 есть в аналогичной задаче, а тут ты выдаешь 5, но только это еще не значит, что твои 5 - это шедевр, если возможно 1-2мс.
у вас инструментарий, а у меня после каждого апдейта смартфон об угол йопнуть хочется. Причем что там сделали - непонятно, пара рюшечек всего.
Другим требовалось 140мс - это как? 140мс мс были acceptance criteria? Значит, бизнес решил, что этого достаточно, например, потому что для конечного пользователя такое время отклика незаметно. И может быть твое усовершенствование до 5мс с точки зрения бизнеса было бесполезной тратой денег и ты вместо этого мог сделать что-то более полезное?
Пошли баззворды )) Одна из моих специализаций - performance optimierung. Такого человека как правило зовут когда смартфон уже йопнули об угол )
это в эту сторону оно нормально,
а вот представь, вы - надуватели щёчек решили, что 140 допустимо, а в том месте, как ни крути, меньше 300 не вытащить?
и все, разработчик - кафно, т.к. ваши эффективные тесты не прошел?
Ну вот. А проектировали бы правильно, с привлечением нужных инструментов и метрик, не надо было бы звать чип&дейлов.
вы - надуватели щёчек решили
Ээ, чейто. Я как раз в рядах пролетариев.
решили, что 140 допустимо, а в том месте, как ни крути, меньше 300 не вытащить
Ну если менеджмент идиоты и цифры с потолка берут, то вопрос уже переходит в политическую плоскость))
даже еще более возрастает. На порядки!
Ты по диагонали что ли читаешь? Пишем об одном и том же, но тебе почему то поспорить нужно)))
но разве ты не в курсе чья подпись кроме разработчика стоит на каждом этапе прохождения разработки продукта?
Практически все они ставятся из-за доверия разработчику. Потому как я уже сказал, оценить правильность технических решений на этапе разработки может только разработчик более высокого уровня, но не девочка-формалист из какого-то отдела..
Во первых на личности я бы предложила не переходить- чревато, но за "девочку " конечно спасибо, если ты имел меня в виду. :-) Только ты ошибся, я не формалист, а что ни на есть практик, который разгребает косяки, в том числе и разработчиков.
По идее отдел качества вроде бы как и не нужен- потому что наша цель : 0 ррм. Также примерно как и пожарные не нужны. Потому что сложно риск предсказать заранее и пожары не должны происходить, также как и ошибки не совершаться. Но реальность почему то другая.
Поэтому еще раз- я нисколько не умаляю важность конструкторов ( я тоже имею к этому самое прямое отношение- забыл какое у меня образование и опыт?)) Но..
ПРоизводство это механизм, где все взаимосвязяно. Не придумают маркетологи новый продукт, а сбыт кому продать- кому нужны будут твои разработки сферического коня в вакууме?
Не заставляй меня убедиться в мнении, что чьи- то амбиции не соответсвуют амуниции. Я потом тебе картинку по теме скину, у тебя очень узкий взгляд на тему.
Ну-ну. Вот только протестировать на начальном наборе фич и тестовых данных это одно, а когда приложение обрастёт кодом и данными клиентов - это совсем другое. Uber вон несколько лет жужжал на постгресе и не жаловался (ок, жаловался немного). И вдруг выясняется, что к концу года постгрес не сможет более обеспечивать работу фирмы. Пришлось срочно мигрировать на mysql и писать обертки сверху.
Примеров проектов с факапами я тоже много могу привести. Их в разработке софта чуть больше, чем каждый. Иногда такое говнище мамонта можно откопать, что хоть в кунсткамеру. И отсутствие масштабируемости - ещё не самый худший вариант.
Ну если менеджмент идиоты и цифры с потолка берут, то вопрос уже переходит в политическую плоскость))
еще 2 поста назад ты мерила качество работы разработчиков автоматизированными тестами, а тут уже сливаешься?