Làm thế nào tôi có thể thúc đẩy mã hóa sạch tại nơi làm việc của tôi?

Tôi làm việc với rất nhiều mã Java và RPG kế thừa trên một ứng dụng nội bộ của công ty. Như bạn có thể mong đợi, rất nhiều mã được viết theo nhiều kiểu khác nhau và thường rất khó đọc vì các biến được đặt tên kém, định dạng không nhất quán và các nhận xét trái ngược nhau (nếu chúng hoàn toàn không có).

Ngoài ra, một lượng mã tốt không mạnh. Nhiều lần mã được đẩy đến sản xuất nhanh chóng bởi các lập trình viên có kinh nghiệm hơn, trong khi mã bởi các lập trình viên mới hơn bị giữ lại bởi "đánh giá mã" mà IMO không đạt yêu cầu. (Chúng thường có dạng "Nó hoạt động, phải ổn", hơn là một sự phê phán nghiêm túc về mã.) Chúng tôi có một số vấn đề sản xuất hợp lý, mà tôi cảm thấy có thể giảm bớt bằng cách suy nghĩ nhiều hơn về thiết kế ban đầu và thử nghiệm.

Tôi đã làm việc cho công ty này được khoảng 4 tháng và đã được khen về phong cách mã hóa của tôi một vài lần. Người quản lý của tôi cũng là một fan hâm mộ của mã hóa sạch hơn là tiêu chuẩn. Đây có phải là nơi để tôi cố gắng thúc đẩy phong cách tốt hơn và mã hóa phòng thủ tốt hơn không, hay tôi nên đơn giản viết mã theo cách tốt nhất có thể, và hy vọng rằng ví dụ của tôi sẽ giúp người khác thấy mã sạch hơn, mạnh mẽ hơn (cũng như tái cấu trúc mạnh mẽ) Sẽ dẫn đến ít gỡ lỗi và thay đổi thời gian?

Bạn đã không đề cập đến trình độ chuyên môn của bạn về chủ đề này. Nếu bạn không phải là một lập trình viên cao cấp, tôi nghĩ điều tốt nhất bạn có thể làm là làm tốt công việc của mình. Bạn cũng đã đề cập rằng người quản lý của bạn thích công việc sạch sẽ - điều đó thật tuyệt. Nếu bạn có thể nói chuyện với anh ấy về điều đó (có thể trong môi trường bán chuyên nghiệp), bạn nên chia sẻ mối quan tâm của mình về vấn đề này với anh ấy. HE đang ở vị trí để thay đổi quy trình làm việc.

Mã sạch có ý nghĩa gì với bạn?

Tôi chắc rằng định nghĩa của bạn là tuyệt vời, nhưng những người khác ở nơi làm việc của bạn có thể có định nghĩa riêng của họ. Họ không sai, chỉ khác bạn.

Bạn nên tạo các hướng dẫn mã hóa mà mọi người trong nơi làm việc của bạn có thể đồng ý và bạn nên làm điều đó cùng với các lập trình viên đồng nghiệp của mình. Đừng cố ép người này, nó sẽ phản tác dụng nếu bạn làm thế.

Vì vậy, tập hợp nhóm và bắt đầu làm việc với một định nghĩa chung về "mã sạch"! Không có quy tắc cứng cho việc này. Bạn đang cố gắng mang nhiều ý nghĩ lại với nhau và điều đó có thể dẫn đến xung đột, vì vậy bạn có thể muốn thiết lập giai đoạn với một lưu ý tích cực rằng tất cả các bạn nên tôn trọng và giữ một tâm trí cởi mở (viết mã là cá nhân ...).

Các Mã sạch cuốn sách có thể có ích. Bạn có thể sử dụng các ví dụ từ cuốn sách đó để nói về và xem nếu bạn tìm thấy một số điểm chung trong đó?

Có hai điều có thể làm nên điều kỳ diệu để đảm bảo tính nhất quán và thanh cao cho chất lượng mã.

Nhận xét mã

Bạn nên cố gắng cho mọi đăng ký - bất kể tầm thường như thế nào - được xem xét bởi một người khác trong nhóm. Không có ngoại lệ. Điều này có vẻ như sẽ gây cản trở lúc đầu, đặc biệt là đối với các nhà phát triển cấp cao, những người nghĩ rằng họ không có gì để đạt được bằng cách có ít người có kinh nghiệm xem lại mã của họ. Tuy nhiên, việc đánh giá mã thường xuyên sẽ có tác động to lớn đối với mọi nhà phát triển trong nhóm.

Xác định một tiêu chuẩn và gắn bó với nó

Tại Google, chúng tôi có một hướng dẫn về phong cách mã hóa cho mọi ngôn ngữ chúng tôi sử dụng: C ++ , Java , Python , v.v. Mặc dù các kỹ sư có thể không đồng ý với hướng dẫn về phong cách, nhưng nó không phải là tùy chọn. (Và được thi hành nghiêm ngặt trong các đánh giá mã.) Kết quả là, toàn bộ cơ sở mã - hàng trăm ngàn dòng mã - rất phù hợp.

Tôi nghĩ rằng nếu bạn đam mê mã sạch thì điều này sẽ xóa sạch đồng nghiệp của bạn. Tâm lý "Nó hoạt động, phải ổn" có thể được thay đổi bởi những người ủng hộ thiết kế tốt và mã sạch một cách nhiệt tình.

Mặc dù một số câu trả lời hữu ích đã được đăng ở đây một lúc, tôi tin rằng có nhiều chỗ hơn. Đề nghị của tôi là, như những người khác đã nói, để làm đánh giá mã. Nhưng điều đáng nói lại là vì thuật ngữ "đánh giá mã" rất mơ hồ ... gần như mơ hồ như "mã sạch" :-). Tôi đã dành rất nhiều thời gian và nỗ lực bản thân để làm việc hướng tới mục tiêu khó nắm bắt đó. Và đặc biệt trong vài năm qua, được thúc đẩy bởi những đồng nghiệp có chung niềm đam mê, tôi đã chắt lọc những quan niệm của mình, pha trộn với những ý tưởng chính từ các nhà phát triển nổi bật, thành một loạt mang tên Zen of Code Reviews .

Các bài viết của tôi là duy nhất, theo như tôi biết, trong đó tôi đề cập đến cả hai mặt của lối đi: thực hiện đánh giá mã với tư cách là tác giả và thực hiện đánh giá mã với tư cách là người đánh giá . Mặc dù có liên quan, các kỹ năng cho mỗi người có phần khác nhau. Và có thể làm tốt cả hai sẽ dẫn đến chất lượng mã tốt hơn. Xem lại mã cũng quan trọng như viết mã. Có thật không. Nó thúc đẩy chuyển giao kiến ​​thức, nó khuyến khích sự nhất quán và giao tiếp của nhóm, nó giúp bạn cải thiện nghề của mình và cuối cùng nhưng không kém phần quan trọng, nó giúp giảm phần mềm lỗi rất hiệu quả - từ càng gần khi bắt đầu càng tốt.

Hai phần đầu cung cấp các mẹo và kỹ thuật để chuẩn bị đánh giá mã. Tóm lại:

• Bạn là tác giả có kiến ​​thức sâu sắc về lý do tại sao mỗi dòng thay đổi nằm trong phần đánh giá mã của bạn. Nhiều người là hiển nhiên đối với một nhà phê bình có giáo dục, nhưng nhiều người thì không. Truyền đạt những điểm đó bằng cách chú thích đánh giá mã của bạn trước khi bạn gửi nó cho người đánh giá.
• Ngay cả trước đó, hãy xem xét cẩn thận những gì bao gồm đánh giá mã của bạn: đảm bảo bạn bao gồm tất cả các thay đổi có liên quan cho một vấn đề và cố gắng không bao gồm nhiều hơn một vấn đề.
• Hãy chắc chắn rằng bạn thực hiện kiểm tra kiểm soát nguồn (để đồng bộ lại mã của bạn với chính) trước khi bạn gửi nó.
• Xem lại mã của riêng bạn trước khi bạn gửi nó - từng dòng một!

Phần 1: Nhận xét trước khi đánh giá: Trao quyền cho đồng nghiệp của bạn để cung cấp cho bạn phản hồi tốt hơn về đánh giá mã của bạn

Phần 2: Thực tiễn tốt nhất: Hướng dẫn chuẩn bị đánh giá mã

Và hai bài viết khác cung cấp lời khuyên thiết thực về cách trở thành người đánh giá tốt hơn:

• Đọc Jira / vấn đề / vé / yêu cầu (bất cứ điều gì bạn gọi nó) đầu tiên.
• Đảm bảo các bài kiểm tra đơn vị bao gồm các yêu cầu.
• Xem lại các bài kiểm tra đơn vị cho lớp tương đương và tính đầy đủ của giá trị biên.
• Đảm bảo mỗi bài kiểm tra đơn vị làm vừa đủ, không kiểm tra nhiều thứ.
• Xem lại mã để tuân thủ các nguyên tắc RẮN.
• Xem ra cho bánh xe phát minh lại, mã quá phức tạp và mã phức tạp.
• Ma thuật Eschew (chuỗi ma thuật, ints ma thuật, và, vâng, thậm chí cả booleans ma thuật).
• Bắt hiệu ứng cánh bướm - có những gợn sóng bị bỏ lỡ (ví dụ như đặt tên không nhất quán).

Phần 3: Câu chuyện của Người phản biện: Hướng dẫn thực hiện đánh giá mã

Phần 4: Xem lại như thể bạn sở hữu mã

Dẫn bằng ví dụ. Có mã của bạn được xem xét.

Theo kinh nghiệm của tôi, hầu hết các ứng dụng "RPG + Java" được viết bởi các lập trình viên đến từ phía RPG chứ không phải từ phía Java và suy nghĩ của hai thế giới rất khác nhau mà tôi tin là một trong những lý do khiến bạn có thiết kế cơ bản các vấn đề.

Công cụ chính thức của IBM dựa trên Eclipse, vì vậy nếu bạn sử dụng công cụ đó, bạn có thể sử dụng hầu hết các mẹo và thủ thuật có sẵn cho Eclipse và bạn cần tìm ra những thứ mang lại nhiều lợi ích cho công sức, vì về cơ bản bạn cần thể hiện những điều này folks rằng nó là giá trị làm tất cả.

Một trong những điều hiệu quả nhất mà tôi đã tìm thấy cho việc này là Lưu hành động của trình soạn thảo Java, nơi bạn có thể yêu cầu nó định dạng lại nguồn của mình mỗi khi bạn lưu tệp. Điều này sẽ trong một thời gian ngắn dẫn đến bố cục mã hóa đồng đều hơn làm cho mọi thứ dễ đọc hơn. Tôi đã viết lên những phát hiện của tôi ở đây.

Nếu trước tiên bạn có ý niệm rằng bạn có thể có những gợi ý hữu ích, mọi người sẽ lắng nghe nhiều hơn ...

"Mọi người đều viết mã xấu". Tiêu hóa nó và sau đó thừa nhận nó. Điều này đặt toàn bộ nhóm trong một mặt phẳng phá vỡ thứ bậc và thấm nhuần vào mọi người rằng tất cả đều bằng nhau. Điều rất quan trọng đối với một lập trình viên cao cấp để thể hiện những hành vi và thái độ này. Với những điều này là tiền đề, hãy thực hành lập trình cặp trong đó bạn nên thảo luận, tranh luận (đóng hộp thời gian) và hội tụ để đưa ra quyết định về những gì đúng sau khi nói tại sao điều gì đó có thể sai. Trong khi lập trình cặp, một người vượt trội hơn người khác - cả hai đều là những lập trình viên khiêm tốn và cởi mở. Cách nào tốt hơn để thúc đẩy thực hành mã hóa tốt! :)

Một cách tôi chưa từng thấy được đề cập trong bất kỳ câu trả lời nào cho đến nay là giáo dục. Yêu cầu công ty của bạn tài trợ cho những người muốn đến JavaZone hoặc RubyConf gần nhất hoặc bất kỳ hội nghị nào phù hợp và thuận tiện cho bạn. Tìm các khóa học có liên quan và gửi các nhà phát triển được chọn tham dự. Nếu công ty của bạn đủ lớn, thậm chí có thể khả thi để sắp xếp các hội thảo và khóa học nội bộ về các chủ đề như thực tiễn tốt nhất, các lớp học chính cho ngôn ngữ của bạn, v.v. Tìm một giảng viên giỏi về chủ đề này và chuẩn bị một khóa học phù hợp với tình huống của công ty bạn.

Công ty của tôi đang làm điều này khá nhiều, và trong khi vẫn còn những người ngoan cố không chịu quan tâm, thì nhận thức chung về các vấn đề như thế này đang tăng lên - và tình trạng chung của cơ sở mã của chúng tôi đang được cải thiện. Ngay cả khóa học "Basic C" mà chúng tôi đã thực hiện trong nhiều vòng đã được chứng minh là đã khai sáng cho các nhà phát triển, những người đã viết C trong khoảng 10-15 năm. Không phải vì họ là những lập trình viên tồi, mà bởi vì bạn có xu hướng rơi vào thói quen và quên đi lý do tại sao, và ngôn ngữ và kinh nghiệm tập thể về cách sử dụng nó cũng đang dần thay đổi.