Dọn dẹp mã được tạo: Tái cấu trúc hoặc bản đồ?

Bối cảnh:

Gần đây tôi đã phải đối phó với một tệp lớp được tạo bởi XSD.exe. Nó dài 3500 dòng với các tên lớp / tên biến đổi kỳ cục (nghĩ someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd- khó so sánh trong nháy mắt someRidiculouslyLongPrefixThenMaybeOneOtherThingChanged) và các chú thích ở khắp mọi nơi. Điểm mấu chốt là tôi mất nhiều thời gian để tìm ra cái quái gì đang diễn ra. Tôi đọc nó và nghĩ rằng tôi sẽ không bao giờ đặt tên mình bên cạnh một cái gì đó nên ... Không sạch sẽ.

Câu hỏi:

1) Có phải thực tế xấu khi gây rối với mã được tạo (nghĩa là làm sạch nó).

2) Sẽ tốt hơn nếu viết một trình ánh xạ để ánh xạ các lớp được tạo thành các lớp sạch, đẹp của riêng tôi (mà sau đó tôi có thể làm việc cùng, khá vui vẻ)?

BIÊN TẬP:

Cảm ơn tất cả các ý kiến.

Nếu tôi thực sự sẽ làm bất cứ điều gì thú vị với nó (ví dụ nếu có các đối tượng miền là bất cứ thứ gì ngoại trừ các đối tượng vận chuyển) thì tôi nghĩ rằng tôi sẽ ánh xạ chúng đến các lớp 'sạch hơn', dù sao tôi cũng phải làm bất cứ điều gì loại chức năng trong số họ. Trong trường hợp này, các lớp là DTOs một cách hiệu quả vì vậy có lẽ nó có ý nghĩa rằng việc đặt tên phù hợp với các yếu tố tương ứng. Như đã nêu, tôi không cần phải chạm vào nó - chỉ cần gọi người truy cập / trình biến đổi trước khi chuyển dữ liệu xuống lớp khác để xử lý.

Hiện tại, tôi nghĩ tôi sẽ để họ yên

Điều nguy hiểm với việc tái cấu trúc mã được tạo để clearn và gọn gàng là nếu nó được tái tạo lại bởi công cụ bởi chính bạn hoặc nhà phát triển khác thì những thay đổi sẽ bị mất.

Nhóm của bạn có thể tự mình vào vị trí mà bạn sẽ tạo mã trong một tệp khác và sao chép nó vào phiên bản đã được làm sạch và tái cấu trúc để áp dụng các thay đổi chỉ mất thời gian và tài nguyên. (Tôi đã ở đó với phiên bản gốc của Entity Framework.)

Nếu bạn không thể sống với các tên được tạo, hãy thay đổi nguồn mà nó tạo ra hoặc làm như bạn đề xuất trong # 2.

Theo nguyên tắc chung, không bao giờ chạm vào mã được tạo, bởi vì làm như vậy có nghĩa là hứa rằng bạn sẽ không bao giờ tạo lại mã đó hoặc bạn sẽ phải làm lại tất cả các thay đổi bạn đã thực hiện. Nếu bạn muốn mã được tạo trông đẹp hơn, bạn phải tự động hóa cả việc tạo mã và dọn dẹp; ví dụ: nếu bạn tạo tệp XML ở đâu đó, bạn có thể muốn chạy nó xmlindentnhư một phần của quy trình xây dựng.

Vì những lý do tương tự, mã được tạo ra không thuộc về kiểm soát nguồn. Bạn đặt dữ liệu và quy tắc dưới sự kiểm soát nguồn và để tập lệnh xây dựng của bạn xử lý việc tạo mã.

Bất kỳ thay đổi nào đối với mã được tạo đều phải thông qua trình tạo mã, nghĩa là, nếu bạn muốn mã được tạo trông khác đi, hãy thay đổi các đầu vào của trình tạo mã, chính trình tạo mã hoặc áp dụng xử lý hậu kỳ theo kịch bản. Nhưng đừng chỉnh sửa bằng tay.

Một ngoại lệ là các trình tạo mã kiểu 'giàn giáo', nơi bạn chạy trình tạo một lần để cung cấp cho bạn một bộ xương mà bạn xây dựng thêm. Với những thứ đó, bạn sẽ không bao giờ chạy lại trình tạo cho cùng một tệp, vì vậy bạn chỉ coi tệp được tạo như một tệp nguồn thông thường và quên rằng nó đến từ một trình tạo.

Tôi hoàn toàn đồng ý với câu trả lời @NikolaiDante (+1).

Trong dotnet / c #, bạn có khái niệm "các lớp một phần": Mã nguồn cho "lớp để sử dụng" bao gồm 2 tệp riêng biệt một phần được tạo và một phần được thêm / chỉnh sửa thủ công. Làm đẹp api của bạn đi vào tập tin "thủ công" sẽ không bị ghi đè bởi bộ mã hóa.

Trong thế giới java / hybris, họ sử dụng tính kế thừa cho mã không được tạo:

Ví dụ, bạn có một Khách hàng đẳng cấp với "api-beautifying" của bạn kế thừa từ "GeneratedCustomer".