Тогда есть зеленый свет, и, чтобы очистить вещи, кто-то пишет GameManager. Возможно, для хранения нескольких GameStates, может быть, для хранения нескольких GameObjects, ничего особенного, правда. Милый, маленький, менеджер.
Знаете, когда я читал это, у меня в голове возникали маленькие тревоги. Объект с именем «GameManager» никогда не будет милым или маленьким. И кто-то сделал это, чтобы очистить код? Как это выглядело раньше? Хорошо, оставим в стороне шутки: имя класса должно быть четким указанием на то, что делает класс, и это должно быть одно (иначе: принцип единой ответственности ).
Кроме того, вы все равно можете получить такой объект, как GameManager, но, очевидно, он существует на очень высоком уровне, и он должен заниматься задачами высокого уровня. Ведение каталога игровых объектов? Может быть. Облегчение общения между игровыми объектами? Конечно. Вычисление столкновений между объектами? Нет! Именно поэтому имя менеджера не одобряется - оно слишком широкое и допускает много злоупотреблений под этим баннером.
Быстрое правило о размерах классов: если вы используете несколько сотен строк кода на класс, что-то начинает идти не так. Не переусердствовав, скажем, что-нибудь свыше 300 LOC - это кодовый запах для меня, и если вы наберете более 1000, должны прозвучать предупреждающие сигналы. Полагая, что каким-то образом 1000 строк кода проще для понимания, чем 4 хорошо структурированных класса по 250 в каждом, вы вводите себя в заблуждение.
Когда время становится проблемой, нет способа написать отдельный класс или разделить этого гигантского менеджера на суб-менеджеров.
Я думаю, что это так только потому, что проблема может распространяться до такой степени, что все в полном беспорядке. Практика рефакторинга - это действительно то, что вы ищете - вам нужно постоянно улучшать дизайн кода небольшими шагами .
Что бы вы предложили, чтобы этого не случилось?
Проблема не технологическая, поэтому вам не нужно искать технологические решения для нее. Проблема заключается в следующем: в вашей команде есть тенденция создавать монолитные фрагменты кода, и есть убеждение, что в среднесрочной / долгосрочной перспективе так или иначе работать так. Также кажется, что команде не хватает сильного архитектурного лидера, который бы руководил архитектурой игры (или, по крайней мере, этот человек слишком занят, чтобы выполнить эту задачу). По сути, единственный выход состоит в том, чтобы члены команды поняли, что это неправильное мышление. Это никто не одобряет. Качество продукта ухудшится, и команда будет проводить еще больше ночей, исправляя вещи.
Хорошей новостью является то, что непосредственные ощутимые преимущества написания чистого кода настолько велики, что почти все разработчики очень быстро осознают свои преимущества. Убедите команду работать так некоторое время, результаты сделают все остальное.
Сложность заключается в том, что развитие чувства плохого кода (и способности быстро придумывать лучший дизайн) является одним из наиболее сложных навыков, которые необходимо освоить при разработке. Мое предложение основано на надежде, что в команде есть кто-то достаточно высокопоставленный, кто сможет это сделать - гораздо проще убедить людей таким образом.
Редактировать - немного больше информации:
В общем, я не думаю, что ваша проблема ограничена разработкой игр. По сути, это проблема разработки программного обеспечения, поэтому мои комментарии в этом направлении. Я не уверен, может ли отличаться природа индустрии разработки игр, более ли она ориентирована на результаты и сроки выполнения, чем другие виды разработки.
Тем не менее, специально для разработки игр принятый ответ на этот вопрос в StackOverflow, касающийся советов «особенно игровой архитектуры», гласит:
Следуйте твердым принципам объектно-ориентированного дизайна ....
По сути, это именно то, что я говорю. Когда я нахожусь под давлением, я также нахожу себя пишущим большие куски кода, но я просверлил это в моей голове, что это технический долг. Что хорошо работает для меня, так это потратить первую половину (или три четверти) дня на создание большого количества кода среднего качества, а затем расслабиться и немного подумать; В своей голове или на бумаге / доске делаю немного о том, как немного улучшить код. Часто я замечаю повторяющийся код и могу фактически сократить общее количество строк кода, разбивая их на части, одновременно улучшая читабельность. Инвестированное время окупается так быстро, что называть его «инвестицией» звучит глупо - довольно часто я выявляю ошибки, которые могли бы потратить впустую половину моего дня (неделю спустя), если бы я позволил этому продолжаться.
- Исправьте вещи в тот же день, когда вы их кодируете.
- Вы будете рады, что сделали это в течение нескольких часов.
Достичь веры в вышесказанное сложно; Мне удалось сделать это для моей собственной работы только потому, что я снова и снова испытывал эффекты. Несмотря на это, мне все еще трудно оправдать исправление кода, когда я мог бы производить больше ... Так что я определенно понимаю, откуда вы пришли. К сожалению, этот совет, возможно, слишком общий, и его нелегко выполнить. Я твердо верю в это, однако! :)
Чтобы ответить на ваш конкретный пример:
Чистый код дяди Боба делает потрясающую работу по обобщению кода хорошего качества. Я согласен почти со всем его содержанием. Поэтому, когда я вспоминаю ваш пример с менеджером класса 30 000 LOC, я не могу действительно согласиться с частью «веских оснований». Я не хочу звучать оскорбительно, но такое мышление приведет к проблеме. Нет веской причины иметь столько кода в одном файле - это почти 1000 страниц текста! Любая выгода от локальности (скорость выполнения или «простота» дизайна) будет немедленно аннулирована разработчиками, которые полностью увязнут в попытках ориентироваться в этом чудовище, и это даже до того, как мы обсудим слияние и т. Д.
Если вы не уверены, мое лучшее предложение - взять копию вышеприведенной книги и просмотреть ее. Применение такого типа мышления приводит к тому, что люди добровольно создают чистый, не требующий пояснений код, который хорошо структурирован.