Làm thế nào để thực thi các thực hành kiểm soát mã nguồn tốt / tốt hơn?


28

Tôi nghi ngờ rằng tôi đang tập trung vào vấn đề sai nên trước tiên tôi sẽ mô tả những gì tôi nghĩ vấn đề là trước khi trình bày giải pháp tối ưu có thể có mà tôi hình dung.

Tình huống hiện tại:
Hiện tại các đồng nghiệp của tôi cam kết thay đổi mã của họ chỉ sau một khoảng thời gian loooong trong khối lớn với những thay đổi lan rộng khắp (các) dự án. Tôi đoán đó là tiến bộ, bởi vì cách đây không lâu họ chỉ đưa tài liệu lưu trữ .zip lên một số chia sẻ mạng. Tuy nhiên, sáp nhập là một cơn ác mộng - và thật lòng mà nói tôi đã có đủ rồi. Và tôi cũng mệt mỏi khi nói chuyện và giải thích và cầu xin. Điều này chỉ cần dừng lại - không có tôi liên tục là "kẻ xấu".

Giải pháp của tôi:
Vì dường như không có nhận thức về và / hoặc không quan tâm đến các vấn đề và tôi không thể mong đợi bất kỳ nỗ lực nào sẽ kéo dài hơn một vài ngày ... tấn công rằng, hàng giờ, tôi muốn máy chủ lật đổ thực hiện cằn nhằn.

Câu hỏi của tôi:
Tôi đang rời khỏi căn cứ ở đây hay tôi đang nhìn vấn đề sai? Có vẻ như tôi đang thiếu một cái gì đó và tôi nghĩ rằng tôi đã hỏi sai điều đó bằng cách xem các công cụ để giải quyết vấn đề của mình.

Tôi có nên tìm kiếm một công cụ để giải quyết vấn đề này hay tôi nên làm gì để khắc phục vấn đề này?


Không phải những rắc rối họ đã hợp nhất một động lực để họ muốn cải thiện cách họ làm việc sao?
Flosculus

1
Chỉ cần một ý tưởng, làm cho chúng hợp nhất mã;) Nhưng một điều khiến tôi ở SVN không thường xuyên cam kết là, nó mất rất nhiều thời gian so với git chẳng hạn ...
Knerd 16/12/14

5
Ai chịu trách nhiệm giải quyết xung đột sau khi ai đó thực hiện hợp nhất?
Flosculus

Một cách tiếp cận cao về phân nhánh có thể mang lại điều tốt nhất cho cả hai thế giới; nếu bạn đang làm một công việc lớn trên một chi nhánh và thường xuyên sáp nhập chi nhánh chính vào chi nhánh đó (vì vậy tất cả các hợp nhất đều nhỏ) thì cuối cùng khi bạn hợp nhất chi nhánh lại thành chủ, việc hợp nhất là không đáng kể, nhưng trong khi đó bạn vẫn chưa có một trạng thái trung gian trên chủ bị hỏng hoặc không đầy đủ một cách khó hiểu. Nó dễ dàng hơn với một số SCM so với các SCM khác (tùy thuộc vào cách phân nhánh ánh sáng), nhưng nó có thể hoạt động với bất kỳ trong số chúng.
Jon Hanna

Câu trả lời:


47

Bạn đang tìm kiếm một giải pháp kỹ thuật cho một vấn đề của con người. Điều đó hiếm khi hoạt động.

Lý do cho điều đó là bởi vì nếu các thành viên trong nhóm không chấp nhận điều gì đó (cũng không hiểu ý nghĩa), thay vì tuân theo các quy tắc, họ sẽ cố gắng phá vỡ chúng. Đó chính xác là lý do tại sao, ví dụ, các nhà phát triển nên chấp nhận và hiểu các quy tắc về phong cách thay vì chỉ bị buộc phải tuân theo trình kiểm tra.

Dưới đây là một vài cách tiếp cận tôi sử dụng trong quá khứ hoặc có trong tâm trí mà không thực sự có cơ hội với chúng trong thực tế. Một số có thể không áp dụng cho trường hợp của bạn, tùy thuộc vào vị trí bạn có trong nhóm (nếu bạn là trưởng nhóm có danh tiếng xuất sắc, rất có thể bạn sẽ có cơ hội tốt hơn để thực thi quan điểm của mình so với khi bạn là sinh viên đại học chỉ tham gia một nhóm trong suốt thời gian thực tập của bạn).

  1. Thảo luận về vấn đề với đồng nghiệp của bạn và giải thích hậu quả của các cam kết lớn. Có lẽ họ chỉ đơn giản là không hiểu rằng các sự hợp nhất phức tạp là hậu quả trực tiếp của các cam kết hiếm, và hơn các cam kết nhỏ, thường xuyên sẽ làm cho việc hợp nhất (tương đối) trở nên dễ dàng.

    Tôi biết rất nhiều lập trình viên chỉ đơn giản là bị thuyết phục rằng việc hợp nhất luôn phức tạp. Họ đã thực hiện tối đa một cam kết mỗi ngày, tránh sử dụng các công cụ mạnh mẽ như khác biệt và tự động hợp nhất của Visual Studio và thực hiện việc sáp nhập thủ công kém (trừ khi thực hiện kiểm tra khác biệt thực sự là một cách kiểm tra khác biệt). Đối với họ, điều này không liên quan gì đến họ , và là bản chất vốn có của sự hợp nhất.

  2. Đưa ra ví dụ cụ thể về những gì đang xảy ra ở các công ty khác (đặc biệt là những công ty mà đồng nghiệp của bạn rất tôn trọng). Họ có thể đơn giản là không biết rằng đó là một vấn đề, và được thuyết phục rằng một cam kết tối đa mỗi ngày là điều mà mọi đội làm.

    Một số người không biết rằng có những nhóm gồm 5-10 thành viên tạo ra tới 50 lần đẩy vào sản xuất, nghĩa là trung bình 5-10 lần cam kết mỗi ngày cho mỗi người. Họ có thể không hiểu làm thế nào là có thể, và tại sao mọi người sẽ làm điều đó.

  3. Dẫn bằng ví dụ. Làm đủ nhỏ cam kết chính mình. Nếu có thể, hãy thực hiện một bản trình bày ngắn cho thấy sự hợp nhất của họ và của bạn cạnh nhau trong một tuần (Tôi không chắc việc trích xuất loại thông tin này có dễ dàng từ kiểm soát phiên bản hay không). Nhấn mạnh vào những sai lầm cuối cùng mà họ đã mắc phải trong quá trình hợp nhất và so sánh nó với số lỗi bạn đã mắc phải (gần bằng 0).

  4. Sử dụng kỹ thuật mà tôi đã nói với bạn về kỹ thuật, khi thích hợp . Khi bạn thấy các đồng nghiệp của mình phải chịu đựng một sự hợp nhất đau đớn, hãy bình luận lớn rằng những cam kết nhỏ, thường xuyên có thể làm cho việc hợp nhất (tương đối) không gây đau đớn.

  5. Giải thích rằng không có thời lượng tối thiểu để thực hiện một cam kết. Một cam kết thậm chí có thể tương ứng với một thay đổi nhỏ được thực hiện trong vài giây. Đổi tên một tệp, xóa một nhận xét lỗi thời, sửa lỗi chính tả là tất cả các nhiệm vụ có thể được thực hiện ngay lập tức.

    Các lập trình viên không nên sợ thực hiện một cam kết nhỏ, mà nên tổng hợp nhiều thay đổi thành một cam kết lớn.

  6. Làm việc với các cá nhân thay vì một nhóm, khi thích hợp. Nếu có một người đặc biệt từ chối thực hiện các cam kết nhỏ, thường xuyên, hãy nói chuyện riêng với người này để xem tại sao anh ta từ chối.

    Họ có thể đưa ra những lý do hoàn toàn hợp lệ có thể cho bạn gợi ý về những gì đang diễn ra với một đội. Một số lý do tôi đã nghe bản thân mình:

    • Giáo viên / người cố vấn của tôi đã nói với tôi rằng cách tốt nhất là thực hiện một cam kết mỗi ngày. Nó không làm tôi ngạc nhiên, những gì tôi phải nghe từ các giáo viên của mình ở trường đại học .

    • Các đồng nghiệp của tôi đã nói với tôi rằng tôi nên thực hiện ít cam kết hơn. Tôi đã được thông báo điều đó ở một số đội và tôi hiểu quan điểm của họ. Chúng tôi đã có một bản ghi thực tế chứa đầy các cam kết của tôi (không khó thực hiện khi bốn đồng đội thậm chí không thực hiện một cam kết mỗi ngày), điều đó làm các đồng nghiệp của tôi thất vọng.

    • Tôi nghĩ rằng những cam kết nhỏ khiến việc tìm kiếm sửa đổi trở nên khó khăn. Một số điểm hợp lệ, ngay cả khi nhóm nỗ lực viết thông điệp nhật ký mô tả.

    • Tôi không muốn lãng phí quá nhiều dung lượng trên máy chủ kiểm soát phiên bản của chúng tôi. Người đó rõ ràng không hiểu cách thức lưu trữ (cũng như không gian lưu trữ rẻ như thế nào).

    • Tôi nghĩ rằng một cam kết nên tương ứng với một nhiệm vụ cụ thể. Thông thường, một nhiệm vụ tương ứng với một số công việc phải hoàn thành trong một ngày (chẳng hạn như trong bảng nhiệm vụ của quản lý trực quan), đây không phải là sự trùng hợp. Sau đó, người đó nên học cách tạo ra sự khác biệt giữa một nhiệm vụ trong một hồ sơ tồn đọng (2 đến 8 giờ làm việc) và một thay đổi hợp lý cần được cam kết (một vài giây đến vài giờ làm việc). Điều này cũng liên quan đến điểm 5.

  7. Tìm kiếm lý do nhóm không thực hiện cam kết thường xuyên hơn. Bạn có thể ngạc nhiên với kết quả.

    Gần đây, tôi đã đề cập trong một câu trả lời khác rằng tốc độ của một cam kết là vấn đề và thậm chí hàng trăm mili giây có thể thúc đẩy các nhà phát triển cam kết ít thường xuyên hơn.

    Các lý do khác có thể bao gồm:

    • Quy tắc quá phức tạp để viết một thông điệp cam kết.

    • Quy tắc buộc nhà phát triển liên kết cam kết với một tác vụ từ hệ thống theo dõi lỗi.

    • Nỗi sợ phá vỡ tòa nhà.

    • Không sẵn sàng đối phó với nguy cơ phá vỡ bản dựng ngay bây giờ: nếu bạn thực hiện cam kết vào tối thứ Sáu ngay trước khi rời đi, bạn có thể hoãn giao dịch với bản dựng bị hỏng cho đến thứ Hai.

    • Nỗi sợ hãi khi làm một sự hợp nhất.

  8. Xác định xem các nhà phát triển có hiểu rằng có những lợi ích khác để cam kết thường xuyên hay không . Ví dụ, một nền tảng Tích hợp liên tục là một động lực rất lớn để có các cam kết thường xuyên , vì nó cho phép xác định chính xác nơi hồi quy được đưa ra .

    Tôi thà thích nền tảng CI nói với tôi rằng tôi đã phá vỡ bản dựng trong phiên bản 5023 bao gồm một thay đổi trong hai phương pháp trong một tệp tôi đã thực hiện mười lăm phút trước, thay vì trong bản sửa đổi 5023 bao gồm các thay đổi bao gồm bốn chục tệp và đại diện 13 giờ làm việc.


"Bạn đang tìm kiếm một giải pháp kỹ thuật cho vấn đề của con người. Điều đó hiếm khi hoạt động." - Tôi biết, nhưng tôi chỉ mệt mỏi và đã trải qua tất cả các điểm của bạn. Đó không phải là vấn đề của tôi lâu hơn nữa, tuy nhiên ...
VolkerK

@VolkerK: xem phần chỉnh sửa của tôi (hai đoạn đầu của câu trả lời). Bạn có máy chủ CI không? Khi bạn đã nói chuyện với đồng nghiệp, làm thế nào để họ giải thích việc họ không muốn cam kết thường xuyên hơn?
Arseni Mourzenko

1
@VolkerK Câu trả lời này giải thích rất tốt. Bạn không có vấn đề kỹ thuật. Vấn đề là với những người từ chối làm theo thủ tục.
BЈовић 16/12/14

1
Hướng tới điểm 3: Ứng dụng khách TortoiseSVN có thể tạo các sơ đồ khác nhau trực quan hóa hành vi đăng ký dựa trên các tham số khác nhau (như thời gian). Thật sự khá thú vị khi đánh giá chúng. Tôi đã làm điều này thường xuyên trở lại trong những ngày chúng tôi đang sử dụng SVN. stackoverflow.com/questions/412129/ cường :)
Aschratt

2
Cảm ơn về đầu vào nhưng tôi đã chọn tuyến đường khác và chỉ cần thông báo ;-)
VolkerK

-3

Một tổ chức mà tôi đã ký hợp đồng trước đây muốn giải quyết vấn đề tương tự này và đã đưa ra một giải pháp xã hội khá tốt: các nhà phát triển không có máy tính riêng. TEAM phát triển có máy tính, nhưng bất kỳ cá nhân nào cũng có thể được yêu cầu và dự kiến ​​sẽ làm việc trên bất kỳ máy tính phát triển nào vào bất kỳ ngày nào. Vì vậy, kiểm tra là cách duy nhất để đảm bảo bạn có thể tiếp tục làm việc với những gì bạn đã làm ngày hôm qua!

Quản lý sau đó đã đi xung quanh và lén lút hoàn nguyên các thay đổi trên máy tính sau nhiều giờ để mọi thứ không được kiểm tra bị mất. Những "lỗi máy tính mô phỏng" này chỉ phải xảy ra một vài lần trước khi các nhà phát triển lên tàu.

Tất nhiên, điều quan trọng là phải giải thích "tại sao" của các quy tắc cũng như "cái gì". Trừ khi "tại sao" được làm rõ, họ chỉ có thể lưu trữ nguồn của họ trên ổ USB hoặc một cái gì đó.


4
Đây là một cách khủng khiếp để đối xử với mọi người. Điều gì xảy ra khi bạn nghĩ về một cái gì đó ngay trước khi rời đi và muốn có nó trên máy, nhưng nó chưa hoàn thành (như không xây dựng) vì vậy bạn không muốn cam kết nó?
dùng1118321

3
Và nó là một sự lãng phí tài nguyên, bởi vì thông thường bạn có một môi trường thiết lập phù hợp với nhu cầu của bạn. Tôi đã có tình huống tương tự từ lâu và đã có máy tính xách tay của riêng mình sau 4 tuần. Tôi ghét mỗi ngày để thiết lập tất cả giống nhau, chỉ để làm công việc tôi dự kiến ​​sẽ làm.
mliebelt

1
Wow, đây là một ý tưởng khủng khiếp vì rất nhiều lý do. Như đã đề cập trong các ý kiến ​​trên, (1) nó ngăn chặn mọi khả năng liên tục từ ngày này sang ngày khác và (2) từ chối mọi người khả năng thiết lập môi trường dev tùy chỉnh xung quanh ...
Ben Lee

1
... Nhưng nó cũng có khả năng phá hủy hàng giờ làm việc nếu ai đó quên kiểm tra mã, hoặc vô tình không vì lý do nào đó và (4) chứng minh cho các nhà phát triển rằng quản lý không tin tưởng họ tuân theo quy tắc , thay vì áp đặt các quy tắc theo cách hà khắc, có khả năng biến nó thành môi trường so với chúng và (5) nó có khả năng khuyến khích họ phá vỡ các quy tắc chỉ để có hiệu quả.
Ben Lee

Xin vui lòng, không ai thực hiện ý tưởng này.
Ben Lee
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.