Máy phát mã có bị hỏng không?

Question

Tôi sử dụng MyGeneration cùng với nHibernate để tạo các đối tượng POCO cơ bản và các tệp ánh xạ XML. Tôi đã nghe một số người nói rằng họ nghĩ rằng máy phát điện không phải là một ý tưởng hay. Suy nghĩ tốt nhất hiện nay là gì? Có phải đó là việc tạo mã không tốt khi nó tạo ra hàng nghìn dòng mã không dễ hiểu?

Answer 1

Mã do trình tạo mã tạo ra không nên (như tổng quát) được sử dụng trong trường hợp sau đó nó được chỉnh sửa bởi sự can thiệp của con người. Một số hệ thống như các trình thuật sĩ trên các hóa thân khác nhau của Visual C++ tạo ra mã mà các lập trình viên sau đó được dự kiến ​​sẽ chỉnh sửa bằng tay.Điều này không phổ biến vì nó yêu cầu các nhà phát triển phải tách rời mã được tạo ra, hiểu nó và thực hiện các sửa đổi. Nó cũng có nghĩa là quá trình tạo ra chỉ là một lần.

Mã được tạo phải nằm trong các tệp riêng biệt từ mã khác trong hệ thống và chỉ được tạo từ trình tạo. Mã mã được tạo nên được đánh dấu rõ ràng để chỉ ra rằng mọi người không nên sửa đổi mã đó. Tôi đã có dịp làm khá một vài hệ thống mã thế hệ của một hay hình thức khác và Tất cả của mã để tạo ra có một cái gì đó như thế này trong lời mở đầu:

-- ============================================================= 
-- === Foobar Module =========================================== 
-- ============================================================= 
-- 
--   === THIS IS GENERATED CODE. DO NOT EDIT. === 
-- 
-- ============================================================= 

Code Generation in Action là khá một cuốn sách hay trên môn học.

Answer 2

lập trường của tôi là mã máy phát điện không phải là xấu, nhưng nhiều công dụng trong số đó là.

Nếu bạn đang sử dụng trình tạo mã để tiết kiệm thời gian viết mã tốt, sau đó tuyệt vời, nhưng thường nó không được tối ưu hóa hoặc thêm rất nhiều chi phí, trong những trường hợp đó tôi nghĩ là xấu.

Answer 3

Trong một số trường hợp (không nhiều) chúng hữu ích. Chẳng hạn như nếu bạn muốn tạo các lớp dựa trên dữ liệu kiểu tra cứu trong các bảng cơ sở dữ liệu.

Answer 4

thế hệ Mã là xấu khi nó làm cho chương trình khó khăn hơn (IE, mã kém tạo ra, hay một cơn ác mộng bảo trì), nhưng họ là tốt khi họ làm cho lập trình hiệu quả hơn.

Họ có thể không phải lúc nào tạo mã tối ưu, nhưng tùy thuộc vào nhu cầu của bạn, bạn có thể quyết định rằng manhours phát triển lưu bù đắp cho một vài vấn đề nhỏ.

Tất cả những gì đã nói, chuôi lớn nhất của tôi với máy phát mã ORM là bảo trì mã được tạo có thể là một Pita nếu những thay đổi giản đồ.

Answer 5

Máy phát mã không phải là xấu, nhưng đôi khi chúng được sử dụng trong các tình huống khi tồn tại một giải pháp khác (tức là khởi tạo một triệu đối tượng khi một mảng đối tượng phù hợp và hoàn thành trong một vài dòng mã).

Tình hình khác là khi chúng được sử dụng không đúng cách, hoặc mã hoá nặng. Quá nhiều người thề các máy tạo mã vì họ đã có trải nghiệm xấu do lỗi hoặc sự hiểu lầm của họ về cách định cấu hình đúng cách.

Nhưng trong và của chính họ, trình tạo mã không phải là xấu.

-Adam

Answer 6

Chúng giống như bất kỳ công cụ nào khác. Một số cho kết quả beter hơn những người khác, nhưng nó là vào người sử dụng để biết khi nào sử dụng chúng hay không. Một cái búa là một công cụ khủng khiếp nếu bạn đang cố gắng vặn vít.

Answer 7

Đây là một trong những vấn đề rất gây tranh cãi. Cá nhân, tôi nghĩ rằng các trình tạo mã thực sự xấu do mã crap chưa được tối ưu hóa mà hầu hết chúng được đưa ra.

Tuy nhiên, câu hỏi thực sự là câu hỏi duy nhất bạn có thể trả lời. Trong rất nhiều tổ chức, thời gian phát triển quan trọng hơn tốc độ thực hiện dự án hoặc thậm chí khả năng bảo trì.

Answer 8

Chúng tôi sử dụng trình tạo mã để tạo các lớp thực thể dữ liệu, các đối tượng cơ sở dữ liệu (như trình kích hoạt, procs được lưu trữ), proxy dịch vụ v.v. Bất kỳ nơi nào bạn thấy nhiều mã lặp lại theo mẫu và nhiều công việc thủ công có liên quan. Tuy nhiên, bạn không nên sử dụng nó quá nhiều để mở rộng mà bảo trì là một nỗi đau. Một số vấn đề cũng phát sinh nếu bạn muốn tạo lại chúng.

Các công cụ như Visual Studio, CodeSmith có mẫu riêng của họ cho hầu hết các tác vụ thông thường và làm cho quá trình này dễ dàng hơn. Nhưng, thật dễ dàng để tự mình tung ra.

Answer 9

Nó thực sự có thể trở thành một vấn đề với khả năng bảo trì khi bạn phải quay lại và không thể hiểu những gì đang xảy ra trong mã.Do đó nhiều lần bạn phải cân nhắc tầm quan trọng của nó là để có được các dự án thực hiện nhanh chóng so với dễ dàng bảo trì

trì <> dễ dàng hay nhanh quá trình mã hóa

Answer 10

tôi sử dụng My Generation với Spaces Entity và tôi không có bất kỳ vấn đề với nó. Nếu tôi có một thay đổi giản đồ, tôi chỉ tạo lại các lớp và tất cả các công trình đều tốt.

Answer 11

Vấn đề lớn nhất tôi gặp phải với trình tạo mã là trong quá trình bảo trì. Nếu bạn sửa đổi mã được tạo và sau đó thực hiện thay đổi đối với giản đồ hoặc mẫu của bạn và cố gắng tạo lại, bạn có thể gặp sự cố.

Một vấn đề là nếu công cụ không cho phép bạn bảo vệ các thay đổi bạn đã thực hiện đối với mã đã sửa đổi thì các thay đổi của bạn sẽ bị ghi đè. Một vấn đề khác mà tôi đã thấy, đặc biệt là với các trình tạo mã trong RSA cho các dịch vụ web, nếu bạn thay đổi mã được tạo quá nhiều, trình tạo sẽ phàn nàn rằng có sự không khớp và từ chối tạo lại mã. Điều này có thể xảy ra cho một cái gì đó đơn giản như thay đổi loại biến. Sau đó, bạn đang mắc kẹt tạo mã cho một dự án khác và kết hợp các kết quả trở lại vào mã ban đầu của bạn.

Answer 12

Chúng hoạt động như một cái nạng có thể vô hiệu hóa khả năng duy trì chương trình của bạn trong thời gian dài.

Answer 13

Tạo mã có thể gây cho bạn một số nỗi buồn nếu bạn muốn kết hợp hành vi vào các lớp học của mình. Một lựa chọn thay thế hiệu quả có thể là các thuộc tính/chú thích và phản xạ thời gian chạy.

Answer 14

Trình biên dịch C++ đầu tiên là các trình tạo mã để giải mã mã C (CFront).

Tôi không chắc liệu đây có phải là đối số hoặc chống lại trình tạo mã hay không.

Answer 15

Nếu máy phát mã chính của bộ tạo khung chính mà Fran Tarkenton đang cố gắng bán cho bạn thì tuyệt đối có!

Answer 16

Trình biên dịch là trình tạo mã, vì vậy chúng không phải là vốn xấu trừ khi bạn chỉ thích lập trình trong mã máy thô.

Tôi tin rằng tuy nhiên các trình tạo mã phải luôn đóng gói hoàn toàn mã được tạo. I E. bạn nên không bao giờ phải sửa đổi mã được tạo bằng tay, mọi thay đổi phải được thực hiện bằng cách sửa đổi đầu vào cho trình tạo và tạo lại mã.

Answer 17

Tôi nghĩ rằng Mitchel đã đánh vào đầu. Tạo mã có vị trí của nó. Có một số trường hợp có hiệu quả hơn khi máy tính thực hiện công việc cho bạn! Nó có thể cung cấp cho bạn sự tự do để thay đổi suy nghĩ của bạn về việc thực hiện một thành phần cụ thể khi chi phí thời gian thực hiện các thay đổi mã là nhỏ. Tất nhiên, nó vẫn có thể quan trọng để hiểu đầu ra của bộ tạo mã, nhưng không phải lúc nào cũng vậy. Chúng tôi đã có một ví dụ về một dự án mà chúng tôi vừa hoàn thành khi một số ứng dụng C++ cần để giao tiếp với ứng dụng C# trên các đường ống có tên. Tốt hơn là chúng tôi nên sử dụng các tệp nhỏ, đơn giản để xác định các thư và có tất cả các lớp và mã được tạo cho mỗi bên của giao dịch. Khi một lập trình viên đang làm việc về vấn đề X, điều cuối cùng họ cần là phải lo lắng về các chi tiết implentation của các thông điệp và việc truy cập bộ nhớ cache không thể tránh khỏi sẽ đòi hỏi.

Answer 18

Tôi đã viết một vài bộ tạo mã trước đây - và thành thật mà nói, chúng đã lưu được nhiều lần một lần!

Khi bạn đã xác định rõ ràng đối tượng - bộ sưu tập - thiết kế điều khiển người dùng, bạn có thể sử dụng trình tạo mã để xây dựng các khái niệm cơ bản cho bạn, cho phép thời gian của bạn làm nhà phát triển được sử dụng hiệu quả hơn trong việc xây dựng nội dung phức tạp , ai thực sự muốn viết hơn 300 tờ khai tài sản công khai và sự thay đổi biến đổi? Tôi thà bị mắc kẹt vào logic kinh doanh hơn là tất cả các nhiệm vụ lặp đi lặp lại mindless.

Answer 19

Đây là câu hỏi về quy trình làm việc. ASP.NET là một trình tạo mã. Công cụ phân tích XAML thực sự tạo ra C# trước khi nó được chuyển thành MSIL. Khi một trình tạo mã trở thành một sản phẩm bên ngoài như CodeSmith được tách biệt khỏi luồng công việc phát triển của bạn, cần phải cẩn thận đặc biệt để giữ cho dự án của bạn được đồng bộ hóa. Ví dụ, nếu mã được tạo ra là ORM đầu ra, và bạn thay đổi lược đồ cơ sở dữ liệu, bạn sẽ phải bỏ hoàn toàn trình tạo mã hoặc sử dụng khả năng của C# để làm việc với các lớp một phần (cho phép bạn thêm các thành viên và chức năng cho một lớp hiện có mà không kế thừa nó).

Cá nhân tôi không thích bản chất bị cô lập/Alt-Tab của luồng công việc máy phát; nếu bộ tạo mã không phải là một phần của IDE của tôi thì tôi cảm thấy nó giống như một kludge. Một số trình tạo mã, chẳng hạn như Entity Spaces 2009 (chưa được phát hành), được tích hợp nhiều hơn các thế hệ máy phát trước đó.

Tôi nghĩ rằng thuốc chữa bách bệnh cho mục đích của các trình tạo mã có thể được hưởng trong các thói quen biên dịch trước. C# và các ngôn ngữ .NET khác thiếu điều này, mặc dù ASP.NET thích nó và đó là lý do tại sao, SubSonic hoạt động rất tốt cho ASP.NET nhưng không có nhiều thứ khác. SubSonic tạo mã C# tại thời điểm xây dựng ngay trước khi biên dịch ASP.NET bình thường.

Yêu cầu nhà cung cấp công cụ của bạn (tức là Microsoft) hỗ trợ các quy trình dựng sẵn kỹ hơn để các trình tạo mã có thể được tích hợp vào luồng công việc của các giải pháp của bạn bằng cách sử dụng siêu dữ liệu, thay vì được quản lý theo cách thủ công như các tệp mã được xuất từ ​​bên ngoài phải được duy trì riêng biệt.

Jon

Answer 20

máy phát điện Mã có thể là một lợi ích cho năng suất, nhưng có một số điều cần tìm kiếm:

Cho phép bạn làm việc theo cách bạn muốn làm việc.

Nếu bạn phải uốn cong mã không được tạo để vừa với mã được tạo, thì có thể bạn nên chọn một cách tiếp cận khác.

Chạy như một phần của công trình xây dựng thông thường của bạn.

Đầu ra phải được tạo vào thư mục trung gian và không được kiểm tra trong kiểm soát nguồn. Tuy nhiên, đầu vào phải được kiểm tra trong điều khiển nguồn.

Không cài đặt

Tốt nhất, bạn kiểm tra các công cụ để kiểm soát nguồn, quá. Làm cho mọi người cài đặt mọi thứ khi chuẩn bị một máy xây dựng mới là tin xấu. Ví dụ, nếu bạn chi nhánh, bạn muốn có thể phiên bản các công cụ với mã.

Nếu bạn phải, hãy tạo một tập lệnh đơn lẻ sẽ lấy một máy sạch với bản sao của cây nguồn và định cấu hình máy theo yêu cầu. Vui lòng hoàn toàn tự động.

Không chỉnh sửa đầu ra

Bạn không cần phải chỉnh sửa đầu ra. Nếu đầu ra không đủ hữu ích, thì công cụ này không hoạt động cho bạn.

Ngoài ra, đầu ra phải nêu rõ rằng đó là tệp được tạo & không được chỉnh sửa.

đầu ra Readable

Sản lượng nên được viết & định dạng tốt. Bạn muốn có thể mở đầu ra & đọc nó mà không gặp nhiều rắc rối.

#line

Nhiều ngôn ngữ hỗ trợ cái gì đó như một chỉ thị #line, cho phép bạn ánh xạ các nội dung của đầu ra trở lại đầu vào, ví dụ như khi sản xuất thông báo lỗi biên dịch hoặc khi bước trong trình gỡ lỗi. Điều này có thể hữu ích, nhưng nó cũng có thể gây phiền nhiễu trừ khi thực hiện tốt, vì vậy nó không phải là một yêu cầu.

Answer 21

Trình tạo mã tuyệt vời, mã xấu không tốt.

Hầu hết các câu trả lời khác trên trang này nằm dọc theo dòng "Không, vì thường mã được tạo không phải là rất tốt".

Đây là một câu trả lời vì người nghèo:

1) Máy phát điện là công cụ như bất cứ điều gì khác - nếu bạn lạm dụng chúng, đừng đổ lỗi cho công cụ này.

2) Nhà phát triển có xu hướng tự hào về khả năng viết mã tuyệt vời một lần, nhưng bạn không sử dụng trình tạo mã cho một dự án tắt.

Chúng tôi sử dụng hệ thống Tạo mã cho sự kiên trì trong tất cả các dự án Java của chúng tôi và có hàng nghìn lớp được tạo trong quá trình sản xuất.

Như một người quản lý Tôi yêu họ vì:

1) Độ tin cậy: Không có lỗi còn lại đáng kể trong mã đó. Nó đã được thử nghiệm rất kỹ lưỡng và tinh tế qua nhiều năm hơn khi gỡ lỗi tôi không bao giờ lo lắng về lớp kiên trì.

2) Tiêu chuẩn hóa: Mỗi mã của nhà phát triển đều giống nhau về khía cạnh này, do đó, ít nhiều cho một chàng trai học hỏi khi chọn dự án mới từ đồng nghiệp.

3) Tiến hóa: Nếu chúng tôi tìm cách tốt hơn để làm những việc chúng tôi có thể cập nhật mẫu và cập nhật 1000 lớp học một cách nhanh chóng và nhất quán.

4) Cách mạng: Nếu chúng ta chuyển sang một hệ thống kiên trì khác trong tương lai thì thực tế là mỗi lớp duy nhất có một API giống hệt nhau làm cho công việc của tôi dễ dàng hơn nhiều.

5) Năng suất: Chỉ là một vài cú nhấp chuột để xây dựng hệ thống đối tượng liên tục từ siêu dữ liệu - điều này tiết kiệm hàng nghìn giờ nhà phát triển nhàm chán.

Tạo mã giống như sử dụng trình biên dịch - trên cơ sở từng trường hợp, bạn có thể viết ngôn ngữ assembly được tối ưu hóa tốt hơn, nhưng trên số lượng lớn các dự án bạn muốn trình biên dịch thực hiện đúng không?

Chúng tôi sử dụng một mẹo đơn giản để đảm bảo rằng các lớp học luôn có thể được tạo lại mà không làm mất các tùy chỉnh: mọi lớp được tạo là trừu tượng. Sau đó, nhà phát triển mở rộng nó với một lớp cụ thể, thêm logic nghiệp vụ tùy chỉnh và ghi đè bất kỳ phương thức lớp cơ sở nào mà anh ta muốn khác với tiêu chuẩn. Nếu có thay đổi về siêu dữ liệu, anh ta có thể tạo lại lớp trừu tượng bất cứ lúc nào và nếu mô hình mới phá vỡ lớp bê tông của trình biên dịch sẽ cho anh ta biết.

Answer 22

Sai lầm mà nhiều người thực hiện khi sử dụng tạo mã là chỉnh sửa mã được tạo. Nếu bạn ghi nhớ rằng nếu bạn cảm thấy như bạn cần phải chỉnh sửa mã, bạn thực sự cần phải chỉnh sửa công cụ tạo mã, đó là một lợi ích cho năng suất. Nếu bạn liên tục chiến đấu mã được tạo ra nó sẽ kết thúc lên chi phí năng suất.

Trình tạo mã tốt nhất mà tôi tìm thấy là những trình tạo mã cho phép bạn chỉnh sửa các mẫu tạo mã. Tôi thực sự thích Codesmith vì lý do này, bởi vì nó dựa trên mẫu và các mẫu có thể chỉnh sửa dễ dàng. Khi bạn tìm thấy có sự thiếu hụt trong mã được tạo ra, bạn chỉ cần chỉnh sửa mẫu và tạo lại mã của bạn và bạn mãi mãi tốt sau đó.

Điều khác mà tôi thấy rằng rất nhiều trình tạo mã không phải là siêu dễ sử dụng với hệ thống kiểm soát nguồn. Cách chúng tôi nhận được xung quanh việc này là kiểm tra các mẫu thay vì mã và điều duy nhất chúng tôi kiểm tra vào kiểm soát nguồn được tạo là phiên bản được biên dịch của mã được tạo (tệp DLL, chủ yếu). Điều này giúp bạn tiết kiệm rất nhiều đau buồn bởi vì bạn chỉ phải kiểm tra một vài DLL thay vì hàng trăm tệp được tạo ra.

Answer 23

Ứng dụng tốt nhất của trình tạo mã là khi toàn bộ dự án là một mô hình và tất cả mã nguồn của dự án được tạo ra từ mô hình đó. Tôi không nói UML và crap liên quan. Trong trường hợp này, mô hình dự án cũng chứa mã tùy chỉnh.

Sau đó, điều duy nhất mà nhà phát triển phải quan tâm là mô hình. Một thay đổi kiến ​​trúc đơn giản có thể dẫn đến việc sửa đổi tức thời hàng nghìn dòng mã nguồn. Nhưng mọi thứ vẫn đồng bộ.

Đây là cách tiếp cận tốt nhất của IMHO. Âm thanh không rõ ràng? Ít nhất tôi biết nó không phải là;) Tương lai gần sẽ nói.

Answer 24

Trong một dự án gần đây, chúng tôi đã tạo trình tạo mã của riêng mình. Chúng tôi đã tạo tất cả nội dung cơ sở dữ liệu và tất cả mã cơ sở cho các lớp trình điều khiển chế độ xem và chế độ xem của chúng tôi.Mặc dù máy phát điện mất vài tháng để xây dựng (chủ yếu là vì đây là lần đầu tiên chúng tôi thực hiện việc này và chúng tôi đã có một vài lần bắt đầu sai), đây là lần đầu tiên chúng tôi chạy và tạo khung cơ bản cho toàn bộ ứng dụng Khoảng mười phút. Đây là tất cả trong Java, nhưng Ruby làm cho một ngôn ngữ viết mã tuyệt vời đặc biệt cho các dự án loại nhỏ, một lần. Điều tốt nhất là tính thống nhất của mã và tổ chức dự án. Ngoài ra, bạn phải suy nghĩ về khuôn khổ cơ bản trước thời hạn, điều luôn tốt.

Answer 25

Dự án hiện tại của chúng tôi sử dụng nhiều bộ tạo mã. Điều đó có nghĩa là tôi đã thấy cả lợi ích "rõ ràng" của việc tạo mã lần đầu tiên - không có lỗi mã hóa, không lỗi chính tả, tuân thủ tốt hơn với kiểu mã hóa chuẩn - và sau vài tháng ở chế độ bảo trì, những nhược điểm bất ngờ. Máy phát mã của chúng tôi đã làm, thực sự, cải thiện chất lượng codebase của chúng tôi ban đầu. Chúng tôi đảm bảo rằng nó hoàn toàn tự động và được tích hợp với các bản dựng tự động của chúng tôi. Tuy nhiên, tôi sẽ nói rằng:

(1) Trình tạo mã có thể là một cái nạng. Chúng ta có một số blob nặng, xấu xí của mã khó duy trì trong hệ thống của chúng ta bây giờ, bởi vì tại một thời điểm trong quá khứ, việc thêm hai mươi lớp mới vào tệp XML tạo mã của chúng ta dễ dàng hơn là phân tích và lớp thích hợp tái cấu trúc.

(2) Ngoại lệ đối với quy tắc sẽ giết bạn. Chúng tôi sử dụng trình tạo mã để tạo hàng trăm lớp Screen và Business Object. Ban đầu, chúng tôi thực thi một tiêu chuẩn về những phương pháp có thể xuất hiện trong một lớp học, nhưng cũng giống như tất cả các tiêu chuẩn, chúng tôi bắt đầu thực hiện các ngoại lệ. Bây giờ, tệp XML tạo mã của chúng ta là một con quái vật khổng lồ, chứa đầy các đoạn mã Java đặc biệt được chèn vào các lớp được chọn. Nó gần như không thể phân tích hoặc hiểu được.

(3) Vì rất nhiều mã của chúng tôi được tạo ra, sử dụng các giá trị từ cơ sở dữ liệu, nên các nhà phát triển đã duy trì một cơ sở mã nhất quán trên máy trạm cá nhân của họ (vì có thể có nhiều phiên bản của cơ sở dữ liệu). Gỡ lỗi và truy tìm thông qua phần mềm là khó khăn hơn nhiều, và những người mới làm quen với nhóm mất nhiều thời gian hơn để tìm ra "dòng chảy" của mã, bởi vì sự trừu tượng thêm và các mối quan hệ ngầm định giữa các lớp. IDE không thể nhận các mối quan hệ giữa hai lớp giao tiếp thông qua một lớp được tạo mã.

Điều đó có thể là đủ cho bây giờ. Tôi nghĩ rằng Code Generator là một phần của bộ công cụ cá nhân của nhà phát triển; một tập hợp các kịch bản viết ra mã soạn sẵn của bạn làm cho việc bắt đầu một dự án trở nên dễ dàng hơn nhiều. Nhưng Code Generator làm không làm cho vấn đề bảo trì biến mất.

Answer 26

Trình tạo mã rất tốt khi giả sử nó là trình tạo mã tốt. Đặc biệt là làm việc C++/java rất tiết tú.