Đối phó với đồng nghiệp không có phong cách mã hóa nhất quán?

Bạn làm gì khi bạn làm việc với một người có xu hướng viết mã xấu theo phong cách? Mã tôi đang nói đến thường chính xác về mặt kỹ thuật, cấu trúc hợp lý và thậm chí có thể thanh lịch về mặt thuật toán, nhưng nó trông có vẻ xấu . Chúng tôi đã có:

• Hỗn hợp của quy ước đặt tên khác nhau và các chức danh ( underscore_stylevà camelCasevà UpperCamelvà CAPStất cả các ứng dụng nhiều hơn hoặc ít hơn một cách ngẫu nhiên để biến khác nhau trong cùng chức năng)
• Khoảng cách kỳ lạ và không nhất quán, ví dụ Functioncall (arg1 ,arg2,arg3 );
• Rất nhiều từ sai chính tả trong các bình luận và tên biến

Chúng tôi có một hệ thống đánh giá mã tốt nơi tôi làm việc, vì vậy chúng tôi phải xem qua và sửa những thứ tồi tệ nhất. Tuy nhiên, cảm thấy rất nhỏ khi gửi đánh giá mã bao gồm 50 dòng "Thêm khoảng trắng ở đây. Viết đúng 'itarator'. Thay đổi cách viết hoa này, v.v."

Làm thế nào bạn sẽ khuyến khích người này cẩn thận và phù hợp hơn với các loại chi tiết này?

Đồng ý về quy ước mã hóa

Ngay cả khi đây là một máy nhắn tin. Tôi đề nghị toàn bộ nhóm ngồi xuống và tất cả đồng ý về quy ước mã hóa làm việc cơ bản mà cả nhóm có thể sử dụng.

Tôi nghĩ bạn chỉ cần tiếp tục làm những gì bạn đang làm. Có một bộ hướng dẫn mã hóa rõ ràng và thực thi chúng trong quá trình đánh giá mã. Nếu nhà phát triển nhận được 50 hoặc 100 dòng "Thêm khoảng trắng ở đây" và "Chính tả 'lặp lại' mỗi khi anh ta cố gắng kiểm tra một cái gì đó, và anh ta thực sự không được phép kiểm tra trước khi tất cả những thứ đó được sửa chữa, cuối cùng anh ta Sẽ phải bắt đầu viết mã sạch hơn để tránh rắc rối.

Tôi nghĩ rằng nếu bạn tự sửa những thứ này, như NimChimpsky đề xuất, bạn sẽ dọn dẹp sau người này mãi mãi.

Tôi gọi cho BS về tất cả những người nói rằng lỗi chính tả và định dạng tên biến không thành vấn đề. Rõ ràng, họ chỉ đọc mã của riêng họ. Và chú ý từ đó ngay tại đó - đọc. Hãy tưởng tượng đọc một cuốn sách có nhiều lỗi chính tả, định dạng sai, khoảng cách dòng không nhất quán và nhiều sự lười biếng khác phổ biến trong rất nhiều mã nguồn. Nó sẽ là tẻ nhạt.

Đối với một nghề nghiệp mà cú pháp của bạn phải chính xác 100% để hoạt động, đơn giản là không có lý do gì để bất kỳ nhà phát triển thực sự nào không có một kiểu mã rõ ràng, nhất quán. Bất cứ điều gì khác là sự chậm chạp và lười biếng. Tôi luôn đặt câu hỏi về tính đúng đắn của mã được định dạng trong triển khai.

Chúng tôi có một hệ thống đánh giá mã tốt nơi tôi làm việc, vì vậy chúng tôi phải xem qua và sửa những thứ tồi tệ nhất. Tuy nhiên, cảm thấy rất nhỏ khi gửi đánh giá mã bao gồm 50 dòng "Thêm khoảng trắng ở đây. Viết đúng 'itarator'. Thay đổi cách viết hoa này, v.v."

Tôi sẽ tự thay đổi và sau đó thêm một nhận xét lịch sự vào mã.

điều này giả định rằng đã có một hướng dẫn về phong cách như câu hỏi đã nêu:

Chúng tôi có một hệ thống đánh giá mã tốt

Vì vậy, đề nghị của tôi là giải pháp cuối cùng, tôi cho rằng việc nhanh chóng tự thay đổi nó và để lại nhận xét, vì nó là để gửi e-mail hoặc bất cứ điều gì.

Tôi nghĩ rằng các quy ước như đặt tên các lớp và biến là quan trọng và cũng nên được tuân theo, mã thanh lịch và hiệu quả cũng vậy, nhưng có nguy cơ khiến câu trả lời của tôi bị hạ thấp nhiều lần, tôi phải nói rằng nói chung là mô hình "mã đẹp" được đẩy rất nhiều xung quanh là trong IMHO rất được đánh giá cao.

Trước hết, nhà phát triển đã viết nó sẽ phải duy trì nó ở vị trí đầu tiên, và nếu anh ta bị xe buýt đâm và một lập trình viên khác không thể tìm ra cách nó hoạt động vì mã không "đẹp", tôi nói rằng nhà phát triển khác dù sao cũng không tốt lắm. Và có rất nhiều trình định dạng / làm đẹp tự động ngoài kia, vì vậy bất kỳ ai cũng có thể sử dụng chúng để làm đẹp mã nếu cần thiết, không lãng phí thời gian trong khi "trong dòng chảy" / "trong khu vực".

Xin lưu ý rằng tôi không ủng hộ mã hóa kiểu spaghetti / cao bồi ở đây, trên thực tế tôi đã thấy một số mã spaghetti được định dạng rất độc đáo (các thân hàm trải dài 4-5 màn hình, các biến toàn cục nằm rải rác xung quanh các tệp mã nguồn khác nhau, nói chung là các tên xấu , v.v.)

Một trong những đồng nghiệp của tôi viết html theo cách nó làm cho da tôi bò lên. Hãy tưởng tượng html của tôi đẹp và có cấu trúc với hai vết lõm không gian, bị hack thành từng mảnh bởi các thẻ được thêm vào cuối của tôi, kết thúc trên cùng một dòng hoặc tiếp theo giống như một người say rượu cần quăng tay quanh bạn để đứng. Các dòng mới hiếm khi được thụt vào nhưng nếu có, tôi chắc chắn có một số lỗ đen rất hỗn loạn trong một phần của thiên hà phun ra các giá trị nhiệt độ không hợp lý theo cách mà bằng cách nào đó, các chữ số của nó phản ánh số lượng khoảng trắng hoặc tab được sử dụng trong vết lõm như vậy bởi người phụ nữ này. Nếu tôi may mắn, tôi sẽ thấy một thẻ đầu vào được đóng bằng " </input>". Cơn ác mộng hoàn toàn bạn có thể hiểu.

Dường như không ai hiểu điều này, khi thấy hầu hết những người cao hơn ở đây, mã có tổ chức hoặc mã không có tổ chức đối với họ giống như sự khác biệt giữa chúng ta đặt phô mai Thụy Sĩ hoặc phô mai Mỹ vào bánh sandwich của chúng ta, có nghĩa là họ thực sự có thể quan tâm ít hơn. Tôi bắt đầu để nó trượt vì tôi bị căng thẳng với một dự án khác và tôi nghĩ cô ấy bắt đầu nhận ra việc hiểu mã như thế nào là khó khăn trước khi cô ấy muốn cải thiện. Lời khuyên của tôi sẽ là chứng minh lý do tại sao nên tạo kiểu mã của bạn hơn là chỉ đơn giản là bảo họ làm điều đó.

Mã tôi đang nói đến thường chính xác về mặt kỹ thuật, cấu trúc hợp lý và thậm chí có thể thanh lịch về mặt thuật toán ...

Hãy hạnh phúc vì bạn đã có tất cả những điều đó. Hầu hết các lập trình viên có thể sẽ cung cấp cho bạn điều đầu tiên trong danh sách đó. Tôi nghĩ rằng việc đặt tên và khoảng cách thay đổi là điều ít quan trọng nhất để lo lắng.

Âm thanh như bạn cần phải thiết lập và đồng ý với một quy ước phong cách. Nếu bạn không có thư viện có 3 dấu cách, một số khác có 4, một số sử dụng Camel Case và các thư viện khác sử dụng dấu gạch dưới.

Là những thay đổi bạn muốn thực hiện sở thích cá nhân của bạn hoặc bạn có một tiêu chuẩn thực tế để làm theo? Nếu bạn không có một tiêu chuẩn thực tế, thì đừng làm điều này. Đầu tiên thiết lập một tiêu chuẩn. Sau đó, bạn có thể lấy phần mềm có thể được thiết lập để cấu trúc lại mã thành cài đặt độc lập (ít nhất là một số thứ).

Nếu bạn có một tiêu chuẩn, bắt đầu thực thi nó trong xem xét mã. Không có điểm nào để có một tiêu chuẩn nếu bạn không thực thi nó trong đánh giá mã. Điều này sẽ có nghĩa là rất nhiều công việc bổ sung trong bảo trì vì mọi người sẽ phải sửa mã cũ không đáp ứng tiêu chuẩn gốc khi họ chạm vào nó.

Ngay cả khi không có tiêu chuẩn, vẫn khăng khăng sửa lỗi sai chính tả trong tên biến (tôi sẽ không đặc biệt lo lắng về các bình luận) vì chúng sẽ khiến mọi người chạm vào mã điên mãi mãi.

Các tiêu chuẩn mã hóa cần được xác định để mọi người biết chúng là gì và sau đó chúng cần được thực thi. Cần phải có hậu quả để không tuân theo các quy tắc.

Dưới đây là những điều cần cung cấp một số ưu đãi:

1. Mã đánh giá sẽ tẻ nhạt và lâu hơn cần thiết.
2. Mã sẽ bị từ chối thường xuyên hơn.
3. Lịch trình sẽ không được đáp ứng.

Nếu người này không phải lo lắng về điều này vì không ai thực thi quy tắc của bạn hoặc họ không quan tâm nếu họ không hiệu quả (và không ai làm gì về điều đó), bạn sẽ không thể làm gì nhiều về điều đó.

Tôi muốn đề nghị có một cuộc trò chuyện riêng tư và xem liệu cả hai bạn có thể tìm ra nguyên nhân gốc rễ hay không:

1. Có phải đồng nghiệp đã vội vàng và vì ai đó muốn mã ngày hôm qua, người đó đang cố gắng để có được thứ gì đó hoạt động nhanh nhất có thể? Đây có thể là một cơ hội để thông báo cho người này tập trung vào chất lượng hơn là tốc độ trong công việc của họ. Một câu thần chú như "Hãy dành thời gian của bạn" có thể hữu ích nếu điều này không phản tác dụng.

2. Làm thế nào để người xem công việc của họ? Nếu có một cảm giác tự hào, thì bạn có thể có một góc để sử dụng để có được một để cải thiện. Nếu đó chỉ là một công việc trả các hóa đơn, có thể khó khăn hơn rất nhiều để có được những thay đổi. Họ có biết họ không làm một công việc tuyệt vời nhưng rất gần với nó?

3. Có phải người này không đồng ý với các công ước và đang cố gắng viết mã để phản đối? Nếu vậy, thì bạn có thể có một vấn đề lớn, nhưng điều này đáng để tìm hiểu nếu đây là trường hợp hoặc là người chỉ lười biếng? Những loại động lực nào có thể hữu ích ở đây, ví dụ bạn có thể kháng cáo lòng tham, niềm tự hào, hoặc một số phó khác để khiến người đó tiến bộ. Điều này là lén lút nhưng có thể hiệu quả nếu thử tuyến đường chàng trai tốt đẹp không nơi nào có được.

4. Làm thế nào để chiến thắng bạn bè và ảnh hưởng Mọi người có một vài gợi ý về tính thuyết phục có thể có hiệu quả, chẳng hạn như ca ngợi những cải tiến và mang lại cho người đó một danh tiếng tốt để duy trì.

Về lý do tại sao điều này phải được thực hiện một cách riêng tư, đây là một vài lý do:

1. Có một cơ hội tốt cho sự sỉ nhục, chỉ trích hoặc khó chịu khác tốt hơn là giữ đằng sau một cánh cửa hơn là để ngoài trời nơi ai đó có thể cảm thấy nhân vật của họ bị ám sát.

2. Bạn muốn khuyến khích người khác này mở ra một chút. Một thách thức ở đây là một số người được bảo vệ cẩn thận nên có thể mất nhiều thời gian để khiến họ gỡ bức tường xuống.

3. Nếu có thể, tôi khuyên bạn nên cố gắng làm điều này cách xa văn phòng một chút. Đi ra ngoài ăn trưa, đi dạo hoặc làm gì đó để môi trường xung quanh được thay đổi đủ để người đó có thể cảm thấy thoải mái hơn một chút. Đây có thể là một thách thức và đòi hỏi phải biết người đó, nhưng ý tưởng ở đây là trong văn phòng, một số người sẽ đeo mặt nạ làm việc không có khả năng hữu ích ở đây.

4. Hãy chuẩn bị cho cuộc trò chuyện trở nên khá nóng bỏng hoặc xấu xí, nhưng đây cũng có thể là một dấu hiệu tốt nếu bạn có thể giữ cho người khác tham gia và có một cuộc đối thoại tốt. Một số người thích để mọi thứ ở ngoài trời và những người khác có thể thích những cách tinh tế hơn để hoàn thành công việc. Điều quan trọng là đảm bảo bạn đang lắng nghe người khác đủ để đồng cảm và cố gắng hiểu khía cạnh của họ.

Chúng tôi có một bài kiểm tra JUnit tìm kiếm các vấn đề định dạng. Nó chạy như là một phần của bản dựng. Tôi liên tục nhận được bit bằng cách bỏ qua khoảng trắng giữa if, while hoặc for và dấu ngoặc đơn mở. Mã của chúng tôi luôn được định dạng, mặc dù.

http://code.google.com.vn/p/kawala/wiki/BadCodeSnippetsRunner

Làm đẹp mã như unscrify sẽ có thể giải quyết một số vấn đề của bạn. Nếu bạn đã sẵn sàng trả tiền cho điều này thì có những phần mềm cấp cao nhúng các quy tắc vào chính mã nguồn như Parasoft . Parasoft bắt buộc phải viết mã theo kiểu đồng phục. Bạn có thể nhúng các quy tắc của riêng bạn quá. Khi các công cụ như vậy được sử dụng, các nhà phát triển buộc phải sử dụng kiểu đồng nhất. Và sau một thời gian họ sẽ quen với nó.

Nếu bạn sử dụng Eclipse, thì hãy kích hoạt Lưu hành động cho các Trình soạn thảo Java và bảo mọi người sử dụng nó. Điều này sửa các vấn đề định dạng trên mỗi lần lưu, nhưng không sửa lỗi viết hoa xấu. Nó có thể khá hữu ích mặc dù!

Làm thế nào là khó khăn để làm theo quy ước phong cách? Tôi hiểu các lỗi chính tả nhưng phần còn lại là một chỉ số về suy nghĩ cẩu thả và mã hóa. Nói với người đó rằng họ cần nhất quán hơn khi nói đến mã sản xuất bởi vì họ không phải là người duy nhất sẽ nhìn vào nó. Nó chỉ đơn giản là thô lỗ, ích kỷ và không phù hợp để viết mã sản xuất theo một phong cách không nhất quán.

LOL. Bạn hoàn toàn ghét mã của tôi. Tôi không thể đánh vần để cứu cuộc đời tôi và tôi không quan tâm.

Nhưng tôi biết một số người thực sự quan tâm đến những điều đó.

Tôi khuyên bạn nên sa thải người viết mã xấu xí đó nếu họ không thay đổi, sau đó tìm ai đó làm cho mọi thứ thực sự đẹp và hy vọng họ có thể viết mã đó

thường đúng về mặt kỹ thuật, cấu trúc hợp lý và thậm chí có thể thanh lịch về mặt thuật toán

và nếu họ không thể thì ít nhất bạn có thể hiển thị mã đẹp bị hỏng cho khách hàng và bán chúng trên đó!

Nhưng nghiêm túc. Tập trung vào những điều thực sự quan trọng đầu tiên. Nếu bạn không thể tìm thấy một lý do chính đáng, vững chắc bên ngoài "điều đó làm tổn thương sự nhạy cảm nhạy cảm của tôi" thì hãy bỏ qua ngay bây giờ. Nếu nó thực sự quan trọng thì hãy ngồi xuống với người đó và thuyết phục họ về tầm quan trọng đó. Những thứ như các tiêu chuẩn giúp dễ dàng phân biệt sự khác biệt giữa cấp độ lớp, mức phương thức, các biến được chia sẻ, các biến không đổi làm nên sự khác biệt. Nếu lập trình viên trong câu hỏi quan tâm tất cả về nghề nghiệp của họ, họ sẽ hiểu và cố gắng làm điều đúng đắn.

Giải pháp của tôi khi xử lý các tài nguyên thuê ngoài không cung cấp &% $ # về việc hình thành (hoặc các lỗi dễ dàng ngăn chặn được vấn đề đó) là để máy chủ xây dựng thực thi điều này. Tôi đã tạo một công việc máy chủ CI chạy mỗi đêm để kiểm tra mã, chạy Jalopy và tìm kiếm sau đó kiểm tra lại mã. Một khi nhóm khác biết rằng việc không sử dụng các quy ước mã tiêu chuẩn sẽ khiến công việc của họ khó khăn hơn, họ bắt đầu sử dụng IDE để duy trì một định dạng tiêu chuẩn.