Điều gì về tất cả các quy tắc mã hóa?

Tôi luôn ủng hộ ý tưởng có các quy tắc mã hóa cho các nhà phát triển trong một công ty hoặc một dự án cụ thể. Đặc biệt nếu công ty có quy mô lớn hơn 10. Công ty càng lớn thì nhu cầu càng lớn. Tôi biết nhiều người sẽ không đồng ý, nhưng tôi đã thấy các dự án không có chúng và mã trông giống như thảm họa hoàn toàn.

Vấn đề thực sự xuất phát từ vấn đề này là làm thế nào để khiến những người khó tính không thích sử dụng dấu ngoặc trong câu lệnh if hoặc sử dụng cùng một chuỗi kết nối ở mọi nơi trong mã, hoặc bất cứ điều gì, để sử dụng quy tắc mã hóa mà không khiến chúng phản đối Ý tưởng?

Để họ tham gia vào việc sửa chữa một vấn đề thay vì các quy tắc chiến đấu. Cá nhân tôi thích ý tưởng về "hướng dẫn phong cách", "tiêu chuẩn mã hóa" hoặc một cái gì đó tương tự, với hy vọng rằng nó ngăn chặn phản ứng "quy tắc = xấu" của đầu gối.

Nhưng ngay cả khi nó xảy ra - tôi có xu hướng nghĩ rằng các quy tắc được đặt ra vì một lý do và cách để khiến những người khó tính quay đầu lại là để họ nhận ra rằng bằng cách làm theo các hướng dẫn, họ đang giúp làm cho mã dễ dàng hơn đọc cho mọi người

Đôi khi áp lực ngang hàng là giải pháp tốt nhất cho việc này.

Trong công việc của tôi, chúng tôi sử dụng cả ba giải pháp sau đây:

1) Áp dụng một kiểm tra mã phong cách như xuất sắc Checkstyle (cho Java) hoặc StyleCop (đối với C #). Đây là những công cụ được cấu hình dễ dàng có thể tự động làm nổi bật độ lệch quy tắc / quy tắc mã hóa. Nó cung cấp cho mọi người một bên thứ 3 trung lập để xác định những gì được và không được chấp nhận.

2) Thông qua mẫu mã định dạng lại tự động lưu (đây là ví dụ sử dụng Eclipse) (và một mẫu khác cho Visual Studio) sẽ tự động định dạng mã của bạn khi lưu. Điều này thật tuyệt khi cho phép ai đó viết mã theo cách họ muốn, nhưng có tất cả các mã được định dạng theo cùng một cách trên save / commit. Tôi thực sự thích cái này và mã của chúng tôi chưa bao giờ nhất quán hơn.

3) Mã đánh giá. Hy vọng rằng dù sao bạn cũng đang làm những việc này, nhưng một điều cần làm nổi bật là nơi các quy tắc / phong cách mã hóa đang phá vỡ quy ước.

Ngoài những điều trên, điều quan trọng là tất cả mọi người đều ở trên cùng một chiếc thuyền và đã đồng ý các phong cách / quy tắc mà họ đang làm việc hướng tới. Hãy nói rõ rằng bạn sẽ không nhận được sự đồng ý từ mọi người về mọi thứ, nhưng hãy yêu cầu sự cam kết từ nhóm để giữ đúng với những gì nhóm quyết định. Hãy chắc chắn thỉnh thoảng xem lại các phong cách / quy tắc được chọn để giải thích cho trải nghiệm trong thế giới thực bằng cách sử dụng chúng và chuyển đổi nhóm.

Vấn đề thực sự xuất phát từ vấn đề này là làm thế nào để khiến những người khó tính không muốn sử dụng dấu ngoặc trong câu lệnh if hoặc sử dụng cùng một chuỗi kết nối ở mọi nơi trong mã, hoặc bất cứ điều gì,

Có phải họ đang "cứng đầu" khi không sử dụng dấu ngoặc hay đây là một yêu cầu "cứng đầu"?

Chọn trận đấu của bạn. Tôi nghi ngờ đây là một trong những người đáng để chọn. Tôi sẽ không thích làm việc ở bất cứ nơi nào mong đợi ở bất kỳ nơi nào gần mức chi tiết này về "mã đăng ký đầu tiên". Đây là một chỉ báo cờ đỏ mà nhóm không hiểu tái cấu trúc.

OO 101 : "Tái cấu trúc khi sản phẩm làm những gì nó cần làm". Không phải trước đây.

Thật khó khăn khi ngồi trên vai của mỗi nhà phát triển trong các nhóm lớn, đảm bảo họ đặt niềng răng ở nơi bạn nghĩ họ nên đến - hãy tin tôi vào điều đó;).

Nếu đó là thứ bạn thực sự cảm thấy đang cản trở sự phát triển của bạn, thì bạn sẽ cần một "người gác cổng". Đừng để mọi người đăng ký mà không xem xét mã chẳng hạn. Yêu cầu kiến ​​trúc sư kỹ thuật hoặc trưởng nhóm xem xét mã và từ chối mã cho đến khi họ "sửa" kiểu mã. Họ sẽ sớm cảm thấy mệt mỏi với điều này và điều chỉnh theo các quy tắc, tuy nhiên, có thể chỉ miễn là họ đang được kiểm tra.

Tất nhiên, một số công ty lấy đi đặc quyền check-in hoàn toàn từ các lập trình viên cơ sở. Khi cuối cùng họ học các quy tắc mã hóa của công ty, sau đó họ có được đặc quyền.

Tôi nghĩ rằng bạn đang nói về các vấn đề ở các cấp độ rất khác nhau:

làm thế nào để khiến những người khó tính không muốn sử dụng dấu ngoặc trong câu lệnh if,

Đó chủ yếu là một vấn đề về phong cách / khả năng đọc, trừ khi có một vấn đề ưu tiên toán tử rõ ràng. Cái sau không nên rất phổ biến, và dù sao cũng có thể kiểm tra được đơn vị, do đó dễ sửa chữa. Cái trước có thể dễ dàng thoái lui vào một cuộc Chiến Thánh với rất ít để đạt được, nhưng hậu quả tiêu cực nghiêm trọng đối với tinh thần đồng đội. Vì vậy, hãy cẩn thận - chỉ đẩy các quy tắc đã được thử và thử nghiệm, đã được ít nhất một số nhóm / cộng đồng chấp nhận và được chứng minh là có hiệu quả.

hoặc sử dụng cùng một chuỗi kết nối ở mọi nơi trong mã,

Nếu bạn có nghĩa là Hằng số ma thuật, đó thực sự là một vấn đề về bảo trì (cộng với khả năng bảo mật) và như vậy IMHO, bất kỳ nhà phát triển dày dạn nào cũng sẽ hiểu và chấp nhận rằng đó là một điều xấu.

hoặc bất cứ điều gì, để sử dụng các quy tắc mã hóa mà không làm cho chúng phản đối ý tưởng?

Bạn không thể buộc mọi người đồng ý với bất kỳ quy tắc mã hóa nào - cơ hội duy nhất của bạn là tìm hiểu và mua chung từ các thành viên trong nhóm thông qua thảo luận và tranh luận (đôi khi gay gắt) . Bạn cần sử dụng các lập luận hợp lý và thuyết phục , thể hiện giá trị đằng sau mỗi quy tắc và giải thích cách tuân theo quy định này sẽ trả tiền cho sự bất tiện của việc điều chỉnh thói quen ăn sâu. Mặt khác, cố gắng thực hiện quá trình chuyển đổi dễ dàng nhất có thể , bằng cách giới thiệu định dạng mã tự động khi nhận phòng, theo các quy tắc được chấp nhận.

Tuy nhiên, đôi khi bạn chỉ cần chấp nhận rằng mọi người có ý kiến ​​khác nhau , do đó các quy tắc mã hóa mà mọi người có thể chấp nhận sẽ được khoan dung trong một số khía cạnh nhất định. Chấp nhận điều đó và tập trung vào các lĩnh vực mà bạn có thể cải thiện mọi thứ với ít nỗ lực hơn.

Để họ tham gia vào việc thiết lập các quy tắc. Điều này thường giúp khuyến khích mọi người theo dõi họ.

Đây là những gì mã đánh giá là dành cho. Người đánh giá mã không được để mã vượt qua mà không đáp ứng các tiêu chuẩn. Đảm bảo không thư giãn các quy tắc cho các sửa chữa khẩn cấp. Phải làm lại một vài lần dưới áp lực để hoàn thành nó sẽ sửa chữa những người miễn cưỡng làm công việc của họ ngay lần đầu tiên.

Chuỗi kết nối giống nhau ở mọi nơi? Giải pháp cho vấn đề đó là tái cấu trúc cho đến khi bạn loại bỏ tất cả các bản sao. Các lập trình viên sao chép-dán nên vào nhà tù lập trình viên. (Đừng cười! Steve Ballmer là quản giáo.)

Nhưng vấn đề thực sự ở đây là động từ "make" của bạn . Bạn không thể khiến các lập trình viên làm bất cứ điều gì, và nếu bạn làm thế, bạn đang lãng phí đặc tính quý giá nhất của họ: sự gắn kết trí tuệ sâu sắc đến từ việc làm việc trên một thứ gì đó mà bạn quan tâm.

Cách tôi giải quyết nó:

1. Khăng khăng rằng nhóm có một tiêu chuẩn mã hóa chung. Nó có thể dài 5 dòng, nhưng tất cả đều phải đồng ý.
2. Mỗi khi bạn nhận thấy một đối số khẳng định họ giải quyết nó cùng nhau và đưa nó vào tiêu chuẩn mã hóa. Nếu bạn nhận thấy mọi người định dạng lại mọi thứ qua lại, hãy coi đó là một cuộc tranh luận.
3. Bất cứ khi nào một mục tiêu chuẩn được thỏa thuận, hãy xem liệu có một công cụ sẽ dọn sạch toàn bộ mã cơ sở cùng một lúc không.
4. Cứ sau vài tháng, trải qua tiêu chuẩn mã hóa và xem cái nào vẫn đúng và phù hợp. Các tiêu chuẩn chỉ là tài liệu những gì mọi người đang làm. Và không có điểm nào trong việc giữ các mục trong tiêu chuẩn đã trở nên rõ ràng.

Lập trình là một môn thể thao đồng đội, hoặc một tác phẩm nghệ thuật tập thể. Những gì mọi người đồng ý không quan trọng bằng việc họ đồng ý và rất giỏi trong việc đi đến các thỏa thuận mới khi cần thiết.