Sau đó, có đèn xanh và trong nỗ lực dọn dẹp mọi thứ, ai đó đã viết một Trình quản lý trò chơi. Có lẽ để chứa một loạt GameStates, có thể để lưu trữ một vài GameObject, thực sự không có gì lớn. Một người quản lý dễ thương, nhỏ bé.
Bạn biết đấy, khi tôi đọc nó, tôi có một chút báo động trong đầu. Một đối tượng có tên "GameManager" sẽ không bao giờ trở nên dễ thương, hoặc nhỏ bé. Và ai đó đã làm điều này để làm sạch mã? Nó trông như thế nào trước đây? OK, đùa qua một bên: tên của một lớp nên là một dấu hiệu rõ ràng về những gì lớp đó làm, và đây phải là một điều (hay còn gọi là nguyên tắc trách nhiệm duy nhất ).
Ngoài ra, bạn vẫn có thể kết thúc với một đối tượng như GameManager, nhưng rõ ràng, nó tồn tại ở mức rất cao và nó phải liên quan đến các nhiệm vụ cấp cao. Duy trì một danh mục các đối tượng trò chơi? Có lẽ. Tạo điều kiện giao tiếp giữa các đối tượng trò chơi? Chắc chắn rồi. Tính va chạm giữa các vật? Không! Đây cũng là lý do tại sao Trình quản lý tên được tán thành - nó quá rộng và cho phép lạm dụng nhiều dưới biểu ngữ đó.
Một nguyên tắc nhanh chóng về quy mô lớp học: nếu bạn đang chạy vào hàng trăm dòng mã cho mỗi lớp, một cái gì đó đang bắt đầu sai. Không quá hăng hái, bất cứ điều gì hơn, nói, 300 LỘC là một mùi mã đối với tôi, và nếu bạn đang đi hơn 1000, tiếng chuông cảnh báo sẽ được tắt. Bằng cách tin rằng bằng cách nào đó, 1000 dòng mã đơn giản hơn để hiểu hơn 4 lớp có cấu trúc tốt gồm 250 lớp, bạn đang tự lừa dối bản thân mình.
Khi thời gian trở thành một vấn đề, không có cách nào để viết một lớp riêng biệt, hoặc tách người quản lý khổng lồ này thành người quản lý phụ.
Tôi nghĩ rằng đây chỉ là trường hợp vì vấn đề được phép truyền bá đến mức mọi thứ là một mớ hỗn độn. Việc thực hành tái cấu trúc thực sự là những gì bạn đang tìm kiếm - bạn cần liên tục cải tiến thiết kế mã theo từng bước nhỏ .
Bạn sẽ đề nghị gì để ngăn chặn điều này xảy ra?
Vấn đề không phải là vấn đề công nghệ, vì vậy bạn không nên tìm cách khắc phục công nghệ cho nó. Vấn đề là ở chỗ: nhóm của bạn có xu hướng tạo ra các đoạn mã nguyên khối và niềm tin rằng bằng cách nào đó có lợi trong trung hạn / dài hạn để làm việc như thế này. Có vẻ như nhóm nghiên cứu đang thiếu một người dẫn đầu về kiến trúc mạnh mẽ, người sẽ điều khiển kiến trúc của trò chơi (hoặc ít nhất, người này quá bận rộn để thực hiện nhiệm vụ này). Về cơ bản, lối thoát duy nhất là để các thành viên trong nhóm nhận ra rằng suy nghĩ này là sai. Nó không ai ủng hộ. Chất lượng của sản phẩm sẽ xấu đi, và nhóm sẽ chỉ dành nhiều đêm hơn để sửa chữa mọi thứ.
Tin tốt là những lợi ích trước mắt, hữu hình của việc viết mã sạch là rất lớn, mà hầu như tất cả các nhà phát triển đều nhận ra lợi ích của họ rất nhanh. Thuyết phục nhóm làm việc theo cách này trong một thời gian, kết quả sẽ làm phần còn lại.
Điều khó khăn là việc phát triển cảm giác về những gì cấu thành mã xấu (và tài năng để nhanh chóng đưa ra một thiết kế tốt hơn) là một trong những kỹ năng khó hơn để học trong quá trình phát triển. Gợi ý của tôi xoay quanh hy vọng rằng bạn có một người đủ cao cấp trong đội có thể làm điều này - việc thuyết phục mọi người theo cách đó sẽ dễ dàng hơn nhiều.
Chỉnh sửa - Thông tin thêm một chút:
Nói chung, tôi không nghĩ vấn đề của bạn chỉ giới hạn ở việc phát triển trò chơi. Về cốt lõi, đó là một vấn đề về công nghệ phần mềm, do đó tôi nhận xét theo hướng đó. Điều có thể khác là bản chất của ngành phát triển trò chơi, cho dù kết quả và thời hạn định hướng của nó nhiều hơn các loại phát triển khác, tôi không chắc chắn.
Cụ thể cho phát triển trò chơi, câu trả lời được chấp nhận cho câu hỏi này trên StackOverflow liên quan đến các mẹo "đặc biệt là kiến trúc trò chơi", cho biết:
Thực hiện theo các nguyên tắc vững chắc của thiết kế hướng đối tượng ....
Đây là cơ bản chính xác những gì tôi đang nói. Khi tôi bị áp lực, tôi cũng thấy mình viết những đoạn mã lớn, nhưng tôi đã khoan nó vào đầu rằng đó là nợ kỹ thuật. Những gì có xu hướng hoạt động tốt đối với tôi, là dành nửa đầu (hoặc ba phần tư) trong ngày để tạo ra một lượng lớn mã chất lượng trung bình, sau đó ngồi lại và suy nghĩ về nó một lúc; làm một chút thiết kế trong đầu tôi, hoặc trên giấy / bảng trắng, về cách cải thiện mã một chút. Thông thường, tôi nhận thấy mã lặp đi lặp lại và có thể thực sự giảm tổng số dòng mã bằng cách phá vỡ mọi thứ, trong khi cải thiện khả năng đọc. Thời gian đầu tư này tự trả tiền rất nhanh, việc gọi đó là "đầu tư" nghe có vẻ ngớ ngẩn - khá thường xuyên tôi sẽ nhận các lỗi có thể lãng phí nửa ngày của tôi (một tuần sau), nếu tôi cho phép tiếp tục.
- Sửa chữa mọi thứ trong cùng một ngày bạn mã hóa chúng.
- Bạn sẽ vui mừng bạn đã làm trong vòng vài giờ.
Đến để thực sự tin những điều trên là khó khăn; Tôi đã quản lý để làm điều đó cho công việc của riêng tôi chỉ vì tôi đã trải nghiệm, nhiều lần, các hiệu ứng. Mặc dù vậy, tôi vẫn khó có thể biện minh cho việc sửa mã khi tôi có thể phát hành thêm ... Vì vậy, tôi chắc chắn hiểu bạn đến từ đâu. Thật không may, lời khuyên này có lẽ quá chung chung, và không dễ thực hiện. Tôi tin tưởng mạnh mẽ vào nó, tuy nhiên! :)
Để trả lời ví dụ cụ thể của bạn:
Clean Code của chú Bob thực hiện một công việc tuyệt vời để tóm tắt mã chất lượng tốt là như thế nào. Tôi đồng ý với hầu hết tất cả các nội dung của nó. Vì vậy, khi tôi nghĩ về ví dụ của bạn về lớp người quản lý 30 000 LỘC, tôi thực sự không thể đồng ý với phần "lý do chính đáng". Tôi không muốn gây khó chịu, nhưng nghĩ rằng cách đó sẽ dẫn đến vấn đề. Không có lý do chính đáng để có nhiều mã trong một tệp - đó là gần 1000 trang văn bản! Bất kỳ lợi ích nào của địa phương (tốc độ thực hiện hoặc thiết kế "đơn giản") sẽ ngay lập tức bị vô hiệu hóa bởi các nhà phát triển bị sa lầy hoàn toàn khi cố gắng điều hướng sự quái dị đó, và thậm chí trước cả khi chúng ta thảo luận về việc hợp nhất, v.v.
Nếu bạn không bị thuyết phục, đề nghị tốt nhất của tôi sẽ là lấy một bản sao của cuốn sách trên và xem qua nó. Áp dụng kiểu suy nghĩ đó để dẫn đến mọi người tự nguyện tạo mã sạch, tự giải thích, được cấu trúc độc đáo.