Xung đột các kiểu Java trong một nhóm

Tôi là thành viên của nhóm phát triển Java với thời hạn 6 tuần. Điều này đòi hỏi phải viết một mã tốt rất rất nhanh chóng. Tuy nhiên, nhóm phát triển của chúng tôi có các phong cách mã hóa khác nhau. Tất cả mọi thứ từ quy ước tên đến phương pháp trừu tượng đều khác nhau giữa nhóm chúng tôi. Có ai biết bất kỳ tài liệu nào ra lệnh "tiêu chuẩn" cho java không?

Để làm rõ, tôi đã tự hỏi nếu có một tổ chức sẽ ra lệnh quy ước đặt tên thích hợp cho các biến và hàm chẳng hạn. Điều này là tối quan trọng vì với thời hạn ngắn như vậy, chúng tôi không thể dành thời gian cố gắng để hiểu mã của nhau.

Có một tổ chức như vậy: Sun / Oracle chính nó. Tài liệu này được gọi là Quy ước mã cho ngôn ngữ lập trình Java và nó mô tả hầu hết các quy ước bạn cần. Chỉ cần mọi người đồng ý đọc nó và làm theo khuyến nghị của nó.

Tôi thực sự gắn thẻ vào câu trả lời của Andres và tập trung vào khía cạnh định dạng thống nhất mã java.

Nếu bạn đang sử dụng Eclipse, bạn có thể đặt bộ định dạng Java của nó thành định dạng tự động theo tiêu chuẩn Java. Trình định dạng Eclipse cũng có các cài đặt hữu ích khác, chẳng hạn như các ký tự trên mỗi dòng (nghĩa là có bao nhiêu ký tự trên mỗi dòng trước khi nó bị ngắt thành một dòng mới) và nhiều ký tự khác. Chuẩn hóa các ký tự trên mỗi dòng giúp mã khác biệt được viết bởi các nhà phát triển khác nhau mà không có nhiều khác biệt chỉ từ khoảng cách và ngắt dòng.

Cuối cùng, với Eclipse, sau khi bạn đã thiết lập tất cả các cài đặt bạn muốn, sau đó xuất bộ định dạng của bạn dưới dạng tệp có thể được nhập bởi mọi thành viên trong nhóm. Vì vậy, nếu bạn đang sử dụng Eclipse, tôi khuyên bạn nên khám phá đầy đủ tất cả các tùy chọn mà nó sẽ tự động định dạng và chỉnh sửa mã cho bạn, sau đó chia sẻ các cài đặt với toàn bộ nhóm.

Tôi sẽ giả sử các IDE java chính khác (IntelliJ và Netbeans) có một tính năng tương tự để xuất các cài đặt định dạng.

[Các kiểu mã hóa khác nhau] này là tối quan trọng vì với thời hạn ngắn như vậy, chúng tôi không thể dành thời gian để cố gắng hiểu mã của nhau.

Thực ra. Nó không phải là tối quan trọng.

Sau 30 năm làm tư vấn, tôi đã đọc rất nhiều mã từ rất nhiều khách hàng. Điều quan trọng cần lưu ý là mọi khách hàng (và thường trong tổ chức của khách hàng) có nhiều phong cách khác nhau.

Sau khi đọc rất nhiều phong cách, tôi đã học được điều này.

Phong cách không thành vấn đề

Vui lòng tập trung vào viết mã luôn hoạt động và viết các bài kiểm tra đơn vị chứng minh rằng nó luôn hoạt động.

Sau khi bạn chuyển mã làm việc, bạn có thể chỉnh sửa mã nếu bạn hết lỗi để sửa và cải tiến để cài đặt.

Đừng lo lắng về việc chọn một số tiêu chuẩn phổ quát hoàn hảo. Tất cả những gì bạn cần là nhóm của bạn đồng ý với một tiêu chuẩn và tuân thủ nó. Trang điểm của riêng bạn nếu bạn muốn, nhưng phải nhất quán.

Tính nhất quán cải thiện sự hợp tác, cộng tác cải thiện mã.

Ngay cả khi tính nhất quán thực tế không có ích, thì thực tế là nhóm của bạn đã làm việc cùng nhau để đi đến thỏa thuận là một điều tốt. Họ không có khả năng đồng ý với một cái gì đó đơn giản như các công ước mã hóa nói rằng có thể có những vấn đề làm việc nhóm lớn hơn ẩn giấu dưới bề mặt.

Sun Java CC được đề cập ở trên không chỉ 13 tuổi và một số quy tắc của nó đã lỗi thời (như 80 ký tự trên mỗi dòng), nhưng nó cũng không định nghĩa các quy ước đặt tên, ngoại trừ các quy tắc chung nhất (vỏ lạc đà cho các lớp, khối chữ hoa cho các biến cuối cùng tĩnh và tương tự).

Bạn cần xác định các tiêu chuẩn của riêng mình cho các loại lớp khác nhau , như DAO, EJB, thực thể, bất cứ thứ gì bạn sử dụng. Sun Java CC giống như một lớp cơ sở trừu tượng có nghĩa là để mở rộng :)

Như được đề cập bởi những người khác ở đây, bạn có thể tìm kiếm trực tuyến một trong số ít 'hướng dẫn phong cách' phổ biến cho Java và thuyết phục mọi người trong nhóm gắn bó với họ. Một số công cụ kiểm tra mã trong IDE yêu thích của bạn có thể giúp nhắc nhở bạn khi bạn không làm như vậy.

Tuy nhiên, đôi khi chính trị có liên quan. Tôi đã từng ở trong một tình huống trước khi nhà phát triển cao cấp nhất trong nhóm tiếp tục làm theo cách của mình ngay cả sau khi ai đó đề cập đến nhu cầu tiêu chuẩn hóa. Trong tình huống như vậy, có thể tốt hơn để quan sát phong cách mã của anh ấy và theo dõi anh ấy vì anh ấy có thể có kiến ​​thức nhất về cơ sở mã và các yêu cầu và bạn có thể không muốn lãng phí thời gian dẫm lên ngón chân của mình mặc dù anh ấy đang gặp khó khăn. Đó là những gì phần còn lại của chúng tôi đã làm trong tình huống cụ thể đó và tôi miễn cưỡng làm theo.

Vì vậy, điều quan trọng là phải xem xét tình hình của bạn là tốt.

Chú Bob cho thấy một phong cách mã hóa hiện đại và hiện đại hơn trong cuốn sách "Clean Code". Thật không may, nó không chứa danh sách các mặt hàng. Bạn phải đọc nó. Anh ta tự nói rằng để xem các quy ước của mình, bạn phải đọc mã của anh ta. Bác Bob chắc chắn là một loại tổ chức. Cuốn sách dù sao cũng là một cuốn sách tuyệt vời, vì vậy ngay cả khi quá muộn để đọc nó, hãy đọc nó càng sớm càng tốt.

Điều thực sự quan trọng trong mã là độ phức tạp chu kỳ thấp, phạm vi nhỏ, độ gắn kết cao và sự lựa chọn các định danh biểu cảm. Với những điều đó, mã trở nên dễ nắm bắt và mã như vậy là tốt.

Tôi đề nghị bạn xem xét lập trình Spartan .

Hầu hết các tiêu chuẩn mã hóa cho bạn biết làm thế nào để làm cho mã viết kém trông đẹp mắt và hầu hết các cuộc thảo luận về "phong cách mã hóa" thực sự là về định dạng. Định dạng mã là về trực quan đại diện cho cấu trúc mã của bạn. Nó là tầm thường và tự động hóa và hầu như không làm gì với phong cách mã hóa, bởi vì phong cách mã hóa không phải là về cách bạn biểu diễn cấu trúc mã, mà là về cách bạn cấu trúc mã.
Ngoài ra còn có rất nhiều cuộc chiến tôn giáo về các quy ước đặt tên, mặc dù thực sự chúng chỉ là một bản hack để khắc phục thiết kế kém. Một cái tên là tốt, nếu nó nói những gì nó có nghĩa. Phạm vi của bạn càng nhỏ và rõ ràng, càng dễ dàng để chọn một tên như vậy.