Làm thế nào tôi nên giới thiệu một tiêu chuẩn mã hóa cho nhóm của tôi?


8

Một chút nền tảng: Người quản lý phát triển hiện tại của tôi sẽ có một cơ hội khác vào cuối tuần này, để lại cho nhóm của chúng tôi với bốn nhà phát triển toàn thời gian, một nhân viên thực tập bán thời gian và một nhà thiết kế web (là một phần kỹ thuật của Marketing, không phải là AppDev). Tại thời điểm này, chúng tôi không quảng bá hoặc tuyển dụng người quản lý mới.

Người quản lý trước sẽ không bao giờ dành thời gian để đưa ra một bộ tiêu chuẩn mã hóa để tuân thủ (để đặt điều này trong viễn cảnh: Kỷ niệm một năm của tôi tại công việc này là trong hai tuần và tôi đã nói chuyện với anh ấy về các tiêu chuẩn kể từ đó Tôi đã bắt đầu). Do đó, tất cả bốn nhà phát triển của chúng tôi viết mã theo cách riêng của chúng tôi: Một số người trong chúng tôi tuân theo các quy ước đặt tên của Microsoft cho .NET, một số sử dụng ký hiệu tiếng Hungary, một số sử dụng hỗn hợp (ví dụ: trộn PascalCasecamelCasecho tên tham số) và hoàn toàn ngẫu nhiên khi bạn mở một tệp mã theo tiêu chuẩn mà nó sẽ tuân theo - về điều duy nhất nhất quán là niềng răng nằm trên các dòng riêng biệt.

Hai trong số ba đồng nghiệp của tôi đã tiếp cận tôi để tạo ra một tài liệu mã hóa tiêu chuẩn mà chúng tôi có thể sử dụng và thực thi tiến lên (mặc dù về mặt kỹ thuật tôi không phải là nhà phát triển cao cấp nhất, nhà phát triển thứ tư đã ở đây vài năm, hai đồng nghiệp và nhân viên thực tập tìm cho tôi lời khuyên / hướng dẫn nhưng chúng tôi không có trưởng nhóm). Tôi đã có ý định làm điều này trong một thời gian nhưng người quản lý sắp rời đi sẽ luôn đặt nó vào bộ đốt ngược; sự ra đi của anh ấy bây giờ cho chúng tôi một cơ hội để dành thời gian và cấu hình mọi thứ một cách chính xác để tạo điều kiện cho một môi trường phần mềm thích hợp và không phải là nơi ẩn náu vội vã mà chúng tôi hiện đang có.

Làm thế nào tôi nên làm điều này và giới thiệu tiêu chuẩn này cho nhóm của tôi mà không gây ra ma sát? Tôi không muốn làm cho nó giống như tôi đang "tiếp quản", mặc dù tôi đã đề nghị vị trí quản lý tôi sẽ chấp nhận nó. Như tôi đã nói, hai trong số ba nhà phát triển khác cùng tham gia với tôi tạo ra một, nhưng người thứ tư ("cấp cao" thực sự trong thời gian dài) có thể hoặc không thể chấp nhận nó. Tôi dự định bắt đầu với các quy ước .Net từ Microsoft (ví dụ: không sử dụng Ký hiệu Hungary), thêm một số tùy chọn cá nhân (ví dụ: _camelcasecho các trường) và đặc biệt gọi ra một số thực tiễn lạ mà chúng tôi sử dụng ở đây là không được sử dụng (ví dụ: đặt tên một lớp với một dấu gạch dưới khi bắt đầu), nhưng tôi nên bao gồm những gì khác? Tôi không muốn đi vào hướng dẫn kiến ​​trúc như ý muốn gây ra ma sát và chúng ta có một cơ sở mã hiện có rất lớn và có mùi, không tuân thủ nó, và chúng ta không ở đâu đến lúc đưa ra chiến lược tái cấu trúc.

Tóm tắt: Ngoài các quy ước đặt tên cơ bản, nếu có bất cứ điều gì, tôi nên đưa vào tài liệu tiêu chuẩn mã hóa (ví dụ sẽ rất tuyệt - tôi đã không tìm thấy bất kỳ ví dụ cụ thể nào về tài liệu đó sẽ như thế nào) và tôi nên làm thế nào trình bày nó cho đội của tôi mà không có âm thanh như nhà độc tài mới.


Ngoài các quy ước đặt tên, bạn sẽ muốn một cách tiêu chuẩn để mô tả những gì tệp làm trong các tiêu đề, cộng với có thể là một cấu trúc thư mục được tiêu chuẩn hóa. Xem hướng dẫn về phong cách của Google làm ví dụ.
chrisaycock

Bạn không có người quản lý / trưởng nhóm và bạn lo lắng về các tiêu chuẩn mã hóa!
mattnz

Chúng tôi có thể không cần một người lãnh đạo nhóm phải trung thực, hầu hết chúng tôi đồng ý về mọi thứ và tự mình hợp tác. Các tiêu chuẩn là một mối quan tâm bởi vì đó là "hãy nói về chúng" trong gần một năm nay với thời gian không được phân bổ để ngồi xuống thảo luận về một số.
Wayne Molina

2
Việc bạn không ngồi xuống trong một cuộc họp 30 phút trong gần một năm cho tôi thấy bạn thực sự cần một người lãnh đạo nhóm.
mattnz

Có lẽ. Người quản lý trước đã vội vàng viết mã, không "lãng phí thời gian" với những việc như nói về các tiêu chuẩn hoặc cố gắng thực hiện CI, kiểm tra, đánh giá mã hoặc tương tự. Một lần chúng tôi cố gắng băm nó ra, nhà phát triển cấp cao đã nhận ra rằng cuộc họp đã diễn ra quá lâu ("Tôi có việc phải làm!" Là trích dẫn chính xác) và xông ra, kết thúc nó đột ngột.
Wayne Molina

Câu trả lời:


10

Làm thế nào tôi nên làm điều này và giới thiệu tiêu chuẩn này cho nhóm của tôi mà không gây ra ma sát?

Bạn cũng nói:

Hai trong số ba đồng nghiệp của tôi đã tiếp cận tôi để tạo ra một tài liệu mã hóa tiêu chuẩn mà chúng ta có thể sử dụng và thực thi để tiến lên phía trước

Có vẻ như bạn đã có một số tiền mua từ hầu hết các đội. Tạo tài liệu một cái gì đó được thực hiện bởi tất cả các bạn (cả bốn nếu có thể). Nếu điều này quá tốn thời gian, hãy đến với tài liệu của bạn và hiển thị nó như một bản nháp cho các đồng nghiệp của bạn. Một khi tất cả các bạn đã đồng ý và hoàn thành một phiên bản, bạn sẽ thấy tốt.

Một nơi tốt để bắt đầu là xem xét các quy tắc stylecop khác nhau - bạn không cần phải tuân thủ tất cả, nhưng những điều này sẽ cho bạn ý tưởng về những gì tài liệu của bạn nên chứa. Là một phần thưởng bổ sung, bạn có thể dễ dàng triển khai stylecop trong các giải pháp của mình và thậm chí tích hợp vào một bản dựng tự động (không thể xây dựng nếu có vi phạm).

Để tóm tắt:

Nhìn vào các công cụ và tiêu chuẩn hiện có để quyết định những gì bạn muốn trong bạn.

Để tránh trông giống như một kẻ độc tài, hãy thay đổi thành một sự hợp tác.


"Để tránh trông giống như một kẻ độc tài, hãy thay đổi thành một sự hợp tác." Thật vậy. Bạn có ba con đường dẫn đến thành công ở đây: 1. sử dụng một tiêu chuẩn bên ngoài, theo cách đó mọi người đều có thứ họ thích và thứ gì đó họ không (fxcop, stylecop hoặc thậm chí bất kỳ .pdf nào bạn có thể tìm thấy trên web). 2. Thế hệ hợp tác. 3. Bạn là một anh hùng huyền thoại với nhiều năm kinh nghiệm và mọi người đổ xô hợp tác với bạn và được mọi người yêu mến, hoặc có thể tên cuối cùng của bạn là Zuckerberg, Page hoặc Brin.
anon

6

Ngoài các quy ước đặt tên cơ bản, nếu có bất cứ điều gì, tôi nên đưa vào tài liệu tiêu chuẩn mã hóa

Không có gì.

Hãy dành thời gian của bạn. Đi chậm thôi. Đừng lãng phí thời gian viết. Các quy ước mã hóa chỉ hoạt động khi chúng là một phần của văn hóa chung.

Nếu họ không phải là một phần của văn hóa, họ chỉ đơn giản là bị bỏ qua.

Làm thế nào tôi nên làm điều này và giới thiệu tiêu chuẩn này cho nhóm của tôi

Mã đánh giá. Đó là một nơi tuyệt vời để giới thiệu vấn đề được giải quyết bằng các quy ước mã hóa.

Hầu hết thời gian, các quy ước chỉ đơn giản là lãng phí thời gian. Khi bạn gặp sự cố thực tế (nghĩa là các chương trình không thể đọc được) mà bạn có thể giải quyết thông qua các quy ước mã hóa, bạn có thể nhanh chóng tuân thủ 100%.

Các quy ước mã hóa chỉ đơn thuần là sở thích cá nhân không giải quyết được vấn đề. Và thực sự, trong quá trình xem xét mã, bạn có thể tìm ra thứ gì đó tốt hơn và thực sự thay đổi sở thích cá nhân của bạn.

Đừng chuẩn hóa quá nhiều trong một tài liệu quy ước mã hóa. Làm việc hợp tác để đi đến một sự hiểu biết chung.

Tôi không muốn tham gia vào các hướng dẫn kiến ​​trúc vì điều đó sẽ gây ra ma sát và chúng ta có một cơ sở mã hiện có rất lớn và có mùi, không tuân thủ nó,

Chính sách tồi.

Một tiêu chuẩn kiến ​​trúc không bao giờ là một cái gì đó với sự tuân thủ 100%. Không thể nào. Nó luôn luôn là một mô tả "hướng tới tương lai", hướng tới sự phát triển phát triển.

Mỗi ý tưởng kiến ​​trúc tốt sẽ dẫn đến một hướng kiến ​​trúc mới. Và đó là những gì đổi mới trông giống như - một con đường, không phải là một mục tiêu.

và chúng ta không ở đâu gần đến lúc đưa ra chiến lược tái cấu trúc.

Tốt Đừng phát triển một cái. Điều đó có nghĩa là "đừng kìm hãm sự đổi mới bằng cách viết ra quá nhiều điều có thể hoặc không thể là cách tiếp cận tốt nhất có thể."


4

Với một cái gì đó giống như các quy ước về mã hóa, tôi sẽ nói rằng bất kỳ quy ước cụ thể nào cũng phải nhất trí 100% hoặc tìm một số điểm trung gian khiến nó nhất trí 100%.

  • Đặt thời hạn hoàn thành tài liệu, điều này sẽ buộc người khác phải nghiêm túc.

  • Làm công việc biên soạn tài liệu, không ai cảm thấy muốn giúp bạn nhưng nếu bạn sở hữu tác phẩm thì sẽ không có ai chống lại bạn trên đó.

  • Gửi các đề xuất cho các quy ước mã hóa khác nhau dựa trên các phong cách khác nhau tồn tại trong cơ sở mã bây giờ. Thu thập thông tin phản hồi và thiết lập một cuộc họp nơi họ có thể được bỏ phiếu.

  • Không ai rời khỏi cuộc họp cho đến khi mỗi hội nghị đã đi đến thỏa thuận nhất trí 100%

  • Những người mới vào đội sẽ phải tuân theo tài liệu và sẽ không nói gì. Nó giống như Hiến pháp ở điểm đó.

Oh và không có ký hiệu Hungary. Nghiêm túc mà nói, tôi thà cắt giấy mắt còn hơn phải xem mã theo ký hiệu Hungary.


1
Tiếng Hungary là một điều lớn, và các tên lớp gạch dưới cũng vậy. Nhìn thấy thứ gì đó như _Customer oCust = new _Customer();khiến tôi lắc đầu ngơ ngác.
Wayne Molina

Tôi nhận nhiệm vụ biên soạn một bộ Tiêu chuẩn mã hóa mới cho công ty của mình. May mắn thay, tôi đã có sự giúp đỡ từ một nhóm các Nhà phát triển cao cấp, những người mới tham gia vào công ty và chúng tôi đã có một VP ủng hộ chúng tôi với việc thực thi. Chúng tôi cập nhật tài liệu vài tháng một lần khi cần thiết. Sau lần sửa đổi lớn thứ 2, tôi đã thêm phần đánh số vào tài liệu để dễ dàng tham chiếu một tiêu chuẩn cụ thể khi dự án không xem xét mã. "Kiểm tra phần 5.3.4.6 về cách sử dụng hàmA thay vì hàmB". Trong năm ngoái, cuối cùng chúng tôi cũng nhận được ít đánh giá mã thất bại hơn.
Adrian J. Moreno

1

Các tiêu chuẩn mã hóa sẽ là một thách thức để được chấp nhận. Một số người thích mã hóa trong hộp cát của họ và chỉ làm việc của họ mặc dù thực tế nó có thể gây ra sự cố nếu nó bị hỏng và những người khác đang cố gắng sửa nó.

Nếu bạn đang sử dụng Visual Studio với .NET, hãy xem StyleCop. Bạn có thể sử dụng các quy tắc được xác định trước hoặc viết riêng của bạn. Sau đó, mọi người đồng ý trước khi đánh giá mã (nếu bạn có chúng) rằng bạn nên tuân thủ các cài đặt.


1

Từ quan điểm kỹ thuật:

Chỉ ra những mâu thuẫn thực sự là một vấn đề đối với nhóm và xác định các quy tắc mã hóa để giải quyết các vấn đề này.

Từ quan điểm quan hệ:

Nếu bạn muốn có được sự tham gia của cấp cao, hãy lấy một số cảm hứng từ các quy ước mã hóa của riêng anh ấy.


Heh một phần lý do chúng tôi muốn các tiêu chuẩn mã hóa là bởi vì cấp cao không tuân theo bất kỳ. Anh ta sử dụng ký hiệu Hungary ở khắp mọi nơi, anh ta không biết rằng các phương thức có thể bị quá tải (vì vậy sẽ giống như một GetFoophương thức, và sau đó GetFoo_WithSomethingElsephương thức có cùng một thứ nhưng với một tham số phụ, với tất cả logic được sao chép và sau đó thêm được thêm vào) và anh ta không hiểu thiết kế lớp ngoài việc nhồi nhét nhiều logic vào một tệp phía sau mã. Người quản lý rời đi không quan tâm đến việc làm những điều khác biệt nên chỉ đi theo phong cách đó.
Wayne Molina

Đây là những gì tôi nghĩ. Có vẻ như dự án của bạn không có vấn đề kỹ thuật và bạn cố gắng giải quyết chúng bằng câu trả lời kỹ thuật.
mouviciel

Điều gì sẽ là cách chính xác để giải quyết các vấn đề sau đó? Vấn đề là không ai đưa ra những điều này cho bất kỳ sự suy nghĩ nào kể từ khi công ty bắt đầu.
Wayne Molina

Tôi có thể sai, nhưng vấn đề tôi thấy là một nhà phát triển cao cấp đã viết mã trong nhiều năm không có lý do gì để thay đổi, đặc biệt nếu yêu cầu đến từ một thiếu niên (tôi không đặt câu hỏi về năng lực của bạn). Tôi thấy không có giải pháp chung, vì tôi không biết đủ về tình huống này.
mouviciel

0

Miễn là bạn không phải là người quản lý mới trong nhóm của mình, bạn cần có sự đồng thuận về việc có một tiêu chuẩn mã hóa (và nếu bạn là người quản lý, bạn thực sự nên cố gắng để có được sự đồng thuận trong nhóm trước khi đưa ra quyết định như vậy "từ bên trên "). Và nghe có vẻ đơn giản, nhưng chỉ nói chuyện - đặc biệt là nói chuyện với nhà phát triển thứ tư - có thể giải quyết điều này.


0

Bạn có một công ty Wiki? Hoặc, thất bại, một máy chủ mà bạn có thể thả một cái trên?

Nếu vậy thì chỉ cần tạo một trang. Gọi nó là một tài liệu sống. Đặt ra một vài tiêu chuẩn không gây tranh cãi và khuyến khích mọi người khác cộng tác. Tiếp tục thêm các mục mỗi vài tuần, khuyến khích thảo luận nhưng theo cách nói "nếu không ai không đồng ý thì chúng ta nên mong đợi điều này sẽ được tuân theo." Nếu bạn có thể, hãy thuyết phục mọi người đăng ký các tài liệu tiêu chuẩn, để bạn có thể thấy bất kỳ thay đổi nào mà đồng nghiệp của bạn thực hiện.

Cũng cố gắng để nhóm bắt đầu đánh giá mã. Mỗi công việc đều trải qua hai nhà phát triển. Điều này sẽ khuyến khích thảo luận và thực thi tiêu chuẩn, và làm cho nó để mọi người đều bình đẳng, không phải là một nhà phát triển ra lệnh cho các quy tắc.

Chỉnh sửa để phản hồi bình luận:

Bạn có thể bán đánh giá mã như một cách để Dev # 4 truyền bá trí tuệ của mình. Ngay cả khi mã của anh ta đang được xem xét, đó là cơ hội để mọi người thấy mã ma thuật của anh ta và đắm chìm trong nỗi sợ hãi về nó. Thực sự, đó là một cách để thúc đẩy thảo luận. Trường hợp lập trình viên và người đánh giá không thể đồng ý, thì nên đến nhóm. Trường hợp nhóm không thể đồng ý, nghiên cứu nên được thực hiện.

Nói về nghiên cứu, làm một số đánh giá mã. Không ai có ý kiến ​​cho nhiều người nghĩ rằng họ là một ý tưởng tồi. Đặt nó cho nhóm, bao gồm cả CIO, trong một email có rất nhiều liên kết. Thật khó để tranh luận với họ mà không trông giống như một thằng ngốc cản trở.

Dưới đây là một số để giúp bạn bắt đầu:

Đối với Wiki, tôi thực sự khuyên bạn nên dành thời gian để thiết lập (Wikis đưa ra ảo tưởng về sự hợp tác, ngay cả khi nó không thực sự ở đó). Nhưng nếu bạn không thể thì một tài liệu Word trên ổ đĩa chung sẽ thực hiện công việc.


Chúng ta không có một cái; đó là một cái gì đó chúng tôi (bất cứ khi nào tôi nói "chúng tôi", ý tôi là bản thân tôi và hai nhà phát triển trì hoãn với tôi - thứ tư về cơ bản là một "đặc công" và xử lý các phần di sản / phức tạp của ứng dụng mà phần còn lại của chúng tôi không chạm vào - ngay cả trước khi người quản lý rời Dev # 4 đã báo cáo trực tiếp với CIO, không phải cho người quản lý) đang nói về. Nhận xét về mã Tôi không chắc chúng tôi có làm được không, vì một số người có thể vi phạm nếu mã của họ bị nghi ngờ (nhiều khả năng là Dev # 4 vì anh ta sẽ phải thay đổi cách anh ta làm mọi thứ để tuân thủ các tiêu chuẩn mới dù sao)
Wayne Molina

@WayneM Nơi tôi làm việc, chúng tôi cũng không có wiki. Thật dễ dàng để thiết lập một dokuwiki vm để bắt đầu. Bạn có thể chạy thứ đó ra khỏi hộp cá nhân của mình nếu cần thiết và một khi mọi thứ bắt đầu, việc di chuyển đến một máy chủ "thực" khá dễ dàng.
Spencer Rathbun

1
@WayneM: Xem chỉnh sửa.
pdr

0

Nhận xét và tiêu chuẩn khoảng trắng là tốt, cùng với các công cụ để di chuyển giữa các phong cách khác nhau. Tôi sử dụng các tab trong mã python của tôi, được coi là phong cách xấu. Tuy nhiên, một hàm VIM đơn giản chuyển đổi giữa hai khi cần thiết.

Ngoài ra, hãy suy nghĩ về mức độ hiểu mã. Mục đích của một phong cách là để truyền đạt thông tin đến người lập trình đọc mã. Nếu bạn có thể hiểu reduce(lambda x, y: x+y, map(lambda x: x + 1, theList)), nhưng đồng nghiệp của bạn sẽ thấy:

for pos,item in enumerate(theList):
    theList[pos] = item + 1
tmp = 0
for item in theList:
    tmp = tmp + item

Sau đó, điều này rất quan trọng để băm ra. Tương tự với không gian màu trắng. Bạn cần phải tìm ra mức độ nén mã mà mọi người đều cảm thấy thoải mái.

Cuối cùng, làm thế nào để các dự án mới, và các dự án hiện tại, bị cắt giảm? Một lớp cho mỗi tệp, các hàm tiện ích tuân theo sơ đồ đặt tên, không có biến toàn cục hoặc rò rỉ phạm vi, các tệp dự án ngẫu nhiên là trực giao và được ghép lỏng lẻo, v.v. Điều này cung cấp một cơ sở hiểu biết quan trọng cho tất cả mọi người. Không có vấn đề gì về tiêu chuẩn mã hóa, nếu mọi dự án đan xen nhau đến mức tôi phải đi qua toàn bộ cơ sở mã và thực sự mò mẫm dự án trước khi tôi xoay vòng foo().

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.