Комментарии 24
А ещё есть дисциплина Управление Проектами. И из неё выясняется, что выборов намного больше, чем описано в статье. По мне лучше объединить введение с разделом 2 и даже 3: получится содержательнее.
Но одно дело найти ошибку, и другое — ее исправить так, чтобы не
появились другие баги. На это можно потратить еще столько же часов. А то
и дней.
А ещё можно потратить на ПОИСК бага, несколько месяцев.
И так его и не найти!
Таким образом, вопрос: качество или скорость переходит в проблему: хороший, но вечно незаконченный проект или хоть как-то, но работающая программа. Любой менеджер как реалист, естественно, выберет второе.
Как только менеджер начнет терять деньги от "как-то работающей программы", его мнение резко поменяется.
На самом деле, правильно было замечено что
Конечно, следовало бы поступить по-иному. Если есть достаточный опыт и теоретическая подготовка, а проект перспективный, не одноразовый, то нужно сначала хорошенько разобраться в теме, выработать качественное решение, а потом уже на основе его серийно делать проекты.
Для начала берем BRD (причем, оно тоже должно быть согласовано) от заказчика и на его основе делаем архитектурное решение. Потом его осуждаем. Когда архитектура утверждена, на основе BRD и архитектуры делаем FSD. И дальше уже следуем ему, не отвлекаясь на "а вот мне тут еще классная фича в голову пришла..."
Все, что пришло в голову пишем в todo для дальнейшего обсуждения.
Ну и про оценку времени тоже не забываем. Любая задача должна быть оценена - столько-то времени на аналитику, столько-то на разработку, столько-то на тестирование.
В общем, в разработке должен быть системный подход. А не допускать до проекта "юношей пылких со взором горящим", которые сразу хватаются за клавиатуру и начинают "творить" без предварительной подготовки. В 99.99% случаем это пустая трата времени и ресурсов.
Любой проект должен "созреть" в голове. Даже если это личный пет-проект. Дать ему "устаканиться", представить все в голове от начала до конца и потом уже планомерно реализовывать в том объеме, который ясно себе представляете. А что пришло в голову по ходу пьесы - оставлять для дальнейшего развития.
Мои мысли читаешь. Ты меня опередил с написанием статьи. Низкий плклон и благодарность от всего сердца!
Т.е. достаточно древнее "выбери два из трех: качественно, дешево, быстро" автор не знает ?
Знает. Про это и написана статья. Все выбирают "дешево и быстро". Всегда. То, что описано в статье называется "технический долг".
Небольшое его количество и постоянный мониторинг - это золотая середина.
А вот когда его много - он съедает и скорость и бюджет, оставляя только не качественность.
Особенно им брезгают при проектах "взял, запилил модуль, через неделю отдал".
Я думаю, что в наличии большого тех. долга виноват менеджер полностью.
Особенно, если он может влиять на кадры. Отмазка в духе "были одни джуны, они нагородили" не работает. Понятное дело, что джуны накуролесят. Или ты думал, что можно платить специалистам в пять раз меньше и ожидал качественный результат?
Найми тех лида, а он уже подберет команду. Разработка (особенно игр) - это ДОРОГО и ДОЛГО. Всё. Нормальный продукт по другому и не происходит
Я думаю, что в наличии большого тех. долга виноват менеджер полностью.
Да, вот только от этого не легче. Мучиться с кодом все равно нам. Поэтому тут и подводится к мысли о необходимости искать решение проблемы своими силами, не надеясь на хороших менеджеров (все равно их не найдешь).
А решение в создании фреймворка и методологии, которые позволят делать и качественно, и дешево (по крайней мере для самого программиста), и быстро. По крайней мере для одной предметной области, в данном случае -- разработке игр.
Однако, есть и третий вариант — взять готовый фреймворк, дать своим разработчикам неделю-две в нем разобраться, а потом клепать игры по шаблону и горя не знать
Вот только игры "по шаблону" не особо интересны. Если у разработчика клона есть оригинальные идеи - зачастую он упрется в ограничения фреймворка. Если у него нет оригинальный идей - получится унылый клон, в который никто не будет играть.
Чем специфичнее фреймворк, тем больше шанс удариться в лимиты. Чем больше возможностей дает фреймворк - тем он сложнее и больше шансов сделать плохо и получить все тяготы, которые описаны в статье
Вот только игры "по шаблону" не особо интересны.
Разве это так? Все играют только в стандартные шаблонные рпг, шутеры, счастливые фермо-крафтеры и чуть пореже в стратегии, адвенчуры и гонки. Ну и ещё "дорогие любители футбола" играют в дорогие футбольные симуляторы, куда же без этого.
А вот в нестандартное люди не играют. Поругать шаблонные игры все горазды, а взять и купить действительно нестандартную игру желающих мало. Я уверен, что гейм девелоперы с удовольствием бы делали новые уникальные игры, но не делают этого просто потому, что в них никто не будет играть. Ну правда же!
В 80е, когда жанры ещё не устаканились и люди играли просто в разные игры, и разработчики решались на совершенно отчаянные по сегодняшним меркам проекты. Большинство игр того времен были платформерами, но если игра не платформер, то скорее всего она была с уникальной игровой механикой и совершенно крезёвой задумкой.
Сейчас и близко такого нет. Сейчас нестандарнтыми и уникальными играми называют шаблонные проекты, в которых чуть-чуть что то одно поменяли. Да и это делают очень редко. Почему? Да потому что пользователи не хотят никаких изменений, их и так все устраивает. А в игры с новыми уникальными механиками надо долго врубаться, заморачиваться, учиться в них играть. Этого никто не хочет.
Ситуация как с Голливудским кино. Все его ругают, называют тупым, пустым, бездарным, но смотрят только его. И даже когда сам Голливуд пытается чуть-чуть приподнять планку и снять что то более серьезное, зрители такой фильм просто сливают, обрекая на кассовый провал.
Разве это так? Все играют только в стандартные шаблонные рпг, шутеры, счастливые фермо-крафтеры и чуть пореже в стратегии, адвенчуры и гонки
Это именно так. То о чем говорю я - это унылые клоны, которые отличаются сменой моделей и текстур и (буквально) парой новых фич. Вы, скорее всего, о них даже и не слышали - именно потому, что они никому не нужны и никогда не становились хоть сколько-либо известными или популярными. Бесчисленные клоны майнкрафта, шутеры по шаблону на юнити с купленным паком моделек и т.д., самые успешные из них можно найти в недрах стима с ценой в 10р и сотней инсталлов. На мобильном рынке это еще более заметно.
То, во что массово играют сейчас люди - это игры, сделанные, как правило, на своих собственных движках. Ну или взят существующий мощный графический движок (Unreal / Unity), а все остальное самописное
Вы говорите, что популярные игры оригинальны и уникальны. Я этого не вижу. Абсолютно все популярные сегодня игры это клоны других игр, которые в свою очередь были клонами клонов и т.д. Какие то там отличия надо просто под микроскопом искать.
Да, майнкрафт был уникальной игрой, когда появился в 2009 году. В игру продолжают играть уже 13 лет. И за эти 13 лет не появилось ни одной популярной новой игры. Новой в смысле с новой игровой механикой и концепцией.
В 80е концептуально новые игры появлялись почти каждый день. Да, была проблема - все они были абсолютно неиграбельное говно. Но они были реально уникальные и по настоящему самобытные. Но тогда вообще не было хороших игр из-за технических ограничений компьютеров тех лет, и люди часто брали игры именно за уникальность, потому, что как шаблонная так и оригинальная игра будут одинаково убогими, но оригинальная хотя бы как то интересна за счет своей необычности.
Сейчас уже не так. Люди предпочитают играть в гарантированно хорошие шаблоны, нежели в неведомо что. Сейчас тоже появляются действительно новые игры. Но все они совершенно непопулярны. Даже когда их делают бесплатными, никто в них не хочет играть. По ряду причин - потому что игровая механика хоть и уникальная, но унылая, потому что бюджет околонулевой и графика отвратительная и просто потому что люди не хотят ничего нового ибо не хотят меняться.
Вы говорите, что популярные игры оригинальны и уникальны
С точки зрения разаботки (а статья именно про это) - да. AAA-тайтлы вообще целиком на своих разработках, остальные, максимум, заимствуют один из топовых графических движков.
Абсолютно все популярные сегодня игры это клоны других игр
Это вопрос философский и можно долго спорить на этот счет. Что есть уникальность, где границы жанров и т.д.
Да, майнкрафт был уникальной игрой, когда появился в 2009 году
Ну не знаю. Я вот например не фанат майнкрафта. Знаю достаточно песочниц с большим кол-вом фич и контента, которые появились задолго до. Единственное, что до майнкрафта никто не делал (во всяком случае я не в курсе) - воксели.
И за эти 13 лет не появилось ни одной популярной новой игры
Ну не знаю, Destiny и сессионные пве шутеры, Hearthstone и засилье ККИ, Fortnite с его "царь горы", Rust и session-survival-sandbox игры, популярность автобаттлеров - довольно много веяний приходило и уходило за эти годы. И это только то, что я помню. Можно, конечно, сказать, что это все тоже клоны - раз есть автомат, значит клон шутера и т.д. Но я рассматриваю игры с точки зрения концепта гейм механики, а не сеттинга
Не, тут беда в том что идейно это всё те же игры просто с новыми режимами, за исключением. Тот же пубге взял шутан-выживач от 3 лица и добавил туда кольцо сужающиеся. Тоесть чисто технически менять в движке даже ничего не надо. Карточные игры и до этого были, прото близы смогли в рекламу и дизайн.
А игры с реально специфичными механиками которые надо прям кодить , типо Dice Dungeon(вроде?), крайне редко выстреливают и обычно умирают ещё до того как кто-то это популяризирует. Как пример игры типа Vampire Survivos были и до неё, я ещё в 2014 в такие игры играл, но популярность только сейчас обрели.
Так что уважаемый выше прав, играм с базовым геймплеем + фичи гораздо легче выстрелить и заработать что-то.
Так что уважаемый выше прав, играм с базовым геймплеем + фичи гораздо легче выстрелить и заработать что-то.
Тем не менее, я что-то не помню сотен выстреливших проектов на RPG Maker'e
Неважно, насколько простая или сложная идея у упомянутых Вами игр - они все были написаны без изпользования "фреймворка для написания %s игр". Можно сделать сейчас фреймворк для генерации клонов VS, но будут ли они успешны?
Нафига, у Майнкрафта есть достойны клон -Vintage Story. Но у него проблема - в нем нет цели. И у всех клонов минесруфта его нет. У той игры есть огромный потенциал для Лора, даже эти крутые шейдеры с временной нестабильностью много идей генерят. Я написал разработчикам почему они не развивают игру в эту сторону - "ну мы эта, крч, виживание реалистичное же хотим, аэ, лор сложно, а нам и так платят нормально" - вот что я услышал.
Так что да, минесруфт форевер.
А еще есть вариант того ,что выбранный фреймворк как и "самописный" перестанет попадать в видение проекта и получим те же сложности, но уже в плоскости смены фреймворка.
Тут наверное основой вывод - это то, что перед тем как сесть писать код нужно все хорошо спроектировать, но это требует много времени, поэтому так мало кто делает. Выбирают эволюционный подход, но в ходе эволюции не все решения выживают.
В одной книге про чистый код прочитал золотые слова: "For decades of using the terms programming languages, we thought that they were languages to communicate our ideas to the machine, so it can run our programs. We were wrong. That's not the truth, but part of the truth. The real language behind programming languages is to communicate our ideas to other developers."
Проблема не в том, что "начали исходя из одних предположений, а потом все изменилось." Нет, она глубже. Проблема в том, что большинство участников проекта в принципе плохие инженеры.
На эту тему я могу распинаться долго, но пока остановлюсь на одном аспекте: именование сущностей. Классы, функции должны в своем имени содержать контракт на то, что они собой представляют, как их использовать, каковы планы автора на дальнейшее расширение функционала. Благодаря грамотному имени и интерфейсу становится возможной идиома "разделяй и властвуй": во время ревью можно сказать, соответствует ли реализация метода его имени и сигнатуре, и если нет, то это можно считать ошибкой. А в вызывающем коде можно сделать предположение о функционале вызываемого метода только по его названию. Но беда в том, что разработчики сами плохо понимают, что именно они пытаются сварганить, а потому сгребают пыль под ковер, давая сущностям "обобщенные" имена вроде "compute", "process", и т.д. В итоге такой код становится легаси даже не с написания первой строчки, а с момента найма сотрудника.
Закончу еще одной цитатой, которую приписывают то Фейнману, то Эйнштейну: "Если вы что-то не можете объяснить 6-летнему ребёнку, вы сами этого не понимаете." Если вы сами себе не в состоянии объяснить, что вы делаете, дав сущностям подходящие имена, а в коммит-месседжах четко описав идею, которой вы руководствуетесь -- то не надо валить вину за дальнейшие проблемы на "изменившиеся обстоятельства".
Помимо названия функции, огромную роль играют типы входных и выходных параметров.
В Хаскеле по ним вообще поиск сделан.
Ну я говорил не только об именах, но и об интерфейсах и сигнатурах. При этом искусство называть сущности своими именами вызывает меньше разногласий, чем, допустим, порядок аргументов.
искусство называть сущности своими именами вызывает меньше разногласий, чем, допустим, порядок аргументов.
Да как вы посмели!? Естественно, называть их нужно по ISO схеме:
[module name]_[class name]_[func name]_argument_number_[argument index]!!
Например:
func ... (render_render_render_argument_number_0, render_render_render_argument_number_1)А вообще, напомнило статью про ниндзя-код, который пишут истинные ниндзя.
Нет никакого "работающего кода", есть только переход неработающего кода — в работающий, и работающего — в неработающий. Т.е. "становление". Привет Гегелю :)
Эволюция игрового фреймворка. Постановка проблемы