Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Я такое давал своим детям несколько лет назад, кроме рекурсии. Это была настольная игра. Дочка только-только пошла в школу и нормально справлялась.
S>>Есть координаты настольной игры?

I>Не могу найти. Игра — такси. Карточки для построения города, карточки заданий и карточки для управления. В готовом виде не продавалась, надо было самому распечатывать весь контент.
Не это? Здесь наоборот, выложили исходник готовой игры.
https://www.mosigra.ru/blog/id2%D0%A1100000378/

S>>Конечно, но когда я сравниваю влияние яп, я пытаюсь мысленно изолировать все остальные факторы. Т.е. берем 2 равные команды и при прочих равных одной даем писать на одном языке, другой — на другом.

I>Если изолировать, то трудно сравнить между собой. Например, менеджер обладает властью всех уволить, урезать бюджета и перекроить чуть не все что угодно. Отсюда и влияние на качество.
Если будем учитывать менеджера, то сравнение яп выйдет нечистым, т.к. при прочих равных один лишь менеджер способен повлиять на результат радикально.

I>В целом, при прочих равных чистое ФП нужно там, где гарантии корректной и надежной работы намного важнее перформанса и потребления памяти.
Вот тут я прямо озадачился сперва... А кому нужна программа, которая работает быстро и жрет мало памяти, но не дает гарантий корректного результата? А потом подумал, и задал себе еще один вопрос. Кому нужна корректная навигация, если ее не тащит железо навигатора? Компромисс имеет право существовать.

I>А если, скажем, готовых требований нет, их надо еще выработать, то тут влияние менеджмента заруливает в минуса все остальные аспекты.

I>Если цель добиться качества на конкретном проекте, то менеджмент и коммуникация влияют намного сильнее парадигмы. Поэтому держаться за парадигму лично я смысла большого не вижу — чистое ФП нужно брать тогда, когда нужны гарантии корретной работы. Руками такое не обеспечишь.

Менджмент вообще влияет очень сильно до тех пор, пока на него не забивают (снизу и сверху). Потому, для сравнения других факторов его следует выносить за скобки.

I>Быстрее всего выпиливаются те, кто наиболее востребован. Функционалист, если он адекватен как человек, как правило очень быстро находит новое место.

S>>Безусловно. Но кто заставляет держать таких решал на местах, где они принимают такие решения? Это же просто враги любой разработки, не говоря уж о бизнесе.

I>Я больше скажу — бизнес сам слишком часто рубит свои же хорошие начинания. Например, сами проводят собеседования на проект, который написан в функционально-реактивном стиле. Парадокс — собеседования успешно проходят в основном студенты или недавние студенты, а вот сеньоры разных сортов или не проходят, или проходят и уходят не задерживаясь. Я посмотрел, что же они спрашивают. Оказалось, что алгоритмические задачи типа рюкзаков, при чем хотят не перебор а какое нибудь эффективно решение на динамическом программировании и тд.
I>Фактически, эти задачи проверяют один единственный аспект, который на проекте вобщем не востребован — ну негде в рядовом приложении применить знания динамического программирования. Студенты еще помнят такие вещи, худо-бедно проходят собеседования. Сеньоры такое встречают не каждый день и даже не каждые полгода. А если проходят собес, то быстро теряют к нему интерес, т.к. математику там применить негде.
I>Итого — в проекте очень быстро начинается хаос. Пример хаоса — десериализуем и процессим 20мб граф в виде json в браузере. Очевидно, что все будет мерзнуть. Решение — граф транслируем в массив на сервере, а на клиент отдадим немного другим json теми же 20мб Теперь мерзнет и сервер и браузер. "Ну и что — у нас всего 5 запросов в минуту!"

I>Другой пример — бизнес вынуждает людей уровня сеньора заниматься всевозможными monkey job, при этом не хочет набирать ни опсов, ни девопсов, ни тестировщиков, типа "это всё код, а код лучше всего умеют писать девелоперы!!!"
I> Почему этим занят бизнес — а потому, что они платят деньги и вот так они обращались со своими разработчиками. Идея зашла в тупик, но они проигрывают её еще раз, но уже с оффшорными командами.

Моя контора уже несколько лет как избавилась от всех проектов (в том числе на заказ), кроме одного. И пилим только лишь его. Сейчас в репе только 3 автора коммитов, включая меня и шефа. Соответственно, приходится заниматься всем от архитектуры до ресерча и тестирования. Соответственно, от манки-джоб приходится избавляться путем автоматизации, хотя бы частичной.

Здравствуйте, samius, Вы писали:

I>>Не могу найти. Игра — такси. Карточки для построения города, карточки заданий и карточки для управления. В готовом виде не продавалась, надо было самому распечатывать весь контент.
S>Не это? Здесь наоборот, выложили исходник готовой игры.
S>https://www.mosigra.ru/blog/id2%D0%A1100000378/

Оно. Правила нужно подбирать под возраст участников.

I>>Если изолировать, то трудно сравнить между собой. Например, менеджер обладает властью всех уволить, урезать бюджета и перекроить чуть не все что угодно. Отсюда и влияние на качество.
S>Если будем учитывать менеджера, то сравнение яп выйдет нечистым, т.к. при прочих равных один лишь менеджер способен повлиять на результат радикально.

Так в том то и дело — оптимизировать нужно узкое место, а это в большинстве случаев далеко не парадигма.

I>>В целом, при прочих равных чистое ФП нужно там, где гарантии корректной и надежной работы намного важнее перформанса и потребления памяти.
S>Вот тут я прямо озадачился сперва... А кому нужна программа, которая работает быстро и жрет мало памяти, но не дает гарантий корректного результата? А потом подумал, и задал себе еще один вопрос. Кому нужна корректная навигация, если ее не тащит железо навигатора? Компромисс имеет право существовать.

По разному бывает. Многих на самом деле устраивает низкое качество, абы выглядело красиво. Именно бизнес в явном виде требует — фичи и красота важнее багов. Софт в навигаторе это пример того, где нужны гарантии корректной работы. Не настолько же ФП провально в перформансе

S>Менджмент вообще влияет очень сильно до тех пор, пока на него не забивают (снизу и сверху). Потому, для сравнения других факторов его следует выносить за скобки.

Это понятно. Но важно понимать, когда именно ФП начнет влиять — какие условия доджны быть выполнены.

S>Моя контора уже несколько лет как избавилась от всех проектов (в том числе на заказ), кроме одного. И пилим только лишь его. Сейчас в репе только 3 автора коммитов, включая меня и шефа. Соответственно, приходится заниматься всем от архитектуры до ресерча и тестирования. Соответственно, от манки-джоб приходится избавляться путем автоматизации, хотя бы частичной.

Из этого следует, что у вас нет никого, кто бы на 100% времени занимался exploratory тестированием, или проектировал тесткейсы и тд и тд.
Если это какой нибудь сервис, где интерактива немного и он не завязан непосредственно на деньги, то бывает. Но в общем случае это не работает — отсутствие выделеных тестировщиков говорит о том, что контроля качества нет.
Для небольших команд или стартапов такое норма. Но для большого энтерпрайза это крайне негативный признак. Тем не менее, такой подход нынче берут на вооружение чуть не все подряд.
Вон даже в микрософта свели чуть не все к авто-тестам, а щас у них все апдейты стремные — то повалят, то поломают, то вообще систему выпилят. В лучшем случае просто кое что из железа перестанет работать.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>https://www.mosigra.ru/blog/id2%D0%A1100000378/

I>Оно. Правила нужно подбирать под возраст участников.
Спасибо, побомбим на днях.

I>Так в том то и дело — оптимизировать нужно узкое место, а это в большинстве случаев далеко не парадигма.
Кто же против? Мой тезис в другом: парадигма при прочих равных может иметь не только минусы.

I>По разному бывает. Многих на самом деле устраивает низкое качество, абы выглядело красиво. Именно бизнес в явном виде требует — фичи и красота важнее багов. Софт в навигаторе это пример того, где нужны гарантии корректной работы. Не настолько же ФП провально в перформансе
Более того, читал о случаях, когда благодаря фп (не о чистом фп речь) удалось засунуть обрезанный C++ в такое железо, где и C не лез.

S>>Моя контора уже несколько лет как избавилась от всех проектов (в том числе на заказ), кроме одного. И пилим только лишь его. Сейчас в репе только 3 автора коммитов, включая меня и шефа. Соответственно, приходится заниматься всем от архитектуры до ресерча и тестирования. Соответственно, от манки-джоб приходится избавляться путем автоматизации, хотя бы частичной.

I>Из этого следует, что у вас нет никого, кто бы на 100% времени занимался exploratory тестированием, или проектировал тесткейсы и тд и тд.
I>Если это какой нибудь сервис, где интерактива немного и он не завязан непосредственно на деньги, то бывает. Но в общем случае это не работает — отсутствие выделеных тестировщиков говорит о том, что контроля качества нет.
Опа, из отсутствия такого кадра, кто бы на 100% времени занимался exploratory тестированием и выделенных тестировщиков не следует отсутствие контроля качества.

I>Для небольших команд или стартапов такое норма. Но для большого энтерпрайза это крайне негативный признак. Тем не менее, такой подход нынче берут на вооружение чуть не все подряд.
I>Вон даже в микрософта свели чуть не все к авто-тестам, а щас у них все апдейты стремные — то повалят, то поломают, то вообще систему выпилят. В лучшем случае просто кое что из железа перестанет работать.
Выделенные тестировщики и exploratory тестирование не помогут решить это эффективным образом. Т.е. ресурсы, спущенные на это будут значительные, но радикальное улучшение качества обновлений это вряд ли повлечет. Те сценарии, которые автотест прогоняет за пол часа, живой человек будет гнать столько времени, что за это время выйдет еще пара релизов. Не говоря о том, что бы зациклить что-то, что бы убедиться в отсутствии гонок. Да, конечно, он сможет заметить что-то, проверка чего в сценарий не заложена.

Здравствуйте, samius, Вы писали:

S>Нет, здесь ошибка. main на Хаскеле определяет computation/action. Можно считать computation результатом evaluation программы на хаскеле.
А можете объяснить этот момент подробнее? Правильно я понимаю, что результатом выполнения программы на Хаскеле будет функция, вычисление которой вернёт результат?

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Нет, здесь ошибка. main на Хаскеле определяет computation/action. Можно считать computation результатом evaluation программы на хаскеле.
S>А можете объяснить этот момент подробнее? Правильно я понимаю, что результатом выполнения программы на Хаскеле будет функция, вычисление которой вернёт результат?
Правильно. Это не вполне так, но для понимания можно считать что

type IO a  =  RealWorld -> (a, RealWorld)

и функция main имеет тип IO ()
аналог на C# выглядел бы так

Func<RealWorld, Tuple<RealWorld,int>> main()
{
}

т.е. выполнение main возвращает нам фукнцию, которая при передаче в нее параметра типа RealWorld вернет пару RealWorld и ничего (здесь я тип (), обозначающий ничего заменил на int для простоты, т.к. в C# тип Void мы не можем использовать как значение, дебильное ограничение, кстати).
На возврате этой функции формально заканчивается выполнение программы на хаскеле. А выполнение функции результата по собственной инициативе делает какой-то конь в пальто, которого мы ни о чем не просили в программе на хаскеле.

Здравствуйте, samius, Вы писали:

S>На возврате этой функции формально заканчивается выполнение программы на хаскеле. А выполнение функции результата по собственной инициативе делает какой-то конь в пальто, которого мы ни о чем не просили в программе на хаскеле.

Тогда я не совсем понимаю смысл именно самой программы на Хаскеле — что именно она делает, если она фактически не проводит никаких вычислений?

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>На возврате этой функции формально заканчивается выполнение программы на хаскеле. А выполнение функции результата по собственной инициативе делает какой-то конь в пальто, которого мы ни о чем не просили в программе на хаскеле.

S>Тогда я не совсем понимаю смысл именно самой программы на Хаскеле — что именно она делает, если она фактически не проводит никаких вычислений?
Совсем никаких — это неверно. Она выполняет вычисления, необходимые для создания результирующего вычисления.
Т.е. если мы рассмотрим условно работу пускача C/C+/C# и т.п., то это будет нечто вроде

* передать управление main()
// вычисления программы и вся грязь выполнены тут main-ом
* дождаться возврата main()

Пускач хаскеля будет делать что-то вроде

* передать управление main()
// создается вычисление
* дождаться возврата main()
* передать управление вычислению
// вычисления программы с грязью выполнены тут
* дождаться завершения вычисления

Здравствуйте, samius, Вы писали:

S>>Тогда я не совсем понимаю смысл именно самой программы на Хаскеле — что именно она делает, если она фактически не проводит никаких вычислений?
S>Совсем никаких — это неверно. Она выполняет вычисления, необходимые для создания результирующего вычисления.
S>Т.е. если мы рассмотрим условно работу пускача C/C+/C# и т.п., то это будет нечто вроде

* передать управление main()
// вычисления программы и вся грязь выполнены тут main-ом
* дождаться возврата main()

Пускач хаскеля будет делать что-то вроде

* передать управление main()
// создается вычисление
* дождаться возврата main()
* передать управление вычислению
// вычисления программы с грязью выполнены тут
* дождаться завершения вычисления

Ну то есть, программа на Хаскеле выполняет работу компилятора? Просто я всё равно не понимаю зачем нужна фаза создания вычислителя.

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>Ну то есть, программа на Хаскеле выполняет работу компилятора? Просто я всё равно не понимаю зачем нужна фаза создания вычислителя.
Нет, композиция вычислений — это не связано с компиляцией, т.к. принимать решение о том, что с чем связывать бывает нужно именно в рантайме. Например, если мы получим с консоли символ, отвечающий за то, будем ли мы складывать или умножать элементы введенного с консоли списка.

Зачем нужна эта фаза — для изоляции грязных вычислений от кода. Если бы не эта фаза, то любая функция типа map или length могла бы гадить в мир. И так может, но лишь через бэкдор.

Здравствуйте, samius, Вы писали:

S>Зачем нужна эта фаза — для изоляции грязных вычислений от кода. Если бы не эта фаза, то любая функция типа map или length могла бы гадить в мир. И так может, но лишь через бэкдор.
Каким образом происходит эта изоляция, если подобное отсекается на этапе компиляции? То есть, если я правильно понимаю, если в функцию не внесён IO, то сам компилятор запретит функции "гадить в мир".

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Зачем нужна эта фаза — для изоляции грязных вычислений от кода. Если бы не эта фаза, то любая функция типа map или length могла бы гадить в мир. И так может, но лишь через бэкдор.
S>Каким образом происходит эта изоляция, если подобное отсекается на этапе компиляции? То есть, если я правильно понимаю, если в функцию не внесён IO, то сам компилятор запретит функции "гадить в мир".
Верно. Любое IO вычисление требует на вход реальный мир. Обычный пользовательский код взять его не может ниоткуда, только если мир был передан ему, но тогда и этот код становится IO действием. Кроме пускача родить мир может бэкдор unsafePerformIO.

Здравствуйте, samius, Вы писали:

S>>Каким образом происходит эта изоляция, если подобное отсекается на этапе компиляции? То есть, если я правильно понимаю, если в функцию не внесён IO, то сам компилятор запретит функции "гадить в мир".
S>Верно. Любое IO вычисление требует на вход реальный мир. Обычный пользовательский код взять его не может ниоткуда, только если мир был передан ему, но тогда и этот код становится IO действием. Кроме пускача родить мир может бэкдор unsafePerformIO.
Я не о том, я всё ещё пытаюсь понять, зачем нужен этот этап с возвратом Computation из программы. Вы сейчас сами пишите, что изоляцию "грязных" функций обеспечивает компилятор, постороение дерева ленивых вычислений происходит в рантайме (потому что поток исполнения может зависить от результатов грязной функции), и т.д. — а зачем тогда нужен этот возврат Computation, что происходит в фазе построения этого Computation?

Здравствуйте, samius, Вы писали:

I>>Так в том то и дело — оптимизировать нужно узкое место, а это в большинстве случаев далеко не парадигма.
S>Кто же против? Мой тезис в другом: парадигма при прочих равных может иметь не только минусы.

Может, но мне кажется что это всегда зависит от задачи.

I>>Если это какой нибудь сервис, где интерактива немного и он не завязан непосредственно на деньги, то бывает. Но в общем случае это не работает — отсутствие выделеных тестировщиков говорит о том, что контроля качества нет.
S>Опа, из отсутствия такого кадра, кто бы на 100% времени занимался exploratory тестированием и выделенных тестировщиков не следует отсутствие контроля качества.

Именно следует Зеленые тесты говорят, что регрессии нет. Но это ни разу не гарантия качества.
Пример 1 девелопер, если неверно интерпретировал требования, естественным путём своё видение повторяет и в тестах.
Пример 2 кто же ищет новы пути, находит неожиданные баги? А никто
Пример 3 кто решает, что все готово — а сам исполнитель. Хы-хы.

Собтсвенно можно говорить о том, что качество высокое, при условии, что работа ведется в соответствии с требованиями
1 новых багов нет (поиск не прекращался)
2 регрессии нет (все найденые пути-кейсы автоматизированы)

S>Выделенные тестировщики и exploratory тестирование не помогут решить это эффективным образом. Т.е. ресурсы, спущенные на это будут значительные, но радикальное улучшение качества обновлений это вряд ли повлечет. Те сценарии, которые автотест прогоняет за пол часа, живой человек будет гнать столько времени, что за это время выйдет еще пара релизов.

Живые люди нужны не для замены авто-тестов, а для поиска новых путей-кейсов, для поиска новых багов, проблем и тд, для определения степени готовности.
Это естественное разделение труда. С учетом разницы в уровнях ЗП, на одного разработчика бывает можно взять двух, а то и трёх нормальных тестировщиков.

>Не говоря о том, что бы зациклить что-то, что бы убедиться в отсутствии гонок.

Живой человек вполне себе может пользоваться полуавтоматическими средствами и пытаться зацикливать всё, что угодно.

>Да, конечно, он сможет заметить что-то, проверка чего в сценарий не заложена.

Каждый автоматизированый сценарий, даже все вместе, проверяют ничтожную часть путей в приложении. Юзер почти никогда такими путями не ходит, он может напороться где угдно.

Другое дело, если у вас сервис, где нет особой интерактивности — такие вещи хорошо тестируются авто-тестами. Но в сложных больших системах даже здесь выделяют АПИ-тестировщиков.

Кроме того, если разработчики проверяют сами себя, то здесь изначально заложен конфликт интересов — разработчик заинтересован увильнуть от тестирования, что обычно и происходит.
А вот тестировщик заинтересован найти ошибку.

Далее — принятие решения о том, что фича закончена, не у девелопера, а у тестировщика, который потратил x-часов вручную и убедился, что всё хорошо. А вот далее идет автоматизация, по ключевым точкам.

Здравствуйте, Somescout, Вы писали:

S>Ну то есть, программа на Хаскеле выполняет работу компилятора? Просто я всё равно не понимаю зачем нужна фаза создания вычислителя.

Нет, там работа не компилятора, а скорее композитора. Но это не суть, поскольку не имеет отношения к ответу на твой вопрос. А ответ очень простой: это нужно исключительно для того, чтобы можно было написать в документации, что Хаскель — это чистый функциональный язык. И всё. Больше пользы от этого нет никакой. Более того, когда фанатам Хаскеля наглядно показывают (http://rsdn.org/forum/philosophy/7577551

Автор: alex_public
Дата: 29.10.19

), что с таким подходом можно назвать абсолютно чистым любой язык программирования, они как-то резко груснеют и по тихому сворачивают дискуссию. )))

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Кто же против? Мой тезис в другом: парадигма при прочих равных может иметь не только минусы.

I>Может, но мне кажется что это всегда зависит от задачи.
Конечно

S>>Опа, из отсутствия такого кадра, кто бы на 100% времени занимался exploratory тестированием и выделенных тестировщиков не следует отсутствие контроля качества.

I>Именно следует Зеленые тесты говорят, что регрессии нет. Но это ни разу не гарантия качества.
Отсутствие контроля качества и гарантия качества — это не одно и то же.
I>Пример 1 девелопер, если неверно интерпретировал требования, естественным путём своё видение повторяет и в тестах.
I>Пример 2 кто же ищет новы пути, находит неожиданные баги? А никто
I>Пример 3 кто решает, что все готово — а сам исполнитель. Хы-хы.
Отсутствие кадра, "кто бы на 100% времени занимался exploratory тестированием" не означает что никто вообще ничего никогда не проверяет.

I>Собтсвенно можно говорить о том, что качество высокое, при условии, что работа ведется в соответствии с требованиями
I>1 новых багов нет (поиск не прекращался)
I>2 регрессии нет (все найденые пути-кейсы автоматизированы)
Отсутствие контроля! Ты топил за отсутствие контроля, а не оценку.

S>>Выделенные тестировщики и exploratory тестирование не помогут решить это эффективным образом. Т.е. ресурсы, спущенные на это будут значительные, но радикальное улучшение качества обновлений это вряд ли повлечет. Те сценарии, которые автотест прогоняет за пол часа, живой человек будет гнать столько времени, что за это время выйдет еще пара релизов.

I>Живые люди нужны не для замены авто-тестов, а для поиска новых путей-кейсов, для поиска новых багов, проблем и тд, для определения степени готовности.
I>Это естественное разделение труда. С учетом разницы в уровнях ЗП, на одного разработчика бывает можно взять двух, а то и трёх нормальных тестировщиков.
Определенные баги вылазят при активной эксплуатации на 10К машин за месяц-два. И стреляют 1-2 раза. Такие не найдешь с помощью 3х нормальных тестировщиков, если мы говорим о тестировании руками. А нормальные тестировщики, которые будут писать код для стресс нагрузок, полагаю, могут стоить подороже некоторых нормальных разработчиков.

>>Не говоря о том, что бы зациклить что-то, что бы убедиться в отсутствии гонок.

I>Живой человек вполне себе может пользоваться полуавтоматическими средствами и пытаться зацикливать всё, что угодно.
С этим сложно спорить, т.к. разработчик тоже живой человек.

>>Да, конечно, он сможет заметить что-то, проверка чего в сценарий не заложена.

I>Каждый автоматизированый сценарий, даже все вместе, проверяют ничтожную часть путей в приложении. Юзер почти никогда такими путями не ходит, он может напороться где угдно.

I>Другое дело, если у вас сервис, где нет особой интерактивности — такие вещи хорошо тестируются авто-тестами. Но в сложных больших системах даже здесь выделяют АПИ-тестировщиков.

I>Кроме того, если разработчики проверяют сами себя, то здесь изначально заложен конфликт интересов — разработчик заинтересован увильнуть от тестирования, что обычно и происходит.
I>А вот тестировщик заинтересован найти ошибку.

I>Далее — принятие решения о том, что фича закончена, не у девелопера, а у тестировщика, который потратил x-часов вручную и убедился, что всё хорошо. А вот далее идет автоматизация, по ключевым точкам.
Выше писал. 1-2 месяца работы 10К клиентов могут выявить баг. А могут и не выявить. Чему будет равно x-часов вручную у тестировщика?

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Верно. Любое IO вычисление требует на вход реальный мир. Обычный пользовательский код взять его не может ниоткуда, только если мир был передан ему, но тогда и этот код становится IO действием. Кроме пускача родить мир может бэкдор unsafePerformIO.

S>Я не о том, я всё ещё пытаюсь понять, зачем нужен этот этап с возвратом Computation из программы. Вы сейчас сами пишите, что изоляцию "грязных" функций обеспечивает компилятор, постороение дерева ленивых вычислений происходит в рантайме (потому что поток исполнения может зависить от результатов грязной функции), и т.д. — а зачем тогда нужен этот возврат Computation, что происходит в фазе построения этого Computation?

Полагаю, что цель именно в контроле над распространением IO по коду программы и заключается. Примерно так же C++ предлагает с помощью const контролировать возможность изменения данных.

Здравствуйте, samius, Вы писали:

I>>Именно следует Зеленые тесты говорят, что регрессии нет. Но это ни разу не гарантия качества.
S>Отсутствие контроля качества и гарантия качества — это не одно и то же.

Контроль качества нужен ради этих самых гарантий

I>>Пример 1 девелопер, если неверно интерпретировал требования, естественным путём своё видение повторяет и в тестах.
I>>Пример 2 кто же ищет новы пути, находит неожиданные баги? А никто
I>>Пример 3 кто решает, что все готово — а сам исполнитель. Хы-хы.
S>Отсутствие кадра, "кто бы на 100% времени занимался exploratory тестированием" не означает что никто вообще ничего никогда не проверяет.

А это примерно оно и есть. Кавалерийскими атаками эта задача не решается. Это долговременная активность, не только exploratory, а ручное вообще.

Что у вас за софт такой ?

I>>Собтсвенно можно говорить о том, что качество высокое, при условии, что работа ведется в соответствии с требованиями
I>>1 новых багов нет (поиск не прекращался)
I>>2 регрессии нет (все найденые пути-кейсы автоматизированы)
S>Отсутствие контроля! Ты топил за отсутствие контроля, а не оценку.

Так контроль нужен ради гарантий У вас только п.2.

Вполне возможно, у вас как раз тот случай, что хорошо ложится на автотесты. Но таких проектов вообще говоря меньшинство.
Если у вас ажно три коммитера, это значит, что
1. обязанности тестеров-мануальщиков ложатся на этих трех (проектирование тестов, планирование тестирования)
2. обязанности тестеров-автоматизаторов ложатся на этих трех (автоматизация ключевых тест-кейсов)
3. нагрузочное тестирование ложится так же на этих трех
4. автоматизация инфраструктуры так же ложится на этих трех (опс, девопс и тд)
5. огромная куча рутинных задач, коих всегда около 80%, ложится на этих трех
6. что с суппортом-траблшутингом — не ясно, кто это делает

То есть, уже в наличии совмещение большого количества ролей. Чем больше ролей совмещается, тем хуже эффективность.
Далее, если один разработчик решил уйти-заболеть-умереть-переехать, найти замену становится очень трудно. Тестировщики страхуют проблем при таких вот поворотах.
Далее, для вас затруднителен вариант "взять миддла-студента на вырост", т.к. такой человек может и будет вносить хаос, а контроль достаточно слабый, т.к. все держится именно на квалификации этих трех.

Фактически, ваш проект скорее всего, на мой взгляд, находится в очень хрупком равновесии. Сильно вряд ли вы можете легко и быстро заполнять вакансии, адаптироваться к новым условиям, колебаниям рынка, изменению требований и тд.

I>>Живые люди нужны не для замены авто-тестов, а для поиска новых путей-кейсов, для поиска новых багов, проблем и тд, для определения степени готовности.
I>>Это естественное разделение труда. С учетом разницы в уровнях ЗП, на одного разработчика бывает можно взять двух, а то и трёх нормальных тестировщиков.
S>Определенные баги вылазят при активной эксплуатации на 10К машин за месяц-два. И стреляют 1-2 раза. Такие не найдешь с помощью 3х нормальных тестировщиков, если мы говорим о тестировании руками. А нормальные тестировщики, которые будут писать код для стресс нагрузок, полагаю, могут стоить подороже некоторых нормальных разработчиков.

Тестировщики не гарантируют, что найдут все баги. Правильный процесс о другом — все что можно найти найти в течение разработки, будет найдено. Для этого, в частности, нужно exploratory тестирование, т.е. поиск новых багов.
Если вы их ищете время от времени, то результат будет соответствующий.

Если вам нужные еще и нагрузочные тесты, это отдельная песня. Что бы внятно представлять вашу ситуацию, нужно хоть как то взглянуть на неё

I>>Живой человек вполне себе может пользоваться полуавтоматическими средствами и пытаться зацикливать всё, что угодно.
S>С этим сложно спорить, т.к. разработчик тоже живой человек.

Разумеется. При этом разделение труда это естественный подход к увеличению эффективности.

I>>Далее — принятие решения о том, что фича закончена, не у девелопера, а у тестировщика, который потратил x-часов вручную и убедился, что всё хорошо. А вот далее идет автоматизация, по ключевым точкам.
S>Выше писал. 1-2 месяца работы 10К клиентов могут выявить баг. А могут и не выявить. Чему будет равно x-часов вручную у тестировщика?

Как я могу такое утверждать, если мне неизвестна ваша система?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Именно следует Зеленые тесты говорят, что регрессии нет. Но это ни разу не гарантия качества.
S>>Отсутствие контроля качества и гарантия качества — это не одно и то же.

I>Контроль качества нужен ради этих самых гарантий
Контроль — это процесс. А гарантии — необязательный результат этого процесса.

I>>>Пример 1 девелопер, если неверно интерпретировал требования, естественным путём своё видение повторяет и в тестах.
I>>>Пример 2 кто же ищет новы пути, находит неожиданные баги? А никто
I>>>Пример 3 кто решает, что все готово — а сам исполнитель. Хы-хы.
S>>Отсутствие кадра, "кто бы на 100% времени занимался exploratory тестированием" не означает что никто вообще ничего никогда не проверяет.

I>А это примерно оно и есть. Кавалерийскими атаками эта задача не решается. Это долговременная активность, не только exploratory, а ручное вообще.
Да нечего там особо руками делать. Только если сценарии писать.

I>Что у вас за софт такой ?
Корпоративная клауд файлопомойка

I>>>Собтсвенно можно говорить о том, что качество высокое, при условии, что работа ведется в соответствии с требованиями
I>>>1 новых багов нет (поиск не прекращался)
I>>>2 регрессии нет (все найденые пути-кейсы автоматизированы)
S>>Отсутствие контроля! Ты топил за отсутствие контроля, а не оценку.

I>Так контроль нужен ради гарантий У вас только п.2.
У нас не только п.2. У нас только лишь нет кадра, на 100% занятого тестами. И даже на 30%.

I>Вполне возможно, у вас как раз тот случай, что хорошо ложится на автотесты. Но таких проектов вообще говоря меньшинство.
I>Если у вас ажно три коммитера, это значит, что
I>1. обязанности тестеров-мануальщиков ложатся на этих трех (проектирование тестов, планирование тестирования)
I>2. обязанности тестеров-автоматизаторов ложатся на этих трех (автоматизация ключевых тест-кейсов)
I>3. нагрузочное тестирование ложится так же на этих трех
I>4. автоматизация инфраструктуры так же ложится на этих трех (опс, девопс и тд)
I>5. огромная куча рутинных задач, коих всегда около 80%, ложится на этих трех
Упс, не слышал. Наверное, те двое, кто не я, этим занимаются.
I>6. что с суппортом-траблшутингом — не ясно, кто это делает
Вместо саппорта мануал по эксплуатации. В нашем случае справляется.

I>То есть, уже в наличии совмещение большого количества ролей. Чем больше ролей совмещается, тем хуже эффективность.
I>Далее, если один разработчик решил уйти-заболеть-умереть-переехать, найти замену становится очень трудно. Тестировщики страхуют проблем при таких вот поворотах.
С уйти-заболеть-умереть согласен. Но переехать — не такая уж и проблема сегодня.
I>Далее, для вас затруднителен вариант "взять миддла-студента на вырост", т.к. такой человек может и будет вносить хаос, а контроль достаточно слабый, т.к. все держится именно на квалификации этих трех.

I>Фактически, ваш проект скорее всего, на мой взгляд, находится в очень хрупком равновесии. Сильно вряд ли вы можете легко и быстро заполнять вакансии, адаптироваться к новым условиям, колебаниям рынка, изменению требований и тд.

Наш проект пережил много таких проектов. Но я не очень понимаю, что именно ты предлагаешь? Видимо, создать отдел кадров для начала?

I>Тестировщики не гарантируют, что найдут все баги. Правильный процесс о другом — все что можно найти найти в течение разработки, будет найдено. Для этого, в частности, нужно exploratory тестирование, т.е. поиск новых багов.
I>Если вы их ищете время от времени, то результат будет соответствующий.

Результат пока нас устраивает.

I>Если вам нужные еще и нагрузочные тесты, это отдельная песня. Что бы внятно представлять вашу ситуацию, нужно хоть как то взглянуть на неё
Думаю, это лишнее.

I>>>Живой человек вполне себе может пользоваться полуавтоматическими средствами и пытаться зацикливать всё, что угодно.
S>>С этим сложно спорить, т.к. разработчик тоже живой человек.

I>Разумеется. При этом разделение труда это естественный подход к увеличению эффективности.
Конечно. Но вместе с трудом придется разделять и мотивацию к нему.

S>>Выше писал. 1-2 месяца работы 10К клиентов могут выявить баг. А могут и не выявить. Чему будет равно x-часов вручную у тестировщика?

I>Как я могу такое утверждать, если мне неизвестна ваша система?
Я думаю, что дал достаточно данных что бы утверждать, что ручной тестировщик не выход в данной ситуации.

Здравствуйте, samius, Вы писали:

I>>Контроль качества нужен ради этих самых гарантий
S>Контроль — это процесс. А гарантии — необязательный результат этого процесса.

Гарантии это цель ради которой проводится этот процесс.

Крайне странно говорить про бенефит от парадигмы, если гарантии качества "необязательный результат"

I>>А это примерно оно и есть. Кавалерийскими атаками эта задача не решается. Это долговременная активность, не только exploratory, а ручное вообще.
S>Да нечего там особо руками делать. Только если сценарии писать.

Это принципиально ничего не меняет. Ну не отсылаются запросы мышом, и с клавиатуры их не набирают

S>>>Отсутствие контроля! Ты топил за отсутствие контроля, а не оценку.

I>>Так контроль нужен ради гарантий У вас только п.2.
S>У нас не только п.2. У нас только лишь нет кадра, на 100% занятого тестами. И даже на 30%.

В том то и дело. Не совсем понятно, как вы ищете новые, неожиданные проблемы Ты про какую то идилию Моя практика показывает, что идилия есть симптом отсутствия контроля качества.

I>>6. что с суппортом-траблшутингом — не ясно, кто это делает
S>Вместо саппорта мануал по эксплуатации. В нашем случае справляется.



I>>Фактически, ваш проект скорее всего, на мой взгляд, находится в очень хрупком равновесии. Сильно вряд ли вы можете легко и быстро заполнять вакансии, адаптироваться к новым условиям, колебаниям рынка, изменению требований и тд.

S>Наш проект пережил много таких проектов.

Пережил — это больше про спрос и соотношение цена/качество. Чем выше спрос, тем хуже может как цена/качество, так и само качество.

>Но я не очень понимаю, что именно ты предлагаешь? Видимо, создать отдел кадров для начала?

Ваш пример нетипичный, я просто указываю на эту особенность. И соответсвенно опираться именно на этот проект при рассмотрении бенефитов парадигмы очень странно.

I>>Если вы их ищете время от времени, то результат будет соответствующий.

S>Результат пока нас устраивает.

Так про то и речь

I>>Разумеется. При этом разделение труда это естественный подход к увеличению эффективности.
S>Конечно. Но вместе с трудом придется разделять и мотивацию к нему.

Именно так это и делается — ктото улучшает продукт фиксами, а ктото улучшает продукт обнаруженными проблемами. Кому интереснее пилить код продукта — пилит продукт, кому интереснее пилить код тестов, пилит тесы, кому интересны сценарии, тесткейсы и тд, занят именно этими вещами.

I>>Как я могу такое утверждать, если мне неизвестна ваша система?
S>Я думаю, что дал достаточно данных что бы утверждать, что ручной тестировщик не выход в данной ситуации.

Ощущение, будто у тебя такая картина — тестировщик отсылает http запрос мышом набирая его с клавиатуры

Ручное, это значит, что сценарий и результат, определяет тестировщик в момент тестирования. А какими средствами он пользуется — мышом, клавиатурой, скриптами, вспомогательными приложениями, мониторингом, специальной админкой — дело десятое.
Например — задеплоили x для заказчика y на z виртуальных машин, дали нагрузку в половину рабочей. Ожидаем, что счетчики будут такие то и такието. Если нет, изыскиваем причины, уочняем, меняем сценарий.
Или так — при повышении нагрузки добавляем новые ноды для процессинга, при уменьшении — убираем. Проверяем, насколько эффективно это работает, соответствует ли нашим требованиями.
Или так — запретить масштабирование, проверить, как именно деградирует производительность при взрывном росте нагрузки, соответсвует ли ожиданиями.

Очевидно, что такие вещи тестировщик делает не руками. Но сценарий и ожидания новые, ранее не зафиксированы ни одним из авто-тестов.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Контроль — это процесс. А гарантии — необязательный результат этого процесса.

I> Гарантии это цель ради которой проводится этот процесс.

I>Крайне странно говорить про бенефит от парадигмы, если гарантии качества "необязательный результат"
Было бы странно говорить наоборот. Вот как если бы ради долголетия я бы тебе пропагандировал правильное питание и говорил бы, что долголетие — гарантированный результат. Конечно, нет.

S>>Да нечего там особо руками делать. Только если сценарии писать.

I>Это принципиально ничего не меняет. Ну не отсылаются запросы мышом, и с клавиатуры их не набирают

S>>У нас не только п.2. У нас только лишь нет кадра, на 100% занятого тестами. И даже на 30%.

I>В том то и дело. Не совсем понятно, как вы ищете новые, неожиданные проблемы Ты про какую то идилию Моя практика показывает, что идилия есть симптом отсутствия контроля качества.

Мы их не ищем, они нас сами находят ))) На самом деле, часть будущих проблем видно на этапе разработки.

I>Пережил — это больше про спрос и соотношение цена/качество. Чем выше спрос, тем хуже может как цена/качество, так и само качество.
Здесь согласен.

>>Но я не очень понимаю, что именно ты предлагаешь? Видимо, создать отдел кадров для начала?

I>Ваш пример нетипичный, я просто указываю на эту особенность. И соответсвенно опираться именно на этот проект при рассмотрении бенефитов парадигмы очень странно.

Уж какой проект есть. Надеюсь, бенефиты я продемонстрировал.

S>>Результат пока нас устраивает.

I>Так про то и речь

S>>Конечно. Но вместе с трудом придется разделять и мотивацию к нему.

I>Именно так это и делается — ктото улучшает продукт фиксами, а ктото улучшает продукт обнаруженными проблемами. Кому интереснее пилить код продукта — пилит продукт, кому интереснее пилить код тестов, пилит тесы, кому интересны сценарии, тесткейсы и тд, занят именно этими вещами.

Так делается, когда продукт дядин. Будут проблемы — наймем кого надо и он будет делать то, что надо, а не то, что ему интересно.

I>>>Как я могу такое утверждать, если мне неизвестна ваша система?
S>>Я думаю, что дал достаточно данных что бы утверждать, что ручной тестировщик не выход в данной ситуации.

I> Ощущение, будто у тебя такая картина — тестировщик отсылает http запрос мышом набирая его с клавиатуры

I>Ручное, это значит, что сценарий и результат, определяет тестировщик в момент тестирования. А какими средствами он пользуется — мышом, клавиатурой, скриптами, вспомогательными приложениями, мониторингом, специальной админкой — дело десятое.
Если дело десятое, то просто прими тот факт, что я в том числе определяю и сценарии тоже.

I>Например — задеплоили x для заказчика y на z виртуальных машин, дали нагрузку в половину рабочей. Ожидаем, что счетчики будут такие то и такието. Если нет, изыскиваем причины, уочняем, меняем сценарий.
Кол-во реальных машин лишь у одного заказчика — несколько десятков тысяч. Делать хотя бы 1000 виртуалок для реализации такого сценария — слишком большой геморр. Учитывая то, что проблемы с нагрузкой нет.
I>Или так — при повышении нагрузки добавляем новые ноды для процессинга, при уменьшении — убираем. Проверяем, насколько эффективно это работает, соответствует ли нашим требованиями.
I>Или так — запретить масштабирование, проверить, как именно деградирует производительность при взрывном росте нагрузки, соответсвует ли ожиданиями.

I>Очевидно, что такие вещи тестировщик делает не руками. Но сценарий и ожидания новые, ранее не зафиксированы ни одним из авто-тестов.
Извини, но по-моему ты пытаешься решать проблемы, которых нет, и которые тебя решать не просили.