Xử lý các tiêu chuẩn mã hóa tại nơi làm việc (Tôi không phải là ông chủ)


40

Tôi làm việc trong một nhóm nhỏ, khoảng 10 dev. Chúng tôi không có tiêu chuẩn mã hóa nào cả. Có một số điều đã trở thành chuẩn mực nhưng một số cách làm việc hoàn toàn khác nhau. Cái lớn của tôi là thụt. Một số sử dụng các tab, một số sử dụng không gian, một số sử dụng một số lượng không gian khác nhau, điều này tạo ra một vấn đề lớn. Tôi thường kết thúc với xung đột khi hợp nhất vì ai đó đã sử dụng IDE của họ để tự động định dạng và họ sử dụng một ký tự khác để thụt lề so với tôi. Tôi không quan tâm chúng ta sử dụng cái gì, tôi chỉ muốn tất cả chúng ta sử dụng cùng một thứ.

Nếu không, tôi sẽ mở một tệp và một số dòng có dấu ngoặc nhọn trên cùng một dòng với điều kiện trong khi các dòng khác có chúng ở dòng tiếp theo. Một lần nữa, tôi không bận tâm cái nào miễn là chúng giống nhau.

Tôi đã đưa ra vấn đề về tiêu chuẩn cho người quản lý trực tiếp của mình, từng người một và trong các cuộc họp nhóm, và anh ta không quá quan tâm đến vấn đề này (có một số người khác có cùng quan điểm với tôi). Tôi đã đưa ra mối quan tâm cụ thể của mình về các nhân vật thụt đầu dòng và anh ấy nghĩ rằng một giải pháp tốt hơn sẽ là "tạo ra một loại kịch bản có thể chuyển đổi tất cả những gì khi chúng tôi đẩy / kéo từ repo." Tôi nghi ngờ rằng anh ta không muốn thay đổi và giải pháp này có vẻ quá phức tạp và dễ xảy ra sự cố bảo trì (cũng vậy, điều này chỉ giải quyết một biểu hiện của một vấn đề lớn hơn).

Có ai trong số các bạn gặp phải tình huống tương tự tại nơi làm việc không? nếu vậy, bạn đã giải quyết nó như thế nào? Điều gì sẽ là một số điểm tốt để giúp bán sếp của tôi theo tiêu chuẩn? Sẽ bắt đầu một phong trào rễ cỏ để tạo ra các tiêu chuẩn mã hóa, trong số những người trong chúng ta quan tâm, có phải là một ý tưởng tốt? Có phải tôi quá đặc biệt, tôi có nên để nó đi không?

Cảm ơn bạn đã dành thời gian cho tôi.

Lưu ý: Cảm ơn tất cả mọi người cho các phản hồi tuyệt vời cho đến nay! Để rõ ràng, tôi không muốn ra lệnh Một Phong cách để cai trị tất cả. Tôi sẵn sàng thừa nhận cách ưa thích của tôi để làm một cái gì đó có lợi cho những gì phù hợp nhất với mọi người. Tôi muốn sự nhất quán và tôi muốn đây là một nền dân chủ. Tôi muốn nó là một quyết định nhóm mà mọi người đồng ý. Đúng, không phải ai cũng sẽ đi theo con đường của mình, nhưng tôi hy vọng rằng mọi người sẽ đủ trưởng thành để thỏa hiệp vì sự tiến bộ của nhóm.

Lưu ý 2: Một số người đang bị cuốn vào hai ví dụ tôi đã nêu ở trên. Tôi là nhiều hơn sau khi trung tâm của vấn đề. Nó biểu hiện bằng nhiều ví dụ: quy ước đặt tên, các chức năng lớn cần được chia nhỏ, nên sử dụng một dịch vụ hoặc sử dụng, nên là một hằng số hoặc được tiêm, tất cả chúng ta nên sử dụng các phiên bản khác nhau của một phụ thuộc hoặc giống nhau, nên giao diện được sử dụng cho trường hợp này, nên thiết lập thử nghiệm đơn vị như thế nào, nên thử nghiệm đơn vị nào, (cụ thể Java) chúng ta nên sử dụng chú thích hoặc cấu hình bên ngoài. Tôi có thể tiếp tục.


3
Một số công cụ hợp nhất cung cấp tùy chọn bỏ qua các khoảng trắng khác nhau. Nó sẽ không giải quyết được nguyên nhân gốc rễ, nhưng có thể giảm bớt cơn đau trung gian ...
Thất vọngWithFormsDesigner

5
Tại sao bạn không thích giải pháp định dạng mã của người quản lý khi mã này được đẩy sang kiểm soát nguồn?
Larry Coleman

5
Tôi nghĩ rằng đây là một vấn đề xã hội, không phải là một vấn đề kỹ thuật. Nếu nhóm không thể đồng ý về các tiêu chuẩn, IMO sẽ không có công nghệ nào có thể giúp được.
Bryan Oakley

11
MỌI NGƯỜI nên sử dụng tính năng tự động định dạng IDE với cùng các cài đặt. Cứ làm đi.

1
@ Thorbjørn - Đồng ý. Chúng tôi vừa ban hành cài đặt IDE toàn cầu ngày hôm qua.
Adrian J. Moreno

Câu trả lời:


73

Một đồng nghiệp và tôi đã gặp vấn đề tương tự trong đội của chúng tôi khi chúng tôi mới tham gia (Tôi gia nhập đội trước, anh ấy tham gia khoảng một năm sau). Không có tiêu chuẩn mã thực sự. Chúng tôi là một cửa hàng MS và thậm chí các tiêu chuẩn mã hóa MS không được sử dụng. Chúng tôi quyết định dẫn đầu bằng ví dụ. Chúng tôi ngồi lại với nhau và phác thảo một tài liệu có tất cả các tiêu chuẩn của chúng tôi: tiêu chuẩn IDE, tiêu chuẩn đặt tên, mọi thứ chúng tôi có thể nghĩ ra. Sau đó, anh và tôi đồng ý tuân theo tiêu chuẩn một cách rõ ràng. Tôi đã gửi email cho nhóm (từ cả hai chúng tôi) và thông báo cho họ rằng chúng tôi đã tìm thấy sự thiếu sót và chúng tôi sẽ giải quyết vấn đề thiếu với tài liệu của chúng tôi. Chúng tôi mời các nhà phê bình, ý tưởng, ý kiến, ý kiến. Chúng tôi đã nhận được rất ít theo cách phản hồi và chỉ một chút đẩy lùi. Anh ấy và tôi ngay lập tức bắt đầu sử dụng các tiêu chuẩn, và khi chúng tôi đưa các nhà phát triển cơ sở vào các dự án của mình, chúng tôi đã giới thiệu cho họ tiêu chuẩn và họ bắt đầu sử dụng nó. Chúng tôi có một vài khách hàng tiềm năng ban đầu miễn cưỡng nhưng đã dần bắt đầu sử dụng tiêu chuẩn cho rất nhiều thứ.

Chúng tôi thấy rằng nhiều nhà phát triển cơ sở đã nhận ra vấn đề tương tự nhưng đang chờ người khác bước lên và đưa ra quyết định. Một khi đã có kế hoạch để thực hiện, nhiều người đã háo hức chấp nhận nó. Các loại hạt cứng để bẻ khóa là những người từ chối mã hóa bằng bất kỳ phương tiện nào khác, và họ thường sẽ tự mã ra khỏi hình ảnh trong thời gian dài.

Nếu bạn muốn tiêu chuẩn, rực sáng con đường. Hãy đưa ra một danh sách đề xuất các tiêu chuẩn mà bạn nghĩ sẽ có lợi cho nhóm của bạn. Gửi cho đồng nghiệp và khách hàng tiềm năng để phản hồi. Tôi chắc rằng những người khác trong nhóm của bạn cũng có ý tưởng tương tự, nhưng có lẽ họ thiếu suy nghĩ để làm bất cứ điều gì về nó. Như Gandhi đã nói, "Bạn phải là sự thay đổi mà bạn muốn thấy trên thế giới."


4
Tôi thích ý tưởng bắt đầu trong số những người đồng ý! Tôi muốn nói thêm rằng bạn càng dễ dàng tìm kiếm và tuân theo các tiêu chuẩn, mọi người sẽ càng làm như vậy - đảm bảo rằng nếu bạn có các công cụ định dạng IDE, các hướng dẫn thiết lập và mọi tệp cấu hình đều dễ tìm thấy và cài đặt được ghi lại tốt.
bethlakshmi

1
Nói tóm lại, hãy giữ bản thân theo một tiêu chuẩn trước khi bạn mong đợi những người khác được giữ cùng tiêu chuẩn. Bắt đầu bằng cách xác định những gì hầu hết các nhà phát triển nhóm của bạn đang sử dụng và đặt môi trường của bạn để làm điều đó.
Freiheit

2
+1 Đây chính xác là cách chúng tôi đã xử lý tình huống tương tự. Tôi đã thấy rằng việc dẫn đầu bằng ví dụ thường khắc phục nhiều vấn đề trong một cửa hàng phát triển - nhưng bạn phải có được sự mua lại từ những người khác. Nếu bạn là người duy nhất rạo rực con đường thì có lẽ bạn nên đánh giá lại con đường đó ngay từ đầu.
Jduv

1
Joel, câu chuyện này đã truyền cảm hứng cho đồng nghiệp của tôi và tôi. Chúng tôi đang nhặt ngọn đuốc bằng cách sử dụng câu chuyện của bạn làm mẫu.
Josh Johnson

Tôi đồng ý một phần với bạn bắt đầu với một người đồng ý, nhưng tôi không đồng ý với "Chúng tôi đã ngồi lại với nhau và soạn thảo một tài liệu", nhà phát triển không nên làm điều này thay vì sử dụng một công cụ. Bạn có thể sử dụng chia sẻ lại hoặc người giúp việc mã thay thế miễn phí, bạn có thể buộc nó định dạng lại mã của bạn mỗi khi bạn lưu tệp. Dù sao, tôi đã làm việc cho công ty buộc tiêu chuẩn mã hóa đến mức điên rồ như phương pháp sắp xếp theo bảng chữ cái, nhóm trường theo loại và sử dụng khu vực. nó làm tôi mất cảm giác như đang lãng phí một nửa thời gian của mình.
cỏ

6

Các tiêu chuẩn không nên là một cái gì đó được xác định và thi hành bởi người quản lý. Nhóm nghiên cứu nói chung nên đồng ý với các tiêu chuẩn. Nếu họ không thể đồng ý về một bộ tiêu chuẩn chung, việc người quản lý buộc các tiêu chuẩn theo họ sẽ thất bại.

Bạn và những người khác đồng ý với bạn nên dẫn dắt bằng ví dụ. Bắt đầu sử dụng các tiêu chuẩn mã hóa tương tự, xuất bản chúng và quảng bá chúng cho các thành viên còn lại trong nhóm và mời phản hồi về cách cải thiện chúng.

Đây là một chút quan trọng khi cố gắng thúc đẩy các tiêu chuẩn: đảm bảo trọng tâm không phải là tìm ra cách tốt nhất để làm mọi việc, mà là tìm ra một cách làm việc nhất quán . Nhiều người có thể không đồng ý, không có một kiểu niềng răng thực sự, không có một kiểu nhận xét đúng, v.v. Điều gì làm cho mã dễ đọc hơn (và do đó, dễ duy trì hơn) là một phong cách nhất quán, bất kể đó là gì.


4
Tôi đồng ý rằng nhóm cần xác định các tiêu chuẩn nhưng lý tưởng nhất là người quản lý nên là người thực thi. Nếu bạn không mua từ người quản lý trên toàn bộ ý tưởng về việc có các tiêu chuẩn mã hóa, bạn nên xem xét tự mình đảm nhận vai trò lãnh đạo đó (xem câu trả lời của Joel Etherton).
semaj

3
Vâng về mặt kỹ thuật có một One True Brace Kiểu: en.wikipedia.org/wiki/Indent_style#Variant:_1TBS
Khôi phục Monica

@semaj: Tôi hết lòng không đồng ý. Nó không nên phụ thuộc vào người quản lý. Thậm chí không một chút.
Bryan Oakley

Mặt khác, bạn là một nhóm lập trình, nhân viên của ai đó, không phải là một người hippie. Đầu cuộn của ai nếu dự án thất bại? Tôi đảm bảo ai đó làm. Nếu mọi người có trách nhiệm, thì không có ai . Xem cái này , cái này , cái này , v.v.
Craig

"Ai lăn đầu," ý tôi là. Rõ ràng ...
Craig

5

Bạn có thể cho thấy một số bằng chứng về thời gian bạn đã lãng phí do những vấn đề này gây ra không?

Nếu bạn đang dành một lượng thời gian đáng kể để khắc phục những vấn đề này hoặc nó gây ra lỗi cần thời gian để khắc phục, thì đây là chi phí bạn có thể giảm đáng kể bằng cách áp dụng các tiêu chuẩn mã hóa.

Vì vậy, hãy ghi lại những vấn đề bạn gặp phải và thời gian cần thiết để giải quyết chúng - cả cho bạn và (nơi bạn nhận thức được chúng) các đồng nghiệp của bạn.

Sau đó, khi bạn đã có một lượng dữ liệu hợp lý trình bày nó cho các đồng nghiệp của bạn. Họ sẽ thấy lợi ích của việc áp dụng một tiêu chuẩn. Nếu không hiển thị dữ liệu cho sếp của bạn và sếp của anh ấy. Cho thấy rằng bằng cách có các tiêu chuẩn mã hóa, bạn có thể tiết kiệm tiền cho công ty của mình và họ sẽ hỗ trợ bạn trong việc nhận chúng.


3

Về tình huống cụ thể của bạn, tôi nghĩ giải pháp của sếp là một giải pháp tốt. Không ai phải thay đổi những gì họ đã làm cho toàn bộ sự nghiệp của mình và điều đó không sao vì các bit của kiểu mã mà trình biên dịch bỏ qua không quan trọng miễn là mã có thể đọc được. Nếu mọi người đã tự động định dạng theo phong cách của họ khi kiểm tra và tự động định dạng theo kiểu chuẩn khi đăng ký, tất cả sẽ ổn. (Đáng buồn là tôi đã đề xuất rằng nơi tôi làm việc và nó đã bị phản đối với lý do rằng người viết mã sẽ không còn viết mã chính xác như máy chủ tích hợp liên tục nhìn thấy.)

Tôi nghĩ rằng các tiêu chuẩn mã hóa là tốt khi áp dụng cho những nơi tạo ra sự khác biệt thực sự về chất lượng mã: ví dụ: các phương thức nhỏ, các lớp có trách nhiệm được nêu rõ ràng, nhận xét hữu ích và chính xác cho các bit khó hơn, v.v. Thật không may, các khía cạnh đó khó tự động kiểm tra hơn, nhưng đó là nền tảng cho phát triển phần mềm. Tất cả những gì bạn thực sự có thể làm là dạy cho người khác những thực hành tốt và dạy bản thân đọc mã với cú đúp trên dòng sai.


3
Tôi ổn với cú đúp trên bất cứ dòng nào. Tôi bị loại bỏ khi cả hai phong cách trong cùng một tập tin. Làm cho nó khó khăn hơn để quét.
Josh Johnson

Nó làm tôi phát điên Nhưng vì tôi không thể định dạng lại chính xác toàn bộ cơ sở mã, tôi chỉ cố gắng xử lý nó cho đến khi tôi có thể thúc đẩy một giải pháp tự động.
jprete

2

Về các tiêu chuẩn mã hóa: Tôi sẽ leo lên tàu với hầu hết mọi người khác để nói rằng các tiêu chuẩn mã hóa là một "điều tốt" (so với không có tiêu chuẩn).

Tuy nhiên, đừng mang đi. Tôi đã làm việc trên một số dự án chỉ ra một kiểu thụt đầu dòng cụ thể, ngay đến số lượng ký tự (và khi các dự án đi xa đến mức đó, chắc chắn họ sẽ chọn thứ gì đó ngu ngốc như 8 chỗ thụt lề). Đừng đổ mồ hôi những thứ nhỏ nhặt.

Một giải pháp đơn giản: Cung cấp cho các nhà phát triển một bộ lựa chọn giới hạn cho nẹp và thụt, nhưng chỉ ra rằng kiểu nẹp và thụt phải nhất quán trong một mô-đun. (Bạn có muốn foo.h và foo.cpp theo cùng một phong cách không?) Người bảo trì phải thích nghi với phong cách hiện có; họ không thể viết lại một mô-đun cho phù hợp với phong cách hay thay đổi của họ. Nhiều kiểu trong một mô-đun chỉ gây nhầm lẫn và là dấu hiệu của sự chậm chạp. Khi tôi thấy điều đó vô nghĩa, nó làm cho tôi tự hỏi những gì khác là sai.

Bạn cũng có thể muốn nghĩ về việc cấm các tab để thụt lề trong nội dung đã lưu của một tệp . Hầu hết các IDE / biên tập viên thực hiện công việc hợp lý khi dịch các tab đầu vào của người dùng sang không gian và hầu hết đều có các tùy chọn để thực hiện bản dịch đó tự động. Nhiều người làm một công việc nhảm nhí khi tệp đã chứa các tab, đặc biệt là một túi hỗn hợp các tab và dấu cách.

Tất cả những gì đã nói, tôi nghĩ rằng bạn có thể có một vấn đề sâu sắc hơn trong dự án của bạn. Bạn đã đề cập đến vấn đề sáp nhập. Nếu bạn thấy mình cần phải thực hiện nhiều việc hợp nhất thì đó có thể là dấu hiệu của việc phân vùng dự án không tốt. Cũng như quá nhiều đầu bếp làm hỏng nước dùng, quá nhiều lập trình viên hoạt động trên cùng một tệp làm hỏng dự án. Tại sao mỗi Joe, Susie và bạn chạm vào foo.cpp?


3
Hoặc bạn chỉ có thể sử dụng các tab và các nhà phát triển riêng lẻ có thể biến chúng thành bất kỳ kích thước nào họ muốn ..
Phục hồi lại

1
@Brendan: Theo kinh nghiệm m không hoạt động. Các lập trình viên không tránh khỏi trộn các tab và không gian để có được mã của họ để xếp hàng chỉ để , đặc biệt là tiếp tục dòng. Không gian chế độ hỗn hợp và rác tab có thể trông hết sức xấu xí với một cài đặt khác cho các tab so với cài đặt được sử dụng bởi nhà phát triển.
David Hammen

2
Tôi không bao giờ nói để trộn chúng. Chỉ sử dụng các tab. Bây giờ thụt lề trông tuy nhiên mỗi dev muốn nó. Nếu bạn thực sự cần mã của mình để xếp hàng "vừa phải", thì vẫn sử dụng các tab để thụt lề, và sau đó khoảng trắng sau đó để sắp xếp mã (tôi coi đây là một sự lãng phí thời gian).
Phục hồi Monica

2
Đó là không gian sau đó giết chết ý tưởng này. Quy tắc "không có tab trong tệp nguồn" là phổ biến trên nhiều, nhiều tiêu chuẩn mã hóa. Có một lý do cho nó.
David Hammen

1

Đây là một trong những lĩnh vực mà một số nghiên cứu được thực hiện. Về cơ bản câu hỏi chính là liệu bạn đang thực hiện đánh giá mã. Đánh giá mã chắc chắn là phương tiện hiệu quả nhất để cải thiện chất lượng mã. (Nguồn: Viện Kỹ thuật phần mềm, CMU). Nó chắc chắn hiệu quả hơn một thử nghiệm thêm.

Bây giờ, đánh giá mã được hưởng lợi từ một tiêu chuẩn mã hóa phổ biến, vì điều đó giúp đọc mã người khác dễ dàng hơn. Điều đó cung cấp cho bạn một đối số hai bước để giới thiệu các tiêu chuẩn mã hóa: cuối cùng, nó làm cho nó rẻ hơn để sản xuất mã tốt.


1

Vì đã có "một vài người khác" đi cùng bạn về vấn đề này, tôi sẽ đề nghị một cuộc họp đầy ngẫu hứng. Mời tất cả các nhà phát triển, dành một chút thời gian và tìm hiểu những điều đang làm phiền chính bạn và đồng nghiệp của bạn hàng ngày. Đừng cố gắng tìm giải pháp cụ thể lúc đầu, chỉ cần tìm ra những gì cần thay đổi theo cách hiện tại bạn đang viết mã.

Sau đó, xem nếu tất cả các bạn có thể đồng ý về một số khái niệm cơ bản. Đề xuất sử dụng cùng một kiểu trong mỗi mô-đun mà @David Hammen đưa ra là một khởi đầu tốt và tôi nghĩ rằng hầu hết các nhà phát triển có thể dễ dàng đồng ý.

Nếu, một khi bạn có điều đó, bạn cảm thấy rằng tất cả các bạn có thể đồng ý về một số phong cách cơ bản khi viết mã mới, đó là một bổ sung tốt. Tập trung vào những thứ thực sự tác động đến khả năng bảo trì; vấn đề đặt tên sẽ rất cao trong danh sách cá nhân của tôi bởi vì nếu bạn có nửa tá kiểu đặt tên khác nhau trong một sản phẩm có độ phức tạp đáng chú ý, nó sẽ nhanh chóng trở thành vấn đề đau đầu, nhưng một lần nữa, hãy tập trung vào những gì bạn và nhóm của bạn cảm thấy quan trọng . Soạn thảo một tài liệu ngắn mà mọi người ít nhất có thể đồng ý tuân theo (ngay cả khi họ có thể có một kiểu thú cưng khác) và gửi nó cho mọi người trong nhóm. Làm cho nó trở thành một tài liệu "sống", đảm bảo cập nhật nó theo thời gian, nhưng hãy chắc chắn không làm cho nó quá cứng nhắc và cụ thể.

Trừ khi ông chủ của bạn có liên quan đến việc viết mã, anh ta không nên lo lắng quá nhiều về phong cách chính xác nào được thông qua (với điều kiện là nó tập trung vào khả năng đọc và duy trì), nhưng anh ta có thể thấy lợi ích của mọi người trong nhóm theo một phong cách chung khi viết mã.


1

Có một số điều đau đớn. Đau đớn nhất là một IDE tự động định dạng lại mã, kết hợp với các nhà phát triển thiết lập IDE của họ theo những cách khác nhau. Mỗi lần bạn so sánh mã, bạn có hàng trăm thay đổi sau khi ai đó có các cài đặt khác nhau chỉnh sửa mã. Điều đó không thể chấp nhận được. Tại đây, bạn cần đập đầu mọi người lại với nhau, đồng ý về một bộ cài đặt và từ chối mọi đăng ký của bất kỳ ai sử dụng các cài đặt khác nhau. Nếu tôi thay đổi một dòng mã, các khác biệt sẽ hiển thị một dòng mã duy nhất đã thay đổi chứ không phải hàng trăm.

Mọi thứ khác đều vô hại, hoặc có những cách tốt hơn để làm những việc mà người khác có thể bị thuyết phục. Ở đây quy tắc nên là: Đừng gây rối với mã của người khác trừ khi bạn thực sự cải thiện nó. Và sự pha trộn giữa phong cách A và phong cách B luôn tệ hơn cả phong cách A hoặc phong cách B.

Hãy chắc chắn rằng bạn làm theo thực hành tốt nhất. Đó là khác nhau cho mỗi ngôn ngữ. Nhưng ở đó bạn không cần các tiêu chuẩn (có thể được viết bởi một người có ý nghĩa tốt nhưng thực sự không phải là người hiểu biết), nhưng mọi người nên cố gắng đưa ra các ví dụ tốt.

Chắc chắn tránh các cuộc đấu tranh quyền lực. Không có gì tệ hơn một số Hitler nhỏ bé trong nhóm của bạn đang cố gắng ép buộc mọi người theo ý mình. Và thật không may, anh chàng sẽ tình nguyện viết tiêu chuẩn mã hóa của bạn :-(


Các tiêu chuẩn khác nhau từ các nhà phát triển khác nhau trong cùng một dự án dẫn đến rụng tóc. Tạo các thiết lập tiêu chuẩn cho dự án. Có mỗi dev nhập các cài đặt đó. Giai đoạn. Điều này thật dễ dàng với các công cụ như Visual Studio IDE. Nếu bạn có những nhà phát triển khăng khăng sử dụng Emacs (mà tôi thích rất nhiều, bản thân tôi) hoặc bất cứ điều gì, họ có trách nhiệm tuân thủ tiêu chuẩn. Sử dụng một thói quen in ấn đẹp để định dạng lại mã để đăng ký. Mục tiêu là mã thống nhất giúp mọi người dễ hiểu, không phải phong cách nghệ thuật riêng lẻ trong các tệp mã nguồn riêng lẻ của mọi người.
Craig

0

Tất cả các ví dụ bạn đã đưa ra về cơ bản là về khoảng trắng và định dạng. Nếu đó là vấn đề lớn nhất, tôi đồng ý với người quản lý của bạn: đó không phải là vấn đề lớn.

Nơi các tiêu chuẩn thực sự rất hữu ích là với việc đặt tên mọi thứ và giảm độ phức tạp. Làm thế nào để đặt tên định danh, lớp, nơi đặt chúng, vv Giữ cho tên nhất quán là vô cùng quan trọng, đặc biệt là trong một dự án lớn. Các quy tắc để giảm độ phức tạp bao gồm giữ các hàm theo một số dòng nhất định (chia nó thành các hàm nhỏ hơn) hoặc giữ các danh sách tham số bên dưới một số đối số nhất định (có thể bạn nên kết hợp chúng vào một đối tượng và chuyển xung quanh đó).

Nếu một nhà phát triển cụ thể trong nhóm của bạn viết mã khó hiểu / gỡ lỗi hơn vì nó bao gồm rất nhiều đoạn mã dài với các tên biến đơn, đó là lý do chính đáng để áp dụng một số tiêu chuẩn và không phải là thứ có thể sửa được một kịch bản. Đó là một điều tốt để chỉ ra (một cách khéo léo) như là một điều mà các tiêu chuẩn có thể cải thiện.

Một lý do khác khiến người quản lý của bạn có thể không coi đó là vấn đề là bạn thực sự không đọc mã của nhau. Điều đó có thể xảy ra khi mọi người đều có vùng mã riêng và không mạo hiểm bên ngoài nó quá nhiều. Điều đó hoạt động khá tốt cho đến khi ai đó rời khỏi tổ chức, điều này có thể xảy ra vì nhiều lý do tốt hoặc xấu. Các tiêu chuẩn giúp dễ đọc sẽ giúp nhà phát triển mới dễ dàng hơn trong việc bảo trì một đoạn mã.


0

xung đột khi tôi hợp nhất vì ai đó đã sử dụng IDE của họ để tự động định dạng và họ sử dụng một ký tự khác để thụt lề so với tôi

Nghe có vẻ như đây là vấn đề của bạn, không phải định dạng, mà là định dạng lại. Đây là một vấn đề lớn đối với SCM và lời khuyên rất đơn giản: đừng làm điều đó. Vì vậy, lần tới khi ai đó định dạng lại tất cả các khoảng trắng thành tab hoặc tái cấu trúc dấu ngoặc nhọn thành kiểu ưa thích của họ, bạn cần phải đặt chúng xuống. Thay vào đó hãy làm cho chúng hợp nhất; đứng trên họ trông không tán thành sự lãng phí thời gian mà sự thiếu suy nghĩ của họ đã gây ra.

Cách khác là đặt một bộ định dạng cam kết trước, luôn định dạng lại tất cả mã theo kiểu chuẩn trước khi đăng ký. Nếu bạn có một nhóm các nhà phát triển định dạng lại như một vấn đề tất nhiên, thì đây là một lựa chọn tốt - SCM sẽ luôn thấy định dạng tương tự, do đó, các đồng bằng sẽ nhỏ và đẹp để hợp nhất.


0

Khi ai đó đề xuất một tiêu chuẩn mã hóa mới nơi tôi làm việc, chúng tôi sẽ bỏ phiếu cho nó. Nếu nó được đa số phiếu thì nó được chấp nhận nếu không nó bị từ chối. Nếu bạn không làm điều này, bạn sẽ không được mua theo tiêu chuẩn của mình và chúng sẽ không được sử dụng ngay cả khi chúng được ghi lại.


0

Đối với vấn đề cụ thể của bạn, đặt cược tốt nhất của bạn có thể sẽ bắt đầu với đề xuất của Joel và dẫn đầu bằng ví dụ. Tập hợp 1 hoặc 2 lập trình viên quan tâm đến vấn đề này, đi đến một thỏa thuận và bạn sẽ có một số lực lượng để áp đặt lên những người lười biếng.

Bây giờ, đối với vấn đề chung, tôi thấy tốt nhất chỉ cần điều chỉnh . Mỗi người có một tệp khác nhau, nếu bạn phải bảo trì một tệp bạn giữ nguyên các tiêu chuẩn mã hóa của nó, ngay cả khi nó khác với các tệp khác. Cần phải viết trong cùng một tập tin? Tạo một tập hợp con và bao gồm nó thay thế.


0

Đừng thử điều này!

Dẫn bằng ví dụ truy cập. Cố gắng làm cho định dạng mã của bạn trở nên khủng khiếp nhất có thể và kiểm tra nhiều thay đổi được định dạng khủng khiếp đối với mã đẹp của người khác. Khi phản ứng (không thể tránh khỏi) xảy ra, hãy nói rằng những gì bạn đang làm là tốt vì không có tiêu chuẩn mã hóa.

Nếu bạn không bị đồng nghiệp làm phiền (!!), bạn có thể kết thúc với một tiêu chuẩn mã hóa.

Rõ ràng, đây là một chiến lược rủi ro cao ... :-)


Trên thực tế, có một vài người đang thử cái này ngay bây giờ và nhiều người đã sử dụng chiến lược này trước khi tôi bắt đầu ở đó. Bất chấp những nỗ lực tốt nhất của họ, cho đến nay vẫn chưa có tiêu chuẩn nào xuất hiện :(
Josh Johnson

@Josh Johnson - rõ ràng là họ đã không cố gắng hết sức. Cân nhắc sử dụng ROT-13 trên tất cả các số nhận dạng :-)
Stephen C
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.