Việc tạo mã có làm tăng chất lượng mã không?

Tranh luận về việc tạo mã, tôi đang tìm kiếm một số ví dụ về cách làm tăng chất lượng mã. Để làm rõ ý của tôi khi tạo mã, tôi chỉ có thể nói về một dự án của tôi:

Chúng tôi sử dụng các tệp XML để mô tả các mối quan hệ thực thể trong lược đồ cơ sở dữ liệu của chúng tôi, vì vậy chúng giúp chúng tôi tạo khung ORM và các biểu mẫu HTML có thể được sử dụng để thêm, xóa và sửa đổi các thực thể.

Theo tôi, nó làm tăng chất lượng mã vì lỗi của con người đã giảm. Nếu một cái gì đó được thực hiện không chính xác, nó bị hỏng trong mô hình, điều này là tốt vì lỗi có thể xuất hiện sớm hơn do mã được tạo nhiều hơn cũng bị hỏng.

Vì tôi được hỏi về định nghĩa chất lượng mã , hãy để tôi làm rõ điều này, ý tôi là chất lượng phần mềm .

Chất lượng phần mềm : Nó không phải là một thuộc tính mà là nhiều thuộc tính, ví dụ như hiệu quả, khả năng sửa đổi, khả năng đọc, tính chính xác, độ mạnh, tính dễ hiểu, tính khả dụng, tính di động, v.v.

Trình tạo mã không thể tạo mã tốt hơn người đã viết trình tạo.

Kinh nghiệm của tôi với các trình tạo mã là chúng chỉ tốt miễn là bạn không bao giờ phải chỉnh sửa mã được tạo . Nếu bạn có thể tuân theo quy tắc đó, thì bạn tốt để đi. Điều này có nghĩa là bạn có thể tạo lại một cách đáng tin cậy một phần của hệ thống với độ tin cậy và tốc độ, tự động thêm nhiều tính năng hơn nếu cần. Tôi đoán rằng có thể tính cho chất lượng.

Tôi đã từng nghe một lập luận cho các trình tạo mã rằng một lập trình viên duy nhất có thể tạo ra rất nhiều dòng mã mỗi ngày và với các trình tạo mã, họ có thể tạo ra hàng ngàn dòng! Rõ ràng đó không phải là lý do chúng tôi đang sử dụng máy phát điện.

Tôi sẽ tranh luận ngược lại - giả sử bạn đang viết các ứng dụng thú vị, việc tạo mã làm giảm chất lượng mã. Bản chất của việc tạo mã thưởng cho các khung công cụ cắt cookie, quá mức, được chỉ định quá mức trở nên rất khó xử lý mà không liên tục phụ thuộc vào công cụ tạo mã để liên tục tạo ra các bó mã lớn hơn, phức tạp hơn, xấu hơn. Mặc dù nó có thể là một công cụ tốt, nhưng nó thực sự không nên là công cụ chính trong hộp.

Tôi nghĩ việc tạo mã tự động và chất lượng mã có phần trực giao và không nhất thiết phải tương quan.

Tạo mã chỉ là một cách để giải quyết một nhiệm vụ kỹ thuật cụ thể. Việc nó có dẫn đến chất lượng mã tăng lên hay không phụ thuộc vào những gì bạn đang làm.

Tình huống của bạn là một ví dụ điển hình về việc tạo mã dẫn đến chất lượng mã tăng lên thông qua việc bắt kịp các lỗi tiềm ẩn.

Tôi có thể cho bạn một ví dụ khác khi việc tạo mã tự động làm giảm chất lượng mã. Đó là ASP.NET WebForms toàn năng. Nó tự động tạo mã bằng cách dịch một hệ thống phân cấp các điều khiển UI thành đánh dấu HTML, đó là tất cả mọi thứ nhưng ổn định, có thể dự đoán và quản lý được.

Để rút ra kết luận, việc tạo mã tự động có thể giúp tăng chất lượng mã khi được sử dụng đúng cách.

Việc tạo mã không ảnh hưởng đến chất lượng mã , mỗi lần, cũng như tính nhất quán của mã .

Mã được tạo sẽ thống nhất giữa các trường hợp tạo. Nếu trình tạo được thiết kế để phát ra mã chất lượng tốt, thì mã được tạo sẽ có chất lượng tốt nhất quán. Tuy nhiên, nếu trình tạo mã phát ra mã chất lượng kém, thì bạn sẽ nhận được mã xấu liên tục.

Tạo mã cũng có thể được sử dụng để xây dựng mã nhanh hơn . Tuy nhiên, nhanh hơn không có nghĩa là tốt hơn ... Điều đó chỉ có nghĩa là bạn nhận được mã chất lượng kém nhanh hơn nhiều.

Tạo mã là tốt nếu:

• mã được tạo ra không cần phải chỉnh sửa
• trình tạo mã cung cấp cho bạn đủ linh hoạt để làm những gì bạn cần làm
• ngôn ngữ nhập vào trình tạo mã tốt hơn (ví dụ DRY) so với ngôn ngữ bạn thường phải viết
• trình tạo mã tạo mã đáng tin cậy tốt mà bạn không phải lo lắng, ngay cả khi nó dài dòng

Khi đây là trường hợp, mã có chất lượng bạn cần xem xét là mã được nhập vào trình tạo.

Một thước đo đơn giản về chất lượng là, đối với những thay đổi điển hình trong yêu cầu, bạn phải thực hiện chỉnh sửa thủ công bao nhiêu. Càng ít, càng tốt.

Chất lượng mã tăng lên do DRY (Đừng lặp lại chính mình).

Các quy tắc tạo mã được viết một lần; chúng không được mã hóa cứng cho mọi trường hợp mã được tạo và do đó làm giảm khả năng lỗi của con người trong việc sao chép / dán nội dung với các sửa đổi nhỏ.

Tôi giả sử bạn có nghĩa là các trình tạo mã độc quyền được điều khiển để sử dụng cụ thể trong nhà vì nếu không, bất cứ thứ gì thiếu mã máy là một trình tạo mã. Nhưng ở đây bạn đi:

Tôi nghĩ rằng rất có thể tranh cãi rằng biểu đồ nút trong Blueprints dễ bảo trì hơn và ít bị lỗi hơn so với mã GLSL / HLSL mà nó tạo ra (và nếu không cần phải viết tay).

Sẽ rất hiệu quả hơn khi đưa ra các shader mới vì bạn nhận được phản hồi trực quan theo thời gian thực về kết quả cuối cùng trông như thế nào khi bạn thay đổi biểu đồ. Tôi chắc chắn muốn duy trì hàng ngàn shader được biểu thị bằng các biểu đồ nút theo cách này thay vì mã GLSL / HLSL và tôi thực sự quen thuộc hơn với việc viết GLSL / HLSL hơn là sử dụng Blueprints. Tôi nghĩ rằng thực tế không thể gây ra lỗi lớn như vậy ngoài việc có thể có một số trục trặc hình ảnh nhỏ mà bạn có thể mắc phải ngay lập tức vì "ngôn ngữ hình ảnh" áp đặt các ràng buộc hợp lý với phong cách chức năng thuần túy không cho phép bạn nói, đánh sập một shader, ít nhất là AFAIK (Tôi thừa nhận không phải là chuyên gia về Blueprints).

Thậm chí không còn "mã" để duy trì nữa. Bạn chỉ cần đặt các nút bên trong một biểu đồ và vẽ các liên kết giữa chúng và, voila, nó tạo ra mã shader cho bạn. Ai duy trì công cụ này và nói: " Bạn biết đấy, cuộc sống của tôi sẽ dễ dàng hơn rất nhiều và tôi sẽ có nhiều thời gian rảnh hơn nếu điều này chỉ được viết bằng mã GLSL thay vì sử dụng Blueprints. " Có lẽ không bao giờ.

Điều đó nói rằng, tôi đã chạy vào phần chia sẻ của mình về các trình tạo mã độc quyền khiến cuộc sống trở nên khó khăn hơn, khiến tôi học ngôn ngữ meta ngu ngốc này có lợi ích rất hạn chế, nếu có, qua việc viết mã bằng ngôn ngữ của mã mà nó tạo ra. Đối với tôi, một dấu hiệu rõ ràng về việc tạo mã, đó là một dấu hiệu ít hơn là giảm một lượng nhỏ nồi hơi và thực sự không làm giảm khả năng xảy ra lỗi. Bạn biết điều đó thật đặc biệt nếu nó thực sự giới thiệu những cách mới để gây ra lỗi mà ngôn ngữ gốc không có. Nhưng có những trường hợp để tạo mã, như ở trên, trong đó việc tăng năng suất rất lớn, tạo ra những thứ tỉ mỉ tốn thời gian khổng lồ bây giờ tốn rất nhiều tiền, mà không ai sẽ sử dụng nó và sau đó nhìn lại.

Đối với tôi có một lập luận chính đáng hơn cho sự phát triển độc quyền của Blueprints trong nhóm Epic so với nhiều ngôn ngữ lập trình không cần thiết ngoài kia được tạo ra cho công chúng mà hầu như không mang lại điều gì mới mẻ cho bảng.

Tôi có thể nói trong trường hợp của bạn, nó có thể tăng chất lượng một chút, nhưng giảm thời gian phát triển đi rất nhiều. Đôi khi mã được tạo ra không ổn định, vụng về hoặc chỉ đơn giản là xấu. Trong những trường hợp đó, mã được tạo có thể làm giảm chất lượng và thêm thời gian thử nghiệm / sửa chữa / hồi quy cho dự án. Và một số nhiệm vụ quá phức tạp để có thể dễ dàng tạo ra - trình tạo trở thành một hệ thống hoàn toàn riêng biệt (có thể lớn hơn và phức tạp hơn dự án chính) cho chính nó.

Máy tạo mã là tốt, nhưng hãy cẩn thận với chúng!

Tôi đã từng làm việc trong một cửa hàng dựa nhiều vào việc tạo mã. Trong tâm trí của tôi, nó làm cho mã cho dự án rất thống nhất. Và về mặt đó, chất lượng là OK.

Tuy nhiên, khi bạn không còn được phép viết mã tùy chỉnh vì mọi thứ phải thông qua trình tạo thì tôi nghĩ bạn sẽ mất đi một số khía cạnh của việc trở thành một lập trình viên.

Vì vậy, tôi nghĩ rằng đây là một chủ đề thanh kiếm hai lưỡi chắc chắn. Có máy phát điện rất tốt vì chúng giảm lỗi và tăng tiêu chuẩn mã, tuy nhiên, chúng cũng khiến "một số" lập trình viên bị câm, vì chúng phụ thuộc vào máy phát điện thay vì phải bị bẩn tay.

Chỉ cần 2 xu của tôi.

Ngoài câu trả lời của Martin, tôi sẽ thêm rằng việc tạo mã SQL rất tốt khi bạn làm việc trong cơ sở ghi theo bản ghi (chọn * từ tab1 trong đó tab1.pkcolumn =: tham số, cập nhật tab1 đặt [bất kỳ số cột nào] trong đó tab1.pkcolumn =: tham số, v.v.). Và ORM của bạn sẽ tỏa sáng trong kịch bản đó, vì SQL cần được tạo ra thực sự lặp đi lặp lại.

Lo lắng chính của tôi là metaqueries - truy vấn các thuộc tính của đối tượng mà ORM dịch sang SQL bằng bất kỳ thuật toán nào. Các siêu câu hỏi rất giống nhau có thể tạo ra SQL hoàn toàn khác biệt - và không có gì đảm bảo rằng SQL được tạo này có hiệu suất.

Một ngôn ngữ metaquery dịch sang ngôn ngữ khác (SQL) dịch sang một kế hoạch truy vấn để thực hiện hiệu quả việc thu thập dữ liệu. Và kết quả được tạo phải là các đối tượng, do đó ORM phải khởi tạo các đối tượng bị ảnh hưởng - để nó có thể kích hoạt một cơn mưa truy vấn khác để điền vào các thuộc tính của các đối tượng không do chính meta mang lại ...

Tôi hoàn toàn đồng ý với những người nói rằng việc tạo mã là tốt miễn là bạn không bao giờ phải chỉnh sửa (tốt nhất là không bao giờ phải xem) mã được tạo.

Nếu chúng ta có thể chấp nhận rằng mã được tạo ra có cùng số lượng dòng được viết bằng tay và nếu chúng ta có thể nói rằng nó không có lỗi, thì số dòng có khả năng chứa lỗi đã giảm. Ergo, chất lượng mã phải tăng lên.

Phụ lục: tất nhiên, các yếu tố khác, như thời gian thực hiện, có thể đóng một vai trò.

Cá nhân, tôi đã viết khá nhiều trình tạo mã, nhưng không bao giờ là cách tiếp cận ban đầu.

Luôn luôn là khi tôi nhận thấy một mẫu lặp đi lặp lại trong mã hiện có, vì vậy trình tạo của tôi lấy một số mã hiện có khi thêm mã mới, nhưng tương tự, và tham số hóa một số phần biến của nó.

Ở mức độ đó, mã được tạo của tôi gần giống với mã viết tay hiện tại (ngoại trừ việc nó có xu hướng được trình bày trực quan tốt hơn và thống nhất hơn, mà tôi thấy có thể đọc được, nếu nó phải được xem xét).

Btw, tôi ủng hộ việc chèn các bình luận mở / đóng cho biết mã đã được tạo, bao gồm các chi tiết về công cụ và bộ bảo trì của nó.