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

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

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

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

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

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

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

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

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

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

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