Комментарии 25
@anz (Привет, Андрей!) даже пообещал поставить тысячу плюсов если бы мог
Извините, но я упоротый. Поэтому полез искать обещание anz и не нашел... Где он это сделал? Не вижу ни под статьёй, ни в истории комментов @anz. (Кстати, мне с телефона не даёт выбрать этот ник при вызове, только anze. Но это уже другая тема.)

Ну с Андреем мы некоторое время работали в одной студии, и общение утекло в тг.
Про сложность - правильно подмечено. Но это не про софт, это про технику вообще, любую и всегда: любой конфликт между требованиями решается стандартно увеличением сложности конструкции. Цифровая камера вместо пленочной - сложность. Автоматическая перелача вместо ручной - сложность. Чай с лимоном - сложность, кофе американо - тоже сложность, трусывместо фигового листа -та еще сложность.
Но в трусах проще двигаться, чем в фиговых листах, молнию прощезастегивать, чем пуговицы, а в туфлях проще передвигаться, чем в лаптях.
Простота - для пользователя и покупателя. Сложность - для производителя и разработчика. Если вы занимаетесь вторым, а хотите первого, - значит, вам придется покупать инструменты, сделанные другими людьми, для которых вы - пользователь и покупатель.
Ничто не ново под Луной...
Ура, хабр — торт! Отличная статья.
Ох уж эта вечная гонка за деньгами, которые постоянно убегают. Игры уже скоро обгонят реальность по качеству картинки :) но "прогресс" не остановить.
Графика почти уперлась в потолок, а оптимизация катится куда-то в район плинтуса. Раньше текстуры сжимали руками ради каждого килобайта на картридже. Сейчас просто лепят апскейлер и надеются на новые видеокарты игроков
Разница между "картинкой из 3ds max / Blender" и "кадром из игры на 5090" - в десятки тысяч, сотни тысяч раз по зартаченным вычислениям (да, почти все они уходят на создание реалистичного освещения - но ни о каком "кадр из игры обгонит реальность" речи пока не идёт).
Про функциональные и нефункциональные требования верно подмечено.
Я бы это охарактеризовал так:
ты ("недо-интерн" в 16 лет пишешь программки за ПК) и видишь только нефункциональные требования - хочу чтобы программа была красивой, быстрой ... (что делать я и сам поинмаю).
Ты после универа уверенный Джну+, тебя научили в универе и втолковали на 1й работе, что ТРЕБОВАНИЯ ЭТО ВАЖНО, даже не думай об оптимизациях, пока не будет выполнено, вчё что написано в 100-страничном документе
Ты сеньор, знаешь, что в 100-страничном документе (функциональные требования) написана самая обычная туфра, главное чтобы всё работало хорошо (ты знаешь как), и да архитектуру твоего приложения будет определять не эта туфта - а насколько всё должно быть быстро, на предполагаетмых объёмах, красиво, real-time'ово...
Настоящий сеньор как раз читает эту портянку очень внимательно, иначе потом бизнес придет с вопросом почему сделано идеально быстро, но вообще не то
А поговорить (с несколькими, желательно всеми доступными) стейкхолдерами заказчика что не позволяет? Религия?
Обычно "надо заказчику" и "написано в ТЗ" - вообще разные вещи. ТЗ с некоторых пор стало вещью самой в себе - не зря оно активно заменилось на use-case, user-story.
П.С.
Играть или не играть в корпоративные игры "формальное соответствие ТЗ" имеющие слабое отношение к решению технической задачи "создать систему, с нужными пользователю характеристиками" - каждый выбирает для себя сам.
Дык не получится, многие воспринимают желание поговорить с заказчиком через голову начальства или уточнить технические детали как личное оскорбление и отбирание куска хлеба, а разговор через начальника довольно быстро приобретает характер сломанного телефона и повышает уровень недовольства у обеих сторон. Так что да, в каком то смысле не позволяет религия... корпоративная вера в непогрешимость клиента
То, что вы написали - у меня проходит по разряду "желание играть в корпоративные игры".
Готов согласится, что мой раздел об этом существенно не полон. Игр взрослых дядечек - посвящающих всё своё и изрядную часть чужого времени вопросу "кто главнее" стараюсь избегать.
Возвращаясь к разговору по-существу:
Написание ТЗ, согласование ТЗ, выполнение работ по ТЗ, приёмка по ТЗ - давно превратилась в самостоятельный, живущий отдельно от изначально решаемой задачи ритуал.
Если тебе доступно только ТЗ (и нет понимания что ИМЕННО нужно заказчику - хоть поговорив с ним, хоть "поварившись" в этой теме с другими заказчиками 3 годика) - то велика вероятность сделать всё по ТЗ, сделать вещь совершенно непригодную для реальной работ и потому ненужную, быть при этом кругом правым, ибо "пункт IV.4.3.12.x.iii говорит что...".
Мне в ижзни везло - и даже в ситуации когда доступно только ТЗ (не из-за начальника, а из-за игр в безопасность с обеих сторон) приёмка-сдача (заказчику а потом в эксплуатацию) всё равно проходила по существу "что надо", а не "что в ТЗ написано".
Когда за окном возникнет гриб от взрыва, читать будут ТЗ, а не чьи-то хотелки и ваши разумения как на самом деле надо.
Хорошо, когда всё хорошо, но бывает и плохо
поговорить (с несколькими, желательно всеми доступными) стейкхолдерами заказчика что не позволяет? Религия?
Облачно, они противоречат друг другу и каждый настанет давить на разработчика, звонить ему по ночам. В результате побеждает не то что соответствует пользе и стратегии, побеждает кто громче кричит на разработчика. Ему это надо?
Обожаю эти 80 мегабайт запаса под фрагментацию, которые на самом деле тают уже в главном меню игры))
Может просто другую игру начать делать?
Ну желание вечно бежать в перед и объять необъятное - оно так и выглядит. После преодоления преграды - возникает новая возможность и сразу новая преграда. Если не опеределить конец пути - будет как в мандалорце - у него нет цели есть только путь.
Вот вы описали типичную ситуацию любого продукта, когда непонятно куда он движется и для чего. Главное, что деньги платят. Там ещё обычно агрессивный марктениг этому способствует. Привлекает людей всё больше, масштаб растёт, а с ним и пробелы новые.
Но вот был год оф вор. Его сделали, поиграли кайфанули и конец истории. Потом ещё раз сделали другую часть.
Лучшие истории - имеют финал. Первый железный человек был классный. Второй нормальный. Трертий был не нужен.
Ну а так по коду если - убирайте технику и сложности за адаптеры и всегда делайте DI.
Нет передела совершенству - но он есть. И наступает тогда, когда появляется вот такая статья о сложностях.
Да. Я далек от мира игр. Но как будто речь про онлайн - там вечно музыка играет пока всем не надоест. И людей стараются удержать там чем ток можно и нельзя. Но думаю им не повредит раз в 3 года стабильно закрываться. Чтобы ментально освобождаться для новых идей.
Если у тебя студия, выпустившая успешный продукт, ты не будешь делать следующий с нуля - будешь дорабатывать тот же движок/механики/тулы/наработки, ибо делать с нуля - это глупо, просто трата времени и денег. По сути такие игры отличаются только графиком релизов, кто то делает патчи раз в неделю, а кто то сразу переделывает всю игру и выпускает через несколько лет с цифоркой 2, а технически суть одна
Ну так и получается. Что сами себя загоняем в такие рамки.
Чтобы объять необъятное.
Кто-то уже нашёл ту точку, когда пора прекращать всё переделывать?
Или ещё нет?
Для пользователей переделанное иногда - это просто новая моделька побежала, новый скин нарисовали.
Постоянно переделывать движок - не помню чтобы сейчас был Ureal Engine 100 версии.
Чем больше человеку даёшь - тем больше он просит. Натура у него такая.
Зачем потакать этому?
А причин нет кроме денег. Чем больше хочешь денег - тем больше от них проблем.

Откуда берётся сложность