Làm thế nào để đối phó với các phong cách lập trình khác nhau trong một nhóm?

Chúng tôi có một nhóm phát triển nhỏ (chỉ có 3 nhà phát triển) và gần đây chúng tôi đã có một thành viên nhóm mới. Trong khi anh ấy là một lập trình viên thông minh, phong cách mã hóa của anh ấy hoàn toàn khác với chúng ta. Cơ sở mã hiện tại của chúng tôi chứa hầu hết mã có thể đọc, sạch và có thể bảo trì, nhưng thành viên nhóm mới đang nhanh chóng thay đổi nhiều tệp, giới thiệu các bản hack và phím tắt xấu xí, sử dụng định nghĩa khắp nơi, thêm chức năng ở sai vị trí, v.v.

Câu hỏi của tôi là nếu những người khác đã trải qua một tình huống như vậy trước đây, và nếu có ai có lời khuyên về cách nói chuyện với anh ta.

Tôi làm việc với một nhóm phát triển từ 2 nhà phát triển lên 10 trong chưa đầy một năm. Tôi là số 3 và là người đầu tiên đưa ra vấn đề về tiêu chuẩn mã hóa. Hai nhà phát triển ban đầu đã làm việc cạnh nhau trong một vài năm và họ đã áp dụng một tiêu chuẩn chung có vẻ xa lạ với tôi. Chúng tôi đã có chính xác những vấn đề tương tự như bạn đang mô tả.

Những gì chúng tôi đã làm là:

Nghiên cứu tiêu chuẩn mã hóa

Chúng tôi đã dành vài ngày để kiểm tra các dự án nguồn mở được thiết lập. Chúng tôi biết nhóm sẽ mở rộng nhanh chóng và chúng tôi đang tìm kiếm các giải pháp thực sự dựa trên các dự án thực tế chứ không phải một số hướng dẫn chung chung. Ngoài ra, chúng tôi không quan tâm đến các tiêu chuẩn mã hóa tối ưu, nhưng đối với một bộ quy tắc và hướng dẫn sẽ có ý nghĩa và không kêu gọi tái cấu trúc tất cả các cơ sở mã của chúng tôi. Chúng tôi đã tìm kiếm một hack tiêu chuẩn mã hóa nếu bạn muốn.

Ba chúng tôi đã quyết định rằng các tiêu chuẩn mã hóa tốt nhất hiện có cho một dự án PHP đã được thiết lập là những tiêu chuẩn được theo sau bởi Zend Framework. May mắn thay, người Zend Framework cung cấp một tài liệu tiêu chuẩn mã hóa rất toàn diện .

Tạo tiêu chuẩn mã hóa của riêng chúng tôi

Tất nhiên áp dụng các tiêu chuẩn mã hóa của dự án khác vào dự án của chúng tôi là không có ý nghĩa. Chúng tôi sử dụng tài liệu Khung Zend làm mẫu:

• Đầu tiên chúng tôi xóa mọi thứ không áp dụng cho dự án của chúng tôi
• Sau đó, chúng tôi đã thay đổi mọi thứ mà chúng tôi coi là vấn đề của phong cách theo phong cách của chúng tôi
• Và cuối cùng chúng tôi đã viết mọi thứ xuống

Vì vậy, chúng tôi đã có một tài liệu khá lớn trong tay, được lưu trữ trong wiki ưa thích của chúng tôi , đó là một cuốn sách hay, được tất cả chúng ta đồng ý. Và hoàn toàn vô dụng trên chính nó.

Giữ đúng lời hứa của chúng tôi

Codebase của chúng tôi tại thời điểm đó là khoảng 1 * 10 ^ 6 sloc. Chúng tôi biết rằng vì chúng tôi đã áp dụng các tiêu chuẩn mã hóa chính thức, chúng tôi phải bắt đầu tái cấu trúc mã của mình, nhưng tại thời điểm đó, chúng tôi đã bị ép với các vấn đề khác. Vì vậy, chúng tôi quyết định chỉ cấu trúc lại các thư viện rất cốt lõi của chúng tôi, chỉ là một khối 5 * 10 ^ 3.

Chúng tôi đã chỉ định một trong số chúng tôi làm chủ tiêu chuẩn mã hóa (chúng tôi sử dụng thô tục địa phương thay cho chủ ) với trách nhiệm kiểm tra và thi hành các tiêu chuẩn. Chúng tôi tái chế vai trò cứ sau vài lần chạy nước rút. Tôi là người đầu tiên, và đó là rất nhiều công việc, vì tôi phải theo dõi hầu hết mọi cam kết.

Chúng tôi đã có một vài cuộc thảo luận mới và các phụ lục nhỏ cho tài liệu gốc trong nhiệm kỳ của tôi và cuối cùng chúng tôi đã có một tài liệu hơi ổn định. Chúng tôi thay đổi nó mọi lúc mọi nơi nhưng hầu hết những thay đổi này là trên các tính năng mới của ngôn ngữ, vì PHP 5.3 là một bản phát hành chính trong tất cả trừ tên.

Đối phó với anh chàng mới

Khi anh chàng mới tiếp theo đến, đã đến lúc đưa các tiêu chuẩn mã hóa của chúng tôi vào thử nghiệm. Sau phần giới thiệu nhỏ về cơ sở mã của chúng tôi, chúng tôi đã yêu cầu anh ấy đánh giá tài liệu tiêu chuẩn mã hóa của chúng tôi. Anh gần như đã khóc. Có vẻ như anh ấy đã làm mọi thứ khác đi.

Vì tôi là bậc thầy về tiêu chuẩn mã hóa vào thời điểm đó, nên tôi phải đánh giá đầu vào của anh ấy và sửa đổi tài liệu cho phù hợp. Đề xuất của ông là:

• Các vấn đề về phong cách cá nhân (cuối cùng bị loại bỏ)
• Các tiêu chuẩn có ý nghĩa đối với nền Java của anh ta nhưng không quá nhiều với PHP (bị loại bỏ)
• Các quy ước mà ông đã thực hiện từ lần tiếp xúc ngắn ngủi với PHP (một số đã bị bác bỏ, nhưng rất nhiều chứng minh là các quy ước phổ biến mà chúng tôi chưa bao giờ nghĩ tới hoặc tìm ra trong nghiên cứu ban đầu của chúng tôi)

Trong vài tuần tiếp theo, anh được giao một nhiệm vụ đơn giản: Đưa một số phần của cơ sở mã của chúng tôi cập nhật với các tiêu chuẩn. Tôi đã phải cẩn thận chọn những phần đó dựa trên một vài quy tắc:

• Mã phải tương đối dễ dàng đối với người không quen thuộc với cơ sở mã của chúng tôi (và PHP nói chung)
• Mã phải dựa trên những gì anh ta được thuê để làm

Tôi theo dõi quá trình của anh ấy và anh ấy đã làm rất tốt. Chúng tôi đã xác định một số phần mã không thể phù hợp với tài liệu của chúng tôi và được sửa đổi cho phù hợp (mã và / hoặc tiêu chuẩn, tùy theo ý nghĩa nào hơn)

Và rồi một chàng trai mới đến. Chúng tôi lặp lại quá trình (chủ khác nhau lần này), và nó hoạt động trở lại. Và một lần nữa.

Tóm lại là

1. Tạo một tài liệu tiêu chuẩn mã hóa, nhưng đảm bảo rằng các tiêu chuẩn của bạn không chỉ là của riêng bạn mà còn phản ánh các tiêu chuẩn chung trong cộng đồng rộng lớn hơn của nền tảng của bạn.
2. Gán một vai trò tương tự như chủ tiêu chuẩn mã hóa của chúng tôi. Có người theo dõi ít ​​nhất mã mới và đặc biệt là mã mới từ các thành viên mới. Tái chế vai trò, vì nó vô cùng nhàm chán.
3. Luôn đánh giá đầu vào từ một thành viên mới. Luôn luôn sửa đổi các tiêu chuẩn của bạn nếu nó có ý nghĩa. Tài liệu tiêu chuẩn mã hóa của bạn nên được phát triển, nhưng chậm. Bạn không muốn cấu trúc lại codebase của mình ở mỗi lần lặp.
4. Dành một chút thời gian để mỗi thành viên mới học hỏi và thích nghi với các tiêu chuẩn và quy ước của bạn. Học bằng cách làm việc tốt nhất trong những tình huống này.
5. Wiki hoạt động kỳ diệu cho các tài liệu như vậy.
6. Mã đánh giá công việc kỳ diệu cho bất kỳ tình huống!

Tại một số điểm trong quy trình, chúng tôi đã đề xuất rằng chúng tôi sử dụng móc nối trước để tự động kiểm tra các tiêu chuẩn. Chúng tôi đã quyết định chống lại nó vì nhiều lý do, có một số cuộc thảo luận thú vị về StackOverflow về vấn đề này:

• SVN định dạng mã tự động khi check in?
• Kiểm soát phiên bản và định dạng mã hóa
• PHP Codeniffer (phpcs) - làm thế nào để cho phép ghi đè khi sử dụng như một phần của hook pre-commit svn?
• SVN Pre-commit hook được kích hoạt cho một thư mục cụ thể
• Thực hiện các tiêu chuẩn mã hóa PHP

Một số là cụ thể PHP, nhưng câu trả lời áp dụng cho tất cả các nền tảng.

Vâng, tôi đã trải nghiệm điều đó trước đây. Khi làm việc trong một nhóm, các thành viên trong nhóm phải đồng ý về các quy tắc và quy ước nhất định và bao gồm cả phong cách.

Bạn nên để nhóm của mình ngồi lại với nhau và soạn thảo một bộ quy tắc, tiêu chuẩn mã hóa , mà bạn sẽ yêu cầu mọi đoạn mã được kiểm tra phải tuân thủ.

Rất có thể, cơ sở cho bộ quy tắc của bạn, ít nhất là kiểu dáng, sẽ là mã hiện có. Sau khi hoàn thành, mọi người phải tuân thủ và cần được kiểm tra như một phần của đánh giá mã . Mã không tuân thủ các tiêu chuẩn không được phép kiểm tra.

Nhân tiện, nó không phải là một cuộc bỏ phiếu dân chủ, một trong những điều mà người lãnh đạo nhóm thực sự có thể thực thi một số quyền lực. Nhưng có nói rằng, tôi không nghĩ rằng bạn có thể áp đặt các tiêu chuẩn mà phần lớn nhóm từ chối. Bạn có thể áp đặt các tiêu chuẩn mà một người, đặc biệt là một người mới, từ chối.

Về cách nói chuyện với anh ta ... Mỗi lập trình viên có kinh nghiệm đều biết rằng mỗi nơi và nhóm có quy ước và phong cách riêng, cần phải tuân theo. Bạn có thể nói với anh ấy rằng anh ấy rất hoan nghênh đề xuất cải tiến, nhưng anh ấy phải tuân thủ các quy tắc của nhóm và anh ấy không nên thay đổi kiểu mã hiện tại mà nên sử dụng cùng một kiểu khi thêm mã mới.

Ngoài ra, bạn có thể nói (nếu bạn là người quản lý hoặc nói chuyện với người quản lý của mình về vấn đề đó) với người đó để không làm những việc mà bạn cho là không phù hợp (bạn đã đề cập đến định nghĩa, thứ tự, hack và phím tắt, v.v.).

1. Ai đó chịu trách nhiệm - họ cần hành động như vậy.
2. Nếu phong cách mã hóa rất quan trọng, tại sao điều này không được giải thích cho người này và cho họ biết rằng họ sẽ không có quyền truy cập vào bất kỳ mã nào cho đến khi họ tìm hiểu các quy tắc.
3. Đánh giá mã - rõ ràng bạn không có bất kỳ hoặc nó rất yếu. Xem # 1.

Hãy lưu ý trong quá trình tuyển dụng của bạn, rằng tuân theo các kiểu mã hóa được chấp nhận là một yêu cầu cho việc làm. Bây giờ bạn làm gì với những người không tuân theo các quy tắc? Bắt đầu bằng cách loại bỏ quyền truy cập của họ vào mã trực tiếp cho đến khi họ nhận được với chương trình.

.

Đây là những gì có thể được thực hiện:

1. Viết một tài liệu giải thích phong cách mã hóa cần thiết và khiến mọi người trong nhóm học nó. Thu thập thông tin từ mọi thành viên trong nhóm.
2. phân chia nhiệm vụ theo cách sao cho mọi thành viên trong nhóm chịu trách nhiệm về phần của riêng họ và có thể quyết định các quy ước của phần đó của mã. Nếu bất kỳ vấn đề được tìm thấy, bất cứ ai đã viết nó sẽ khắc phục vấn đề.
3. thêm một công cụ tự động để kiểm soát phiên bản giúp sửa lỗi thụt lề và các công cụ khác mỗi khi mã được cam kết với kiểm soát phiên bản
4. Các lập trình viên khác nhau luôn có phong cách lập trình khác nhau, và sau này có thể khó thay đổi. Cách tốt nhất để xử lý nó là chia sẻ thông tin giữa các thành viên trong nhóm để mọi người tìm hiểu phong cách mà mọi người đã sử dụng. Nếu bạn có một thành viên trong nhóm viết mã khác nhau, đó là cơ hội cho các thành viên nhóm hiện tại của bạn học phong cách mới.
5. Một mẹo hay là không bao giờ sửa đổi mã hiện có. Thay vì sửa đổi mã, hãy viết mã mới bằng cách thay thế các dòng trống bằng mã mới. Và một khi mã đã sẵn sàng, chỉ thực hiện một số sửa đổi nhỏ nhất cho hệ thống hiện có để đưa mã mới vào sử dụng. Điều này tránh điều chỉnh mã hiện có, có thể phá vỡ những gì đã hoạt động tốt.

Đây là những điều cần tránh:

1. quyết định rằng mã của ai đó tốt hơn hoặc xấu hơn các thành viên khác trong nhóm. Nó chỉ không hoạt động như vậy - mọi người đều biết một tập hợp con nhất định của ngôn ngữ đủ để sử dụng nó trong mã. Mỗi lập trình viên đã chọn các tập hợp con khác nhau để tìm hiểu và trừ khi họ học nó cùng nhau, nó sẽ trông khác nhau.
2. Thay đổi cách ai đó viết mã. Tất cả những gì bạn nhận được bằng cách buộc mọi người viết kiểu lạ là bạn nhận được số lượng lớn lỗi trong mã. Mọi người chỉ không biết đủ chi tiết về thứ họ sử dụng lần đầu tiên. Các lập trình viên luôn chọn một tập hợp con của ngôn ngữ và sử dụng ngôn ngữ đó một mình. Nếu các lập trình viên của bạn đã viết hàng ngàn dòng mã chứa đầy gotos, thì gotos sẽ cung cấp cho bạn mã có ít lỗi nhất.
3. Bạn cũng không nên nghĩ rằng cơ sở mã hiện tại của bạn là công cụ tốt, sạch sẽ, có thể bảo trì. Luôn luôn có những điều cần cải thiện. Nhưng cũng có mỗi thay đổi làm mờ ý tưởng thiết kế ban đầu được viết cho nó. Đặt mục tiêu viết mã hoàn hảo ngay lần đầu tiên, để những thay đổi sẽ không cần thiết sau này. (anh chàng mới sẽ không cần phải "phá vỡ" mã hoàn hảo của bạn, nếu nó được thực hiện đúng lần đầu tiên)

Cơ sở mã hiện tại của chúng tôi chứa hầu hết mã có thể đọc, sạch và có thể bảo trì

Một điều tôi đã học được trong nhiều năm qua là khả năng đọc nằm trong mắt của kẻ si tình. Tôi đã thấy nhiều trường hợp trong đó phong cách mã hóa gà của ai đó được chứng minh là "có thể đọc được" và tôi đã thấy những người hoàn toàn hợp lý tranh luận về kiểu mã hóa nào là "dễ đọc" nhất. Có lẽ anh chàng này không xem phong cách của bạn là có thể đọc được?

Điều đó nói rằng, anh chàng mới nên phù hợp với tiêu chuẩn của bạn, không phải cách khác.

Xem xét sử dụng các yêu cầu kéo cho mã mới vào kho lưu trữ. Điều này cung cấp một nơi thuận tiện để làm mã xem xét. Mã không xem xét mã sẽ không được hợp nhất vào kho lưu trữ cho đến khi nó được định hình.

Chỉ cần cẩn thận không làm cho các yêu cầu kéo quá lớn. Theo kinh nghiệm của tôi, họ không nên lớn hơn giữa nửa ngày đến tối đa hai ngày hoặc bạn sẽ có quá nhiều xung đột hợp nhất.

Các hệ thống vcs trực tuyến như bitbucket hoặc github hỗ trợ chức năng này. Nếu bạn thích một phương pháp tiếp cận tại chỗ, có vẻ như đặt cược tốt nhất hiện tại.

Có một quy tắc đơn giản mà bạn có thể tuân theo: Nếu bạn sửa đổi một tệp có mã, bạn sử dụng tiêu chuẩn mã hóa được sử dụng trong tệp đó. Nếu bạn tạo một tệp mới, bạn sử dụng bất kỳ tiêu chuẩn mã hóa tốt nào. (Plus: Nếu trình biên dịch của bạn có thể đưa ra cảnh báo, bạn bật tất cả các cảnh báo hợp lý, bật cảnh báo = lỗi nếu có thể và không cho phép bất kỳ mã nào có cảnh báo. Plus: Nếu bạn sử dụng các công cụ thực hiện thay đổi bán buôn trong một tệp, như thay đổi các tab vào khoảng trắng hoặc tương tự, KHÔNG sử dụng chúng).

Lý do tại sao có những tranh luận lớn về các tiêu chuẩn mã hóa là một tiêu chuẩn không tốt hơn hoặc kém hơn so với tiêu chuẩn khác (thông thường) mà chỉ khác nhau. Điều thực sự tồi tệ duy nhất là trộn các phong cách mã hóa.

Rõ ràng tôi mong đợi rằng bất kỳ lập trình viên tử tế nào cũng có thể viết mã theo bất kỳ tiêu chuẩn mã hóa nào, cho dù họ có thích tiêu chuẩn cụ thể đó hay không.

Và mặt khác, có tiêu chuẩn chất lượng. Không bao giờ chấp nhận mã không đáp ứng các tiêu chuẩn chất lượng của bạn.