Dự án của tôi đang triển khai từ từ các chú thích Java. Một nửa số nhà phát triển - bao gồm cả bản thân tôi - thấy rằng việc làm bất cứ điều gì phức tạp với chú thích có vẻ như thêm vào gánh nặng bảo trì tổng thể của chúng tôi. Nửa còn lại của nhóm nghĩ rằng họ là đầu gối của ong.Tính duy trì của chú thích Java?
Trải nghiệm thực tế của bạn với các nhóm nhà phát triển có thể duy trì mã được chú thích là gì?
Tôi cảm thấy nó chia thành hai cách sử dụng chú thích - chú thích để cung cấp 'mô tả' của một lớp so với chú thích để cung cấp 'sự phụ thuộc' của lớp.
Tôi thích sử dụng chú thích trên lớp - đó là thứ thuộc về lớp và chú thích giúp tạo phiên bản ngắn gọn - JPA chú thích nằm trong phần này.
Tuy nhiên, tôi không thực sự thích chú thích 'phụ thuộc' - nếu bạn đặt trực tiếp phụ thuộc vào lớp - ngay cả khi nó được xác định trong thời gian chạy từ chú thích thay vì thời gian biên dịch trong lớp - isn ' t mà phá vỡ tiêm phụ thuộc? (Có lẽ trong tinh thần chứ không phải là trong quy tắc ...)
Nó có thể là sở thích cá nhân, nhưng tôi như một tập tin XML lớn có chứa tất cả các thông tin phụ thuộc của ứng dụng của tôi - Tôi xem đây như 'cấu hình ứng dụng' thay vì 'cấu hình lớp'. Tôi muốn tìm kiếm thông qua một vị trí được biết đến hơn là tìm kiếm thông qua tất cả các lớp trong ứng dụng.
Trải nghiệm cá nhân của tôi là, trung bình, việc xử lý chú thích dễ dàng hơn đối với hầu hết các nhà phát triển so với việc xử lý địa chỉ Cấu hình Java XML chuẩn của bạn. Đối với những thứ như thử nghiệm JPA và Spring họ là những người cứu sống tuyệt đối.
Điều tốt về chú thích là chúng tạo cấu hình cho các lớp của bạn tự ghi lại tài liệu. Bây giờ, thay vì phải tìm kiếm qua một tệp XML khổng lồ để thử và tìm hiểu cách một khung công tác đang sử dụng lớp học của bạn, thì lớp của bạn sẽ cho bạn biết.
Thông thường vấn đề với những thay đổi như thế này là việc sử dụng chúng chỉ đơn giản là mất thời gian. Hầu hết mọi người, bao gồm các nhà phát triển, chống lại sự thay đổi. Tôi nhớ khi tôi bắt đầu làm việc với Spring. Trong vài tuần đầu tiên, tôi tự hỏi tại sao bất cứ ai sẽ phải chịu đựng những cơn đau đầu liên quan đến nó. Sau đó, một vài tuần sau, tôi tự hỏi làm thế nào tôi đã từng sống mà không có nó.
Tôi hoàn toàn yêu thích chú thích. Tôi sử dụng chúng từ Hibernate/JPA, Seam, JAXB .... bất cứ thứ gì tôi có thể. IMO không có gì tệ hơn là phải mở một tệp XML chỉ để tìm hiểu xem một lớp được xử lý như thế nào.
Để chú thích bằng mắt của tôi cho phép một lớp tự nói. Ngoài ra chú thích là (hy vọng) một phần của nội dung IDE của bạn hỗ trợ, trong khi với cấu hình XML bạn thường là của riêng bạn.
Tuy nhiên, nó có thể đi xuống cách cấu hình XML và chú thích thực sự được sử dụng bởi bất kỳ thư viện cụ thể nào (như hầu hết phiếu mua hàng) và loại chú thích nào được sử dụng. Tôi có thể tưởng tượng rằng các chú thích xác định một cái gì đó được xây dựng cụ thể (ví dụ: đường dẫn tệp/url) có thể thực sự dễ dàng hơn như cấu hình XML.
Tùy thuộc vào sự hỗ trợ của IDE. Tôi cảm thấy rằng chú thích nên được giữ đồng bộ với mã thông qua kiểm tra trong IDE, nhưng sự hỗ trợ cho điều này là hơi thiếu.
Ví dụ:phiên bản cũ hơn của IDEA sẽ cảnh báo nếu bạn overrode một hàm không có @Override, nhưng sẽ không xóa thẻ @Override nếu bạn đã thay đổi chữ ký phương thức (hoặc chữ ký superclass, cho vấn đề đó) và phá vỡ quan hệ.
Không có hỗ trợ Tôi tìm thấy chúng một cách cồng kềnh để thêm siêu dữ liệu vào mã.
cá nhân tôi cảm thấy rằng trường hợp sử dụng cụ thể mà bạn đã đề cập (tự động tạo biểu mẫu web) là trường hợp sử dụng tuyệt vời cho chú thích. bất kỳ loại kịch bản "khung" nào mà bạn có thể viết mã đơn giản và cho phép khung làm việc nâng nặng (thường lặp lại) dựa trên một vài đề xuất (hay còn gọi là chú thích) là, tôi nghĩ, trường hợp sử dụng lý tưởng cho chú thích.
Tôi tò mò tại sao bạn không như chú thích trong trường hợp này và bạn coi đó là "gánh nặng bảo trì"? (và, tôi không cố gắng xúc phạm vị trí của bạn, chỉ cần hiểu nó).
Không xúc phạm. Chúng tôi đã từng có thẻ tùy chỉnh thực hiện tất cả công việc lặp đi lặp lại/dễ bị lỗi cho chúng tôi trong JSP, vì vậy nó rất nhẹ để bắt đầu. Các nhà phát triển đã quen thuộc với nó. Nó không khó để làm theo, hoặc là từ 10.000 feet hoặc dưới tấm. JSP là * rất * dễ làm theo, vì vậy nếu có một vấn đề, gỡ lỗi là một snap. Hệ thống mới khó thêm vào và/hoặc thay đổi. Chúng tôi cũng có một nhóm các nhà phát triển sẽ gặp khó khăn trong việc học cách sử dụng nó. Khi có sự cố với màn hình, việc gỡ lỗi thông qua việc này bao gồm việc đọc mã mà hầu hết các nhà phát triển không biết –
vì vậy, có vẻ như vấn đề của bạn không có chú thích, nhưng với khung đang tiêu thụ chú thích. nếu có, thì vấn đề sẽ giống nhau cho dù bạn đang sử dụng chú thích, tệp cấu hình hay bất kỳ thứ gì. – james
bạn đang sử dụng chú thích bằng cách nào? Tôi không nghĩ rằng có một câu trả lời ở đây, tôi nghĩ rằng nó thực sự phụ thuộc vào cách bạn đang sử dụng chúng. – james
Câu hỏi hay, vì điều đó có thể khá quan trọng trong trường hợp này. Các nhà phát triển chú thích ủng hộ đã tạo ra một khuôn khổ cho ứng dụng web của chúng tôi. Ứng dụng sử dụng Spring. Các chú thích tự động xây dựng các biểu mẫu web dựa trên các mục trong các đối tượng Command và tránh sử dụng hoàn toàn các JSP. Đã không đề cập đến nó ban đầu bởi vì tôi đã tò mò cho câu trả lời chung; Tôi cũng tò mò về câu trả lời cụ thể. –
Bumping lên một bình luận sau:
Chúng tôi đã từng có thẻ tùy chỉnh làm tất cả các công việc lặp đi lặp lại/lỗi dễ bị cho chúng tôi trong một JSP, do đó, nó rất nhẹ để bắt đầu. Các nhà phát triển đã quen thuộc với nó. Nó không khó để làm theo, hoặc là từ 10.000 feet hoặc dưới tấm, vì vậy khi có một vấn đề, gỡ lỗi là một snap.
Hệ thống mới khó thêm vào và/hoặc thay đổi. Chúng tôi cũng có một nhóm các nhà phát triển sẽ gặp khó khăn trong việc học cách sử dụng nó. Khi có sự cố với màn hình, việc gỡ lỗi thông qua việc này bao gồm việc đọc mã mà hầu hết các nhà phát triển không hề quen thuộc. –