Потім з'являється зелене світло, і намагаючись прибрати речі, хтось пише GameManager. Ймовірно, щоб влаштувати купу GameStates, можливо, щоб зберігати кілька GameObjects, нічого великого, насправді. Милий, маленький, менеджер.
Знаєте, коли я це читав, у мене в голові мало тривог. Об'єкт з назвою "GameManager" ніколи не буде симпатичним чи маленьким. А хтось це зробив, щоб очистити код? Як це виглядало раніше? Гаразд, жартуємо вбік: назва класу має бути чіткою ознакою того, що робить клас, і це повинно бути одне (також: принцип єдиної відповідальності ).
Крім того, ви можете все-таки опинитися з таким об'єктом, як GameManager, але, очевидно, він існує на дуже високому рівні, і він повинен стосуватися завдань високого рівня. Ведення каталогу ігрових об’єктів? Можливо, Полегшення спілкування між ігровими об’єктами? Звичайно. Обчислення зіткнень між об'єктами? Немає! Ось чому назви менеджера імен нахмурюються - воно занадто широке і дозволяє сильно зловживати під цим банером.
Швидке правило щодо розмірів класу: якщо ви стикаєтеся з кількома сотнями рядків коду на клас, щось починає йти не так. Без зайвого завищення, скажімо, 300 LOC - це кодовий запах для мене, і якщо ви збираєтеся перевищити 1000, дзвінки попереджувальних сигналів повинні згасати. Вважаючи, що так чи інакше 1000 рядків коду зрозуміти простіше, ніж 4 добре структуровані класи по 250 у кожному, ви себе в оману.
Коли час стає проблемою, немає можливості написати окремий клас або розділити цього гігантського менеджера на субменеджерів.
Я думаю, що це так лише тому, що проблемі дозволено поширюватися до того моменту, коли все є повним безладом. Практика рефакторингу - це дійсно те, що ви шукаєте - вам потрібно постійно вдосконалювати дизайн коду невеликими кроками .
Що б ви запропонували, щоб цього не сталося?
Проблема не технологічна, тому не слід шукати технологічних виправлень. Проблема полягає в тому, що у вашій команді є тенденція до створення монолітних фрагментів коду, і віра в те, що в середньо / довгостроковій перспективі так чи інакше вигідно працювати так. Також здається, що команді бракує сильної архітектурної позиції, яка керувала б архітектурою гри (або, принаймні, ця людина занадто зайнята для виконання цього завдання). В основному єдиним виходом є те, щоб члени команди визнали, що таке мислення неправильне. Це нікому не сприяє. Якість продукту погіршиться, а команда лише витратить ще більше ночей на виправлення речей.
Хороша новина полягає в тому, що негайні, відчутні переваги написання чистого коду настільки великі, що майже всі розробники дуже швидко усвідомлюють свої переваги. Переконайте команду працювати таким чином деякий час, результати зроблять решту.
Важкою частиною є те, що вироблення почуття до того, що є поганим кодом (і таланту швидкого придумати кращий дизайн) - одна з найскладніших навичок засвоєння розвитку. Моя пропозиція покладається на надію, що у вас є хтось досить старший в команді, який може це зробити - набагато простіше переконати людей у цьому.
Редагувати - трохи більше інформації:
Взагалі, я не думаю, що ваша проблема обмежується розробкою ігор. По суті, це проблема інженерії програмного забезпечення, звідси мої коментарі в цьому напрямку. Що може відрізнятись від природи індустрії розвитку ігор, чи більше її орієнтовані результати та терміни, ніж інші типи розвитку, я не впевнений.
Зокрема, для розробки ігор, відповідь на це питання в StackOverflow щодо порад щодо "особливо архітектури ігор" говорить:
Дотримуйтесь твердих принципів об'єктно-орієнтованого дизайну ....
Це по суті саме те, що я говорю. Коли я під тиском, я також пишу великі фрагменти коду, але я просвердлив це в голові, що це технічна заборгованість. Що, як правило, добре працює для мене, - це витратити першу половину (або три чверті) дня на створення великої кількості коду середньої якості, а потім посидіти і подумати над цим деякий час; зробити трохи дизайну в моїй голові, або на папері / дошці, про те, як трохи покращити код. Часто я помічаю повторюваний код і можу фактично зменшити загальний рядок коду, розбиваючи речі, увесь час покращуючи читабельність. Цього разу вкладений час окупається так швидко, що називати його «інвестицією» звучить нерозумно - досить часто я збираю помилок, які, можливо, витратили б половину дня (тиждень пізніше), якби я дозволив йому продовжуватись.
- Виправте речі в той же день, коли ви їх кодуєте.
- Ви будете раді, що зробили це протягом кількох годин.
Дійсно повірити у вищесказане важко; Мені вдалося зробити це за власну роботу лише тому, що я переживав наслідки знову і знову. Незважаючи на це, мені все ще важко виправдати встановлення коду, коли я міг би робити більше ... Тому я точно розумію, звідки ви родом. На жаль, ця порада, мабуть, занадто загальна і нелегка. Я дуже вірю в це, однак! :)
Щоб відповісти на ваш конкретний приклад:
Чистий код дядька Боба робить дивовижну роботу підсумовувати, що таке хороша якість. Я випадково погоджуюся з майже всім його змістом. Отже, коли я думаю про ваш приклад класу 30 000 LOC-менеджера, я не можу погодитися з частиною "доброї причини". Я не хочу звучати образливо, але думаючи, що таким чином призведе до проблеми. Немає вагомих причин мати стільки коду в одному файлі - це майже 1000 сторінок тексту! Будь-яка перевага локальності (швидкість виконання або простота дизайну) буде негайно скасована тим, що розробники повністю заблукають, намагаючись орієнтуватися на цю жахливість, і це ще до того, як ми обговоримо об'єднання тощо.
Якщо ви не впевнені, найкращим моїм пропозицією було б взяти копію вищезгаданої книги та переглянути її. Застосування такого типу мислення призводить до того, що люди добровільно створюють чистий, зрозумілий код, який добре структурований.