Làm thế nào để bạn nói với ai đó họ đang viết mã xấu? [đóng cửa]

Tôi đã làm việc với một nhóm nhỏ những người trong một dự án mã hóa để giải trí. Đó là một nhóm có tổ chức và khá gắn kết. Những người tôi làm việc cùng có tất cả các bộ kỹ năng khác nhau liên quan đến lập trình, nhưng một số người trong số họ sử dụng các phương pháp sai cũ hoặc hoàn toàn sai, chẳng hạn như biến toàn cục quá mức, quy ước đặt tên kém và những thứ khác. Trong khi mọi thứ hoạt động, việc thực hiện là kém. Cách tốt để hỏi một cách lịch sự hoặc giới thiệu cho họ sử dụng phương pháp tốt hơn, mà không gặp phải vấn đề (hoặc xúc phạm) kinh nghiệm và / hoặc giáo dục của họ là gì?

Đưa ra các câu hỏi để khiến họ nhận ra rằng những gì họ đang làm là sai. Ví dụ, hỏi những loại câu hỏi sau:

Tại sao bạn quyết định biến nó thành một biến toàn cầu?

Tại sao bạn lại đặt cho nó cái tên đó?

Nó thật thú vị. Tôi thường làm theo cách này vì [Chèn lý do tại sao bạn tốt hơn]

Cách đó có hiệu quả không? Tôi thường [Chèn cách bạn sẽ làm cho chúng trông ngớ ngẩn]

Tôi nghĩ rằng cách lý tưởng để thực hiện điều này là khéo léo hỏi họ tại sao họ viết mã theo một cách nhất định. Bạn có thể thấy rằng họ tin rằng có những lợi ích cho các phương pháp khác. Trừ khi tôi biết lý do cho phong cách mã hóa của họ là do thông tin sai lệch, tôi sẽ không bao giờ đánh giá theo cách của tôi là tốt hơn nếu không có lý do chính đáng. Cách tốt nhất để làm điều này là chỉ hỏi họ tại sao họ chọn cách đó; hãy chắc chắn có vẻ quan tâm đến lý luận của họ, bởi vì đó là những gì bạn cần để tấn công, không phải khả năng của họ.

Một tiêu chuẩn mã hóa chắc chắn sẽ có ích, nhưng nếu đó là câu trả lời cho mọi dự án phần mềm thì tất cả chúng ta sẽ nhấm nháp ly cocktail trên các hòn đảo tư nhân của chúng ta trên thiên đường. Trong thực tế, tất cả chúng ta dễ gặp vấn đề và các dự án phần mềm vẫn có tỷ lệ thành công thấp. Tôi nghĩ rằng vấn đề chủ yếu xuất phát từ khả năng của từng cá nhân chứ không phải là vấn đề với quy ước, đó là lý do tại sao tôi khuyên bạn nên giải quyết các vấn đề như một nhóm khi một vấn đề làm hỏng cái đầu xấu xí của nó.

Quan trọng nhất, KHÔNG ngay lập tức cho rằng cách của bạn là tốt hơn . Trong thực tế, có lẽ là như vậy, nhưng chúng ta đang đối phó với ý kiến ​​của người khác và đối với họ chỉ có một giải pháp. Đừng bao giờ nói rằng cách của bạn là cách tốt hơn để làm điều đó trừ khi bạn muốn họ xem bạn là kẻ thua cuộc tự mãn.

Bắt đầu thực hiện đánh giá mã hoặc lập trình cặp.

Nếu nhóm sẽ không dành cho những người đó, hãy thử đánh giá thiết kế hàng tuần. Mỗi tuần, gặp nhau trong một giờ và nói về một mẩu mã. Nếu mọi người có vẻ phòng thủ, hãy chọn mã cũ mà không ai có cảm xúc gắn bó nữa, ít nhất là vào lúc bắt đầu.

Như @JesperE: đã nói, tập trung vào mã chứ không phải mã hóa.

Khi bạn thấy một cái gì đó bạn nghĩ nên khác biệt, nhưng những người khác không thấy nó theo cùng một cách, sau đó bắt đầu bằng cách đặt câu hỏi dẫn đến sự thiếu sót, thay vì chỉ ra chúng. Ví dụ:

Globals : Bạn có nghĩ rằng chúng ta sẽ muốn có nhiều hơn một trong số này không? Bạn có nghĩ rằng chúng tôi sẽ muốn kiểm soát truy cập này?

Trạng thái có thể thay đổi : Bạn có nghĩ rằng chúng ta sẽ muốn thao tác điều này từ một luồng khác không?

Tôi cũng thấy hữu ích khi tập trung vào những hạn chế của mình , điều này có thể giúp mọi người thư giãn. Ví dụ:

chức năng dài : Bộ não của tôi không đủ lớn để chứa tất cả những thứ này cùng một lúc. Làm thế nào chúng ta có thể tạo ra những mảnh nhỏ hơn mà tôi có thể xử lý?

tên xấu : Tôi bị nhầm lẫn đủ dễ dàng khi đọc mã rõ ràng; khi tên sai lệch, không có hy vọng cho tôi.

Cuối cùng, mục tiêu không phải là để bạn dạy cho nhóm của mình cách viết mã tốt hơn. Đó là thiết lập văn hóa học tập trong nhóm của bạn. Nơi mỗi người tìm đến những người khác để được giúp đỡ trong việc trở thành một lập trình viên tốt hơn.

Giới thiệu ý tưởng về một tiêu chuẩn mã. Điều quan trọng nhất về tiêu chuẩn mã là nó đề xuất ý tưởng về tính nhất quán trong cơ sở mã ( lý tưởng là tất cả các mã sẽ trông giống như được viết bởi một người trong một lần ngồi) sẽ dẫn đến mã dễ hiểu và dễ bảo trì hơn.

Bạn phải giải thích tại sao cách của bạn tốt hơn .

Giải thích tại sao một chức năng tốt hơn cắt và dán.

Giải thích tại sao một mảng tốt hơn $ foo1, $ foo2, $ foo3.

Giải thích tại sao các biến toàn cầu là nguy hiểm và các biến cục bộ sẽ giúp cuộc sống dễ dàng hơn.

Đơn giản chỉ cần đưa ra một tiêu chuẩn mã hóa và nói "làm điều này" là vô ích vì nó không giải thích cho lập trình viên tại sao đó là một điều tốt.

Đầu tiên, tôi sẽ cẩn thận đừng phán xét quá nhanh. Thật dễ dàng để loại bỏ một số mã là xấu, khi có thể có lý do chính đáng tại sao nó lại như vậy (ví dụ: làm việc với mã kế thừa với các quy ước kỳ lạ). Nhưng hãy giả sử rằng họ thực sự tồi tệ.

Bạn có thể đề nghị thiết lập một tiêu chuẩn mã hóa, dựa trên đầu vào của nhóm. Nhưng bạn thực sự cần phải xem xét ý kiến ​​của họ sau đó, không chỉ áp đặt tầm nhìn của bạn về những gì mã tốt nên được.

Một lựa chọn khác là mang sách kỹ thuật vào văn phòng (Code Complete, C ++ hiệu quả, Lập trình viên thực dụng ...) và đề nghị cho người khác mượn nó ("Này, tôi đã hoàn thành việc này, có ai muốn mượn nó không?" )

Nếu có thể, hãy đảm bảo họ hiểu rằng bạn đang phê phán mã của họ chứ không phải cá nhân họ.

Đề xuất một sự thay thế tốt hơn theo cách không đối đầu.

"Này, tôi nghĩ cách này cũng sẽ hiệu quả. Các bạn nghĩ sao?" [Cử chỉ rõ ràng là mã tốt hơn trên màn hình của bạn]

Có mã đánh giá và bắt đầu bằng cách xem lại mã CỦA BẠN .

Nó sẽ giúp mọi người thoải mái với toàn bộ quy trình xem xét mã bởi vì bạn đang bắt đầu quá trình bằng cách xem lại mã của riêng bạn thay vì mã của họ. Bắt đầu với mã của bạn cũng sẽ cung cấp cho họ những ví dụ hay về cách thực hiện.

Họ có thể nghĩ rằng phong cách của bạn bốc mùi quá. Làm cho nhóm cùng nhau thảo luận về một bộ hướng dẫn phong cách mã hóa nhất quán. Đồng ý với một cái gì đó. Cho dù điều đó phù hợp với phong cách của bạn không phải là vấn đề, giải quyết bất kỳ phong cách nào miễn là nó phù hợp là điều quan trọng.

Ví dụ như. Chỉ cho họ cách đúng.

Chậm lại đi. Đừng ném chúng cho mọi sai lầm nhỏ ngay lập tức, hãy bắt đầu với những thứ thực sự quan trọng.

Ý tưởng tiêu chuẩn mã là một trong những tốt.

Nhưng xem xét không nói bất cứ điều gì, đặc biệt là vì nó là cho vui, với, có lẽ, những người bạn là bạn bè. Đó chỉ là mã ...

Có một số lời khuyên thực sự tốt trong cuốn sách "Tâm lý học lập trình máy tính" của Gerry Weinberg - toàn bộ khái niệm của ông về "lập trình vô ngã" là tất cả về cách giúp mọi người chấp nhận chỉ trích mã của họ như khác biệt với chỉ trích chính họ.

Thực hành đặt tên xấu: Luôn không thể tha thứ.

Và vâng, đừng luôn cho rằng cách của bạn tốt hơn ... Nó có thể khó khăn, nhưng tính khách quan phải được duy trì.

Tôi đã có một kinh nghiệm với một lập trình viên có chức năng đặt tên khủng khiếp như vậy, mã còn tệ hơn không thể đọc được. Các chức năng nói dối về những gì họ đã làm, mã là vô nghĩa. Và họ đã được bảo vệ / chống lại việc có người khác thay đổi mã của họ. khi đối mặt rất lịch sự, họ thừa nhận nó được đặt tên kém, nhưng muốn giữ quyền sở hữu mã và sẽ quay lại và sửa nó "vào một ngày sau đó." Điều này là trong quá khứ bây giờ, nhưng làm thế nào để bạn đối phó với một tình huống mà lỗi của họ bị CHẤP NHẬN, nhưng sau đó được bảo vệ? Điều này diễn ra trong một thời gian dài và tôi không biết làm thế nào để vượt qua rào cản đó.

Biến toàn cục: Bản thân tôi không thích RẤT NHIỀU biến toàn cục, nhưng tôi biết một vài lập trình viên xuất sắc khác thích họ RẤT NHIỀU. Đến nỗi tôi đã tin rằng chúng không thực sự tệ đến thế trong nhiều tình huống, vì chúng cho phép sự rõ ràng, dễ gỡ lỗi. (xin đừng châm lửa / hạ bệ tôi :)) Tôi đã thấy rất nhiều mã không có lỗi, rất hiệu quả, sử dụng các biến toàn cầu (không phải do tôi đưa vào!) và rất nhiều lỗi, không thể đọc / duy trì / sửa mã mà sử dụng các mẫu thích hợp một cách tỉ mỉ. Có thể có LÀ một địa điểm (mặc dù bị thu hẹp có lẽ) cho các biến toàn cầu? Tôi đang xem xét xem xét lại vị trí của mình dựa trên bằng chứng.

Bắt đầu một wiki trên mạng của bạn bằng một số phần mềm wiki.

Bắt đầu một danh mục trên trang web của bạn được gọi là "thực tiễn tốt nhất" hoặc "tiêu chuẩn mã hóa" hoặc một cái gì đó.

Chỉ mọi người cho nó. Cho phép phản hồi.

Khi bạn phát hành phần mềm, hãy nhờ người có nhiệm vụ đưa mã vào bản dựng đẩy lùi các nhà phát triển, trỏ chúng vào các trang Wiki trên đó.

Tôi đã thực hiện điều này trong tổ chức của mình và phải mất vài tháng để mọi người thực sự say mê sử dụng Wiki nhưng bây giờ đây là tài nguyên không thể thiếu.

Nếu bạn thậm chí có một tiêu chuẩn mã hóa lỏng lẻo, có thể chỉ ra điều đó hoặc chỉ ra rằng bạn không thể tuân theo mã bởi vì đó không phải là định dạng chính xác có thể đáng giá.

Nếu bạn không có định dạng mã hóa, bây giờ sẽ là thời điểm tốt để đặt một vị trí. Một cái gì đó giống như câu trả lời cho câu hỏi này có thể hữu ích: /programming/4121/team-coding-ststyle

Tôi luôn đi theo dòng 'Đây là những gì tôi sẽ làm'. Tôi không thử và giảng cho họ và nói với họ rằng mã của họ là rác rưởi, nhưng chỉ đưa ra một quan điểm khác có thể hy vọng cho họ thấy một cái gì đó rõ ràng là gọn gàng hơn một chút.

Yêu cầu (các) người trong câu hỏi chuẩn bị một bài thuyết trình cho phần còn lại của nhóm về mã cho một mô-đun đại diện mà họ đã viết và để Q & A chăm sóc nó (hãy tin tôi, nó sẽ, và nếu đó là một nhóm tốt, nó thậm chí không nên trở nên xấu xí).

Tôi yêu thích mã, và chưa bao giờ có bất kỳ khóa học nào trong cuộc sống của tôi về bất cứ điều gì liên quan đến tin học, tôi bắt đầu rất tệ và bắt đầu học hỏi từ các ví dụ, nhưng điều tôi luôn nhớ và giữ trong đầu kể từ khi tôi đọc cuốn sách "Gang Of Four" là :

"Mọi người đều có thể viết mã được hiểu bởi một cỗ máy, nhưng không phải tất cả đều có thể viết mã được hiểu bởi một con người"

với ý nghĩ này, có rất nhiều việc phải làm trong mã;)

Tôi không thể nhấn mạnh đủ kiên nhẫn. Tôi đã thấy loại chính xác này hoàn toàn phản tác dụng chủ yếu là vì ai đó muốn những thay đổi xảy ra NGAY BÂY GIỜ. Khá nhiều môi trường cần những lợi ích của sự tiến hóa, chứ không phải cách mạng. Và bằng cách buộc thay đổi ngày hôm nay, nó có thể tạo ra một môi trường rất không vui cho tất cả.

Mua vào là chìa khóa. Và cách tiếp cận của bạn cần phải tính đến môi trường bạn đang ở.

Có vẻ như bạn đang ở trong một môi trường có nhiều "tính cá nhân" đối với nó. Vì vậy, ... tôi sẽ không đề xuất một bộ tiêu chuẩn mã hóa. Bạn sẽ thấy rằng bạn muốn thực hiện dự án "vui vẻ" này và biến nó thành một dự án làm việc có cấu trúc cao (ồ tuyệt vời, ... tài liệu chức năng tiếp theo là gì?). Thay vào đó, như một người khác nói, bạn sẽ phải đối phó với nó ở một mức độ nhất định.

Hãy kiên nhẫn và hướng tới việc giáo dục người khác theo hướng của bạn. Bắt đầu với các cạnh (các điểm mà mã của bạn tương tác với người khác) và khi tương tác với mã của họ, hãy thử lấy đó làm cơ hội để thảo luận về giao diện mà họ đã tạo và hỏi họ xem có ổn không nếu họ thay đổi (bởi bạn hoặc họ). Và giải thích đầy đủ lý do tại sao bạn muốn thay đổi ("nó sẽ giúp đối phó với việc thay đổi các thuộc tính hệ thống con tốt hơn" hoặc bất cứ điều gì). Đừng chọn nit và cố gắng thay đổi mọi thứ bạn thấy là sai. Khi bạn tương tác với những người khác, họ sẽ bắt đầu xem nó sẽ mang lại lợi ích như thế nào cho cốt lõi của mã của họ (và nếu bạn có đủ động lực, hãy đi sâu hơn và thực sự bắt đầu thảo luận về các kỹ thuật hiện đại và lợi ích của các tiêu chuẩn mã hóa). Nếu họ vẫn không thấy ... có lẽ bạn '

Kiên nhẫn. Tiến hóa, không phải cách mạng.

Chúc may mắn.

Tôi tặng một toga và mở một lon phương pháp xã hội.

Các Phương pháp Socrate đặt tên sau khi cổ điển Hy Lạp nhà triết học Socrates, là một hình thức điều tra triết học trong đó người hỏi tìm hiểu ý nghĩa của các vị trí của người khác, để kích thích suy nghĩ hợp lý và ý tưởng sáng. Phương pháp biện chứng này thường liên quan đến một cuộc thảo luận đối lập trong đó sự bảo vệ một quan điểm được đọ sức với một quan điểm khác; một người tham gia có thể khiến người khác mâu thuẫn với chính mình theo một cách nào đó, củng cố quan điểm của người hỏi.

Rất nhiều câu trả lời ở đây liên quan đến định dạng mã mà ngày nay không đặc biệt liên quan, vì hầu hết các IDE sẽ định dạng lại mã của bạn theo kiểu bạn chọn. Điều thực sự quan trọng là làm thế nào mã hoạt động, và người đăng có quyền xem xét các biến toàn cục, sao chép và dán mã, và peeve thú cưng của tôi, quy ước đặt tên. Có một thứ như mã xấu và nó ít liên quan đến định dạng.

Phần tốt là hầu hết nó xấu vì một lý do rất tốt, và những lý do này thường có thể định lượng và giải thích được. Vì vậy, theo cách không đối đầu, giải thích lý do. Trong nhiều trường hợp, bạn thậm chí có thể đưa ra các kịch bản cho người viết trong đó các vấn đề trở nên rõ ràng.

Tôi không phải là nhà phát triển chính trong dự án của mình và do đó không thể áp đặt các tiêu chuẩn mã hóa nhưng tôi đã thấy rằng mã xấu thường gây ra vấn đề sớm hơn là sau này và khi đó tôi có ý tưởng hoặc giải pháp sạch hơn.

Bằng cách không xen vào thời điểm đó và thực hiện một cách tiếp cận tự nhiên hơn, tôi đã có được sự tin tưởng hơn với người dẫn đầu và anh ấy thường quay sang tôi để lấy ý tưởng và đưa tôi vào chiến lược thiết kế và triển khai kiến ​​trúc được sử dụng cho dự án.

Những người viết mã xấu chỉ là một triệu chứng của sự thiếu hiểu biết (khác với việc bị câm). Đây là một số mẹo để đối phó với những người đó.

• Kinh nghiệm riêng của mọi người để lại ấn tượng mạnh mẽ hơn những gì bạn sẽ nói.
• Một số người không đam mê mã họ sản xuất và sẽ không nghe bất cứ điều gì bạn nói
• Lập trình theo cặp có thể giúp chia sẻ ý tưởng nhưng chuyển đổi người lái xe hoặc họ sẽ kiểm tra email trên điện thoại của họ
• Đừng dìm họ quá nhiều, tôi đã tìm thấy ngay cả Tích hợp liên tục cần được giải thích một vài lần cho một số nhà phát triển cũ
• Làm cho họ vui mừng một lần nữa và họ sẽ muốn học hỏi. Nó có thể là một cái gì đó đơn giản như robot lập trình trong một ngày
• TRUST TEAM CỦA BẠN, các tiêu chuẩn và công cụ mã hóa kiểm tra chúng khi xây dựng thường không bao giờ đọc hoặc gây phiền nhiễu.
• Xóa quyền sở hữu mã, trên một số dự án, bạn sẽ thấy các silo mã hoặc đồi kiến ​​nơi mọi người nói đó là mã của tôi và bạn không thể thay đổi mã này, điều này rất tệ và bạn có thể sử dụng lập trình được ghép nối để loại bỏ mã này.

Thay vì để họ viết mã, hãy để họ duy trì mã của họ.

Cho đến khi họ phải duy trì đống mì spaghetti hấp, họ sẽ không bao giờ hiểu được họ tệ như thế nào khi viết mã.

Không ai thích nghe ai đó nói rằng công việc của họ tệ, nhưng bất kỳ người tỉnh táo nào cũng sẽ hoan nghênh tư vấn và cách tránh những công việc không cần thiết.

Một trường dạy thậm chí còn nói rằng bạn không nên chỉ ra những sai lầm, mà hãy tập trung vào những gì được thực hiện đúng. Ví dụ, thay vì chỉ ra mã không thể hiểu là xấu, bạn nên chỉ ra nơi mã của họ đặc biệt dễ đọc. Trong trường hợp đầu tiên, bạn đang khiến người khác phải suy nghĩ và hành động như những lập trình viên nhảm nhí. Trong trường hợp sau, bạn đang chuẩn bị cho việc suy nghĩ như một chuyên gia lành nghề.

Tôi có một senario tương tự với những người tôi làm việc cùng .. Họ không tiếp xúc với tiền mã hóa nhiều như tôi nhưng họ vẫn rất hữu ích trong việc viết mã.

Thay vì tôi để cho những gì họ muốn và quay lại và chỉnh sửa toàn bộ. Tôi thường chỉ ngồi xuống và chỉ cho họ hai cách làm việc. Cách thức và cách thức của tôi, Từ đó, chúng tôi thảo luận về ưu điểm và nhược điểm của từng phương pháp và do đó đi đến sự hiểu biết tốt hơn và kết luận tốt hơn về cách chúng ta nên đi về lập trình.

Đây là phần thực sự siêu. Đôi khi họ sẽ đưa ra những câu hỏi mà thậm chí tôi không có câu trả lời, và sau khi nghiên cứu, tất cả chúng ta đều có được một khái niệm tốt hơn về phương pháp và cấu trúc.

1. Bàn luận.
2. Cho họ thấy tại sao
3. Thậm chí đừng nghĩ rằng bạn luôn đúng .. Đôi khi, họ thậm chí sẽ dạy bạn điều gì đó mới mẻ.

Đó là những gì tôi sẽ làm nếu tôi là bạn: D

Có lẽ hơi muộn sau hiệu ứng, nhưng đó là nơi mà một tiêu chuẩn mã hóa đã được thống nhất là một điều tốt.

Tôi thẳng thắn tin rằng mã của ai đó tốt hơn khi dễ dàng thay đổi, gỡ lỗi, điều hướng, hiểu, định cấu hình, kiểm tra và xuất bản (whew).

Điều đó nói rằng tôi nghĩ rằng không thể nói với ai đó rằng mã của anh ta / cô ta xấu mà không có lần đầu tiên để anh ta / cô ta giải thích nó làm gì hoặc làm thế nào để bất cứ ai phải cải thiện nó sau đó (như, tạo ra chức năng mới hoặc gỡ lỗi nó).

Chỉ sau đó tâm trí của họ chộp lấy và bất cứ ai cũng có thể thấy rằng:

• Thay đổi giá trị biến toàn cầu hầu như luôn luôn không thể theo dõi
• Các chức năng rất khó đọc và hiểu
• Các mẫu làm cho mã của bạn dễ dàng nâng cao hơn (miễn là bạn tuân thủ các quy tắc của chúng)
• ( Vân vân...)

Có lẽ một phiên lập trình cặp nên thực hiện các mẹo. Đối với việc thực thi các tiêu chuẩn mã hóa - nó giúp nhưng chúng quá xa để thực sự xác định đâu là mã tốt.

Bạn có thể muốn tập trung vào tác động của mã xấu, thay vì những gì có thể bị bác bỏ chỉ là ý kiến ​​chủ quan của bạn về việc đó là phong cách tốt hay xấu.

Hỏi riêng về một số phân đoạn mã "xấu" để xem khả năng đó là mã thực sự hợp lý , (cho dù bạn có thể bị ảnh hưởng như thế nào), hoặc có thể có các tình huống giảm nhẹ. Nếu bạn vẫn tin rằng mã chỉ đơn giản là xấu - và nguồn thực sự là người này - hãy biến đi. Một trong nhiều điều có thể xảy ra: 1) người đó thông báo và thực hiện một số hành động khắc phục, 2) người đó không làm gì cả (không biết gì, hoặc không quan tâm nhiều như bạn).

Nếu # 2 xảy ra hoặc # 1 không dẫn đến cải thiện đủ theo quan điểm của bạn, VÀ nó đang làm tổn thương dự án và / hoặc ảnh hưởng đến bạn đủ, thì có lẽ đã đến lúc bắt đầu một chiến dịch để thiết lập / thực thi các tiêu chuẩn trong đội. Điều đó đòi hỏi quản lý mua, nhưng hiệu quả nhất khi được xúi giục từ rễ cỏ.

Chúc may mắn với điều đó. Tôi cảm thây nôi đau đơn của anh bạn.