Про оценку готовности компонент

Вот мне интересно, пользуется ли кто-либо какими либо системами классификации готовности и работоспособности библиотек. Понятно, что вопрос достаточно сложный, зависит от особенностей разработки, назначения компоненты и т.д. Но тем не менее, лично для меня вопрос весьма и весьма интересный.

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

В общем, вот личная классификация различных библиотек, которой я пользуюсь в работе.
Поскольку все таки бывший преподаватель, от стандартной школьной системы оценок мне не уйти, поэтому пользуюсь исключительно системой оценок неуд-уд-хор-отл. Только добавляю к ним плюсы и минусы в неприличных количествах. Итак:


“Неудовлетворительно”.

2. Компилируется, но не работает.

“Удовлетворительно”. Базовая функциональность.

3 – -. Что-то там написано, как-то там работает. Как пользоваться (причем так, чтобы не упало), знает только владелец, остальные могут только спрашивать “а как следать так, что бы было то-то и то-то”.

3 -. Основные баги методом проб и ошибок (или методом Unit tests, что встречается сильно реже) вычищены. Хотя интерфейс как был убогий, так и остался.

3. Ценой длительных ругательств интерфейс усовершенствован до состояния, что функциями стало можно пользоваться. Баги в целом вычищены, хотя на нестандартных данных поведение системы неизвестно даже ее владельцу.

3 +. Добавлено протоколирование и ассертная диагностика. Хотя огромное количество обслуживающего кода приходится писать руками, хотя многое из запланированного не реализовано, подсистема живет с удовлетворительным перформансом. Есть что-то похожее на документацию.

3 + +. На том уровне и с той функциональностью, которая предполагается в базовом варианте система вычищена и вылизана. Баги и неопределенное поведение устранены насколько это возможно. Об ошибках в работе компоненты (включая ее вызовы) можно разобраться по логам. Присутствует вменяемая документация, примеры работ и комментарии.

“Хорошо”. Расширенная функциональность. На этапах от 3 – - до 3 + + набиты основные шишки, теперь то уж точно понятно, как его надо писать, что еще надо добавлять в систему, можно двигаться дальше.

4 – -. Первая реализация расширенной функциональности. Если это не переписывание с нуля, то какие-то полезные части из предыдущих пунктов сохранились, хотя документацию надо переделывать, а количество багов резко увеличилось в несколько сотен раз.

4 -. Интерфейс более менее стабилизирован, в отличие от предыдущего перехода в этапе “3 – -” – “3 -” появилось еще и понимание того, как делать интерфейс библиотеки расширяемым так, чтобы это не затрагивало (или затрагивало по минимуму) действующей функциональности. Основные баги почищены.

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

4 +. Введены дополнительные функции протоколирования и диагностики. Система работает стабильно, ей можно пользоваться. За счет стресс-тестов перформанс системы поднят до хорошего уровня. Отсутствуют очевидные bottlenecks. Количество багов сведено к стандартному минимуму.

4 + +. Система вычищена и вылизана, документация приведена в соответствие функционалу. Подсистема работает, понятно, как и куда ее можно безболезненно расширять.

“Отлично”. “Полная функциональность.

5 – -. Функционал системы расширяется новыми возможностями для решения задач в приложениях разных типов и жанров (также, возможно, на разных платформах), однако поскольку это расширение системы, опирающееся на предыдущую хорошо отлаженную и продиагностированную функциональность, подобное развитие не влечет за собой фатальных сбоев в имеющемся коде, использующем данную компоненту. Кроме того, ошибки в новых возможностях также быстро диагностируются за счет функций более низкого уровня.

5 -. Система имеет максимально требуемую производительность. Отсутствуют очевидные bottlenecks. Имеются полноценные протоколы и диагностика вызовов. Количество багов сведено к стандартному минимуму.

5. Актуализация документации. Система имеет функционал, который позволяет использовать ее во множестве проектов, как в виде исходных кодов, так и в виде собранных библиотек.

Еще раз оговорюсь – подобная классификация не претендует на полноту и объективность. Составлена исключительно для своих собственных нужд. Но определенные переходы в системе можно переложить на любые проекты.

Например, рассмотрим систему анимации. Если переложить абстрактные “базовая”, “расширенная” и “полная” функциональность на нее, то получим примерно следующее:

  • 3 – -. Как-то работает. Есть SetAnimation(name, time), если модель правильная и если вызывать функцию правильно, то она даже отрендерится.
  • 3 -. Работает на всех моделях, но процедурные корректировки не добавить.
  • 3. Работает на всех моделях. Теперь если никакая анимация не воспроизводится, даже не надо вызывать SetAnimation(“”, 0) на первом этапе, чтобы привести ее в чувство.
  • 3 +. Системой можно пользоваться для проигрывания анимаций, причем ее даже запотимайзили по скорости выполнения.
  • 3 + +. Система работает стабильно и устойчиво, пользоваться ей может кто угодно из программистов компании. Нормально поддерживаются процедурные анимации.
  • 4 – -. Начали добавлять блендинг анимаций и воспроизведение анимационных подпоследовательностей.
  • 4 -. Блендинг устойчиво заработал.
  • 4. Появилась возможность добавлять информацию о графе переходов между анимациями (в рамках подсистемы анимации про редактирование графа речи не идет – это отдельные UI подсистемы). Анимации могут быть согласованы с физикой для корректировки перемещения игрока/скорости воспроизведения анимаций для предотвращения проскальзываний, проваливаний и т.п.
  • 4 +. Блендинг, секвенции, анимграф работают успешно и хорошо оптимизированны по времени (а может быть и по памяти).
  • 4 + +. Система имеет всю необходимую документацию, тесты, протоколы и runtime диагностику. Правильно обрабатываются все анимационные модели, те, которые не могут корректно воспоизводится, правильно репортят сообщения об ошибках.
  • 5 – -. Появилась возможность добавлять дополнительные модификаторы. Инверсная кинематика, регдолы, гибкие сочленения, … Все это легко надстраивается на систему.
  • 5 -. Кроме того, что оно легко надстраивается, оно теперь еще и работает на 100% адекватно с любыми входными моделями, удовлетворяющими четким спецификациям.
  • 5. Система находится в финальном состоянии.

Если посмотреть с другой стороны, то развитие игр у многих компаний проходит по принципу “сделали технологически убогую игру”, “сделали клон получше” – “сделали игру в другом жанре”. Оно тоже хорошо ложится на развитие 3-4-5: “потрахались с базовым функционалом” – “сделали получше” – “реализовали так, чтобы можно было пользовать независимо от игры”.

Выводов можно сделать несколько:

  1. Для игры достаточно уровней “3″-”4″. “5″ не надо, только если оно не получилось автоматически в результате длительных разработок (и то – само оно не получится, максимум – это “5 -”).
  2. Для продаваемого движка достаточным уровнем является 4 или 5. Причем обязательно со статусом “+” или “+ +”. В противном случае вы заранее обрекаете несчастных лицензиатов на длительный и мучительный секс.
  3. Восхождение в пределах одной оценки как правило длительное и мучительное. Перескакивание в следующую категорию незавершенного варианта возможно, но как правило сопровождается откатом вниз – с “+” до “- -”, например.
  4. Быстрые переходы из фазы например “3 -” в фазу “4 – -” могут быть сильно губительны для проекта. Потому что суммарное накопление багов будет приводит к поистине фантастическим задержкам. Сильно лучше для проекта будет, если та или иная библиотека проходит через правильные этапы развития, не перескакивая сразу несколько пунктов. В любом случае после этапов или майлстоунов надо давать время на передышку, code review, его причесывание и перевод в следующую категорию.

А вы оцениваете свои библиотеки по какой-либо шкале?

  • shodan

    > множество проблем … при использовании … связаны с тем, что они находились на недопустимом классификационном уровне.

    Не забывай про NIH синдром.

    Самое лютое проявление на моей памяти было, когда движок МК кое-кто переделывал в течение 1+ года совершенно без общения с оригинальными разработчиками и, разумеется, без попыток обновляться и мержиться.

    Было круто.

  • dDIMA

    Есть много вариантов, почему пишется свое:
    1.1. Нет нужного функционала
    1.2. Функционал есть, но непонятно, как им пользоваться
    1.3. …
    2.1. Нет желания разбираться
    2.2. Идите нахрен со своим движком
    2.3. …
    Мне встречались и те, и другие варианты. 1.* это в первую очередь проблемы движка. 2.* – тут все понятно.

  • http://www.gamedezigner.ru WildMaN

    > Для продаваемого движка достаточным уровнем является 4 или 5.
    > Причем обязательно со статусом “+” или “+ +”. В противном случае
    > вы заранее обрекаете несчастных лицензиатов на длительный и мучительный секс.

    Оооо. Много, много секаса. 4+ не катит.

  • look4awhile

    в Sony говорят – internal teams are very capable
    т-е можно отдать отлично работающий необёрнутый код – и будет масса давольных
    а говно сколько не оборачивай или документируй – так и будет говно

  • dDIMA

    Это, естественно все очень субъективно. Но когда берешь ту или иную либу, надо (как и в Vista performance meter :)) смотреть на минимальный коэффициент. Отлично задокументированное говно как имело статус 3–, так в нем и будет пребывать. При этом хорошая, добротная система, пусть даже и без документации (довольно часто документацию можно заменить здравым смыслом или аналогами) все равно будет находиться уровнем выше.