Làm thế nào tôi có thể thuyết phục các lập trình viên cao bồi sử dụng kiểm soát nguồn?

CẬP NHẬT
Tôi làm việc trên một nhóm nhỏ các nhà phát triển, 4 người. Họ đã sử dụng tất cả các kiểm soát nguồn. Hầu hết trong số họ không thể kiểm soát nguồn và thay vào đó chọn không sử dụng nó. Tôi tin tưởng mạnh mẽ rằng kiểm soát nguồn là một phần cần thiết của sự phát triển chuyên nghiệp. Một số vấn đề khiến việc thuyết phục họ sử dụng kiểm soát nguồn rất khó khăn:

• Nhóm không quen sử dụng TFS . Tôi đã có 2 buổi đào tạo, nhưng chỉ được phân bổ 1 giờ là không đủ.
• Các thành viên trong nhóm trực tiếp sửa đổi mã trên máy chủ. Điều này giữ cho mã không đồng bộ. Yêu cầu so sánh chỉ để chắc chắn rằng bạn đang làm việc với mã mới nhất. Và các vấn đề hợp nhất phức tạp phát sinh
• Ước tính thời gian được cung cấp bởi các nhà phát triển loại trừ thời gian cần thiết để khắc phục bất kỳ vấn đề nào trong số này. Vì vậy, nếu tôi nói không phải sẽ mất nhiều thời gian hơn ... Tôi phải liên tục giải thích những vấn đề này và tự mạo hiểm vì bây giờ ban quản lý có thể coi tôi là "chậm".
• Các tệp vật lý trên máy chủ khác nhau theo cách không xác định trên ~ 100 tệp. Sáp nhập đòi hỏi kiến ​​thức về dự án trong tay và do đó, hợp tác phát triển mà tôi không thể có được.
• Các dự án khác đang mất đồng bộ. Các nhà phát triển tiếp tục không tin tưởng vào kiểm soát nguồn và do đó kết hợp vấn đề bằng cách không sử dụng kiểm soát nguồn.
• Các nhà phát triển lập luận rằng việc sử dụng kiểm soát nguồn là lãng phí vì việc hợp nhất dễ xảy ra lỗi và khó khăn. Đây là một điểm khó để tranh luận, bởi vì khi kiểm soát nguồn bị sử dụng quá tệ và kiểm soát nguồn liên tục bị bỏ qua, đó thực sự là lỗi dễ xảy ra. Do đó, bằng chứng "nói lên điều đó" theo quan điểm của họ.
• Các nhà phát triển lập luận rằng trực tiếp sửa đổi mã máy chủ, bỏ qua TFS giúp tiết kiệm thời gian. Điều này cũng khó để tranh luận. Bởi vì việc hợp nhất cần thiết để đồng bộ hóa mã để bắt đầu là tốn thời gian. Nhân số này với hơn 10 dự án chúng tôi quản lý.
• Các tệp cố định thường được lưu trữ trong cùng thư mục với dự án web. Vì vậy, xuất bản (xuất bản đầy đủ) sẽ xóa các tệp không nằm trong kiểm soát nguồn. Điều này cũng gây mất lòng tin cho kiểm soát nguồn. Bởi vì "xuất bản phá vỡ dự án". Việc sửa lỗi này (di chuyển các tệp được lưu trữ ra khỏi các thư mục con của giải pháp) sẽ mất rất nhiều thời gian và gỡ lỗi vì các vị trí này không được đặt trong web.config và thường tồn tại trên nhiều điểm mã.

Vì vậy, văn hóa vẫn tồn tại. Thực hành xấu sinh thêm thực hành xấu. Các giải pháp xấu thúc đẩy các bản hack mới để "khắc phục" các vấn đề sâu hơn, tốn nhiều thời gian hơn. Máy chủ, không gian ổ cứng là vô cùng khó khăn để đi qua. Tuy nhiên, kỳ vọng của người dùng đang tăng lên.

Có thể làm gì trong tình huống này?

Đó không phải là vấn đề đào tạo, đó là vấn đề yếu tố con người. Họ không muốn và đang tạo ra các khối đường. Đối phó với các động lực nhóm bị phá vỡ, nguyên nhân sâu xa của sự phản đối của họ - thường là sợ hãi, đó chỉ là sợ thay đổi, hay nó độc ác hơn.

Không có nhà phát triển chuyên nghiệp nào ngày hôm nay, hoặc trong 20 năm qua, đã chống lại kiểm soát nguồn. Một lần, khoảng 30 hoặc 40 năm trước, khi máy tính hoạt động chậm, kiểm soát nguồn thậm chí chậm hơn và các chương trình bao gồm một tệp 500 dòng, đó là một nỗi đau và có những lý do hợp lệ để không sử dụng nó. Những phản đối này chỉ có thể đến từ loại cao bồi tồi tệ nhất mà tôi có thể nghĩ ra.

Là hệ thống buộc họ làm cho cuộc sống của họ khó khăn theo một cách nào đó? Tìm hiểu nó là gì và thay đổi hệ thống để vô hiệu hóa sự phản đối. Lặp lại cho đến khi hoàn thành.

Tôi đề nghị nhìn vào GIT hoặc Mercurial. Bạn có thể tạo một kho lưu trữ trong mỗi cây mã nguồn, họ thậm chí sẽ không nhận thấy và có thể tiếp tục hack theo cách họ làm bây giờ. Bạn có thể theo dõi các thay đổi mà họ đã hack vào cơ sở mã, thực hiện các cam kết, hợp nhất chúng vào các cây nguồn khác, v.v. Khi họ thấy bạn hợp nhất một tuần nỗ lực vào một sản phẩm khác trong vài giây, họ có thể thay đổi ý tưởng của họ. Khi bạn quay lại một trong những thao tác của họ bằng một lệnh và lưu mông của họ, họ thậm chí có thể cảm ơn bạn (đừng tin vào điều đó). Tệ nhất, bạn trông thật tuyệt trước mặt sếp và, để nhận tiền thưởng, hãy khiến họ trông giống như những chàng cao bồi.

Sáp nhập không chỉ cần một kiến ​​thức tuyệt vời về dự án

Trong trường hợp đó, tôi sợ bạn lên lạch không có mái chèo. Nếu việc hợp nhất không phải là một tùy chọn, thì cũng không thực hiện nó, vì vậy bạn đang nói rằng bạn không còn có thể thêm các tính năng bạn đã có trong một nhánh (thuật ngữ được sử dụng một cách lỏng lẻo) cho một nhánh khác.

Nếu tôi là bạn, tôi sẽ xem xét lại triển vọng nghề nghiệp của mình ...

Đôi khi, các vấn đề trong thế giới thực làm cho nó không thực tế để sử dụng.

Sai trái.

Nếu nhóm không quen sử dụng kiểm soát nguồn, vấn đề đào tạo có thể phát sinh

Điều đó không liên quan gì đến kiểm soát mã nguồn và mọi thứ liên quan đến đào tạo. Đào tạo dễ dàng, rẻ, hiệu quả và được thực hiện trong vài giờ. Không sử dụng kiểm soát mã nguồn là tốn kém, rủi ro, không hiệu quả và các vấn đề vẫn tồn tại mãi mãi .

Nếu một thành viên trong nhóm trực tiếp sửa đổi mã trên máy chủ, các vấn đề khác nhau có thể phát sinh.

Đó là vấn đề đào tạo. Lần nữa. Không có gì để làm với kiểm soát mã nguồn và tất cả mọi thứ để làm với đào tạo.

Các nhà phát triển tiếp tục không tin tưởng vào kiểm soát nguồn và do đó kết hợp vấn đề bằng cách không sử dụng kiểm soát nguồn

Họ cần được đào tạo về cách sử dụng kiểm soát mã nguồn. Nó giảm chi phí, giảm rủi ro, đơn giản hóa mọi thứ và hiệu quả hơn. Đó là một khoản đầu tư một lần trả cổ tức mọi lúc.

Những gì có thể có thể được thực hiện trong loại tình huống này?

Bắt đầu đào tạo mọi người về cách sử dụng kiểm soát mã nguồn.

Cập nhật

Các nhà phát triển lập luận rằng trực tiếp sửa đổi kiểm soát nguồn tiết kiệm thời gian.

Vì họ sai, điều quan trọng là thu thập dữ liệu để chứng minh chính xác điều này sai như thế nào.

Đáng buồn thay, tuy nhiên, quản lý dường như thưởng cho một phản ứng ngay lập tức mà tốn kém trong thời gian dài.

Cách duy nhất để vượt qua hệ thống khen thưởng này là

A) Xác định rằng chi phí dài hạn cao hơn giá trị ngắn hạn rõ ràng.

B) Xác định các phần thưởng thực tế đang thực sự tạo ra tham nhũng ngắn hạn (nghĩa là thay đổi trực tiếp) có vẻ có giá trị hơn so với kiểm soát mã nguồn chính xác dài hạn. Ai nhận được một cái vỗ nhẹ vào đầu để làm điều sai trái? Những loại vỗ nhẹ vào đầu họ nhận được? Ai cho nó? Để sửa chữa mọi thứ, bạn phải đặt tên cho những điều sai và người quản lý cụ thể thực sự khuyến khích mọi người.

C) Đề xuất một hệ thống khen thưởng được sửa đổi, coi trọng giá trị dài hạn thay vì phản ứng nhanh ngắn hạn. Pats khác nhau trên đầu vì lý do khác nhau.

D) Huấn luyện mọi người về những phần thưởng bạn tìm thấy cho giá trị lâu dài; giá trị rõ ràng lớn hơn phản ứng nhanh ngắn hạn.

Các nhà phát triển từ chối sử dụng kiểm soát nguồn / phiên bản nên bị sa thải, đơn giản như vậy. Như bạn đã chỉ ra, những rủi ro và chi phí vốn có của việc KHÔNG sử dụng nó lớn hơn bất kỳ chi phí nào mà nó phải chịu bởi nhiều, nhiều đơn đặt hàng lớn. Bất cứ ai cố gắng chống lại điều này chỉ đơn giản là không nên tham gia vào phát triển phần mềm và tôi sẽ thẳng thừng từ chối làm việc với những người như vậy.

Trước tiên, chúng tôi đã giải quyết vấn đề bằng cách thiết lập một máy chủ tích hợp liên tục để xây dựng kiểm soát nguồn của chúng tôi thành dev. Thứ hai, khóa truy cập thư mục để chỉ đọc, để ngăn mọi người phá vỡ kiểm soát nguồn và sửa đổi các tệp trực tiếp.

Đó là Pita vào những ngày bạn không thể tái tạo lỗi cục bộ, nhưng khác hơn là nó có thể hoạt động, kiểm tra và di chuyển tốt hơn, biết rằng nó sẽ được máy chủ CI đẩy tự động.

Tôi nghe thấy nỗi đau của bạn. Tôi đã đi vào một vài nơi làm việc để tìm ra "điều khiển nguồn" là một thư mục dùng chung trên ổ đĩa mạng. Vấn đề nói chung không phải là vì họ tin rằng phương pháp này vượt trội hơn bất kỳ thứ gì khác, nó đơn giản chỉ hoạt động và họ chưa từng được giới thiệu một quy trình công việc tích hợp thành công kiểm soát nguồn.

Với cấu trúc đội trái đất phẳng, bạn đã giải thích việc thay đổi được đẩy từ trên xuống có thể không phải là cách tốt nhất để tiếp cận tình huống. Một phương pháp đáng để thử là mua trực tiếp từ một hoặc hai nhà phát triển khác để cho phép khái niệm thu thập động lượng. Một khi bạn có ngay cả một nhà phát triển khác trên tàu, việc lan truyền nó đến phần còn lại của đội sẽ dễ dàng hơn nhiều. Từ từ giới thiệu cho họ khái niệm, nói rằng hãy bắt đầu làm việc với một dự án phụ nhỏ, đưa nó lên và đi vào Git , hoặc thậm chí chi nhánh một cái gì đó được lưu trữ trên GitHub .

Bắt đầu đơn giản, giới thiệu các khái niệm từ từ và riêng biệt từ quy trình công việc hàng ngày của họ. Con người rất giỏi trong việc học hỏi mọi thứ và thích nghi với sự thay đổi, đặc biệt là khi sự thay đổi đó mang lại lợi ích trực tiếp cho họ (nghĩ tiến hóa). Tuy nhiên, khi được trình bày với một loạt các thay đổi nhỏ cùng một lúc, nó trở nên xa lạ. Khi họ đã nắm bắt được cách thức kiểm soát nguồn hoạt động và những lợi thế mà nó mang lại, hãy thử tích hợp nó vào một dự án nội bộ của bạn (nếu bạn bắt đầu một dự án mới, đây là thời điểm xấu để giới thiệu nó). Hãy để các dự án khác hoạt động theo cách hiện có nếu bạn thích, điều này sẽ đặc biệt hiệu quả trong việc làm nổi bật các lợi thế của kiểm soát mã tốt.

Nếu thất bại, hãy chạy.

Bạn rõ ràng có các kỹ năng kỹ thuật để xác định và khắc phục tình huống của bạn, vấn đề của bạn là con người và quá trình liên quan.

Mọi người có xu hướng phản ứng tốt hơn nhiều so với ví dụ so với tầm nhìn, vì vậy tôi sẽ đề nghị "tự sửa" nó:

Lấy một bản sao của nguồn mới nhất, cấu trúc lại nó để thân thiện với kiểm soát phiên bản, tạo một dự án mới với cấu trúc hướng tới hữu ích (tìm hiểu cách bạn sẽ xử lý các chi nhánh, nơi bạn đặt phụ thuộc của bên thứ 3, v.v.). Có lẽ bạn sẽ phải làm điều đó trong thời gian của riêng bạn.

Sau đó kéo đồng nghiệp và quản lý của bạn vào một căn phòng và cho họ thấy sự phát triển phần mềm trông như thế nào trong thế kỷ 21. Minh họa những thất bại với hệ thống hiện tại của bạn và cho thấy cách chúng được loại bỏ với cấu trúc mới của bạn.

Bạn cũng sẽ phải tự đặt mình là Người giữ nguồn - vì bạn dường như là người duy nhất quan tâm, bạn buộc mọi người (với bất kỳ phương tiện kỹ thuật hoặc tâm lý nào theo ý của bạn) phải tuân theo kế hoạch. Đảm bảo rằng điều duy nhất đến với khách hàng đã đến từ một máy xây dựng ngoài tầm kiểm soát nguồn. Nghi thức làm nhục những người phá vỡ các quy tắc và gây ra sự tàn phá. Mua chuộc họ bằng bánh rán ... bất cứ việc gì.

Nếu tất cả điều đó có vẻ như quá nhiều nỗ lực thì (như đã nói trong mỗi câu trả lời khác) - hãy kiếm một công việc khác. Họ không xứng đáng với thời gian của bạn.

Bước 1 - quản lý bất tài!

Nếu bạn không thể thực hiện bước 1, hãy cố gắng để người quản lý giới hạn triển khai để chỉ sản xuất các tập lệnh được lấy từ kiểm soát nguồn. Nếu các nhà phát triển (những người không nên có quyền sản xuất trên prod, hãy xem bước 1 nếu họ muốn) muốn công cụ của họ được triển khai, nó phải đến từ kiểm soát nguồn. Điều đó đã giải quyết vấn đề của chúng tôi về việc không sử dụng kiểm soát nguồn khá độc đáo khi chúng tôi lần đầu tiên sử dụng nó cho công cụ cơ sở dữ liệu cũng như mã C #.

Làm thế nào một người nào đó không muốn các phiên bản khác nhau của tệp của họ và khả năng nhìn thấy sự khác biệt? Quên phân nhánh và bất kỳ thứ phức tạp. Họ thậm chí không có được những điều cơ bản. Trực tiếp sửa đổi một tệp sản xuất mà không thực hiện thay đổi thô sơ nhất trong môi trường thử nghiệm là điên rồ. Tôi đã làm việc với một số cá nhân và rất may chúng tôi không bao giờ làm việc trong cùng một dự án.

Đồng nghiệp của bạn quá ngu ngốc để lười biếng. Điều đó thật lãng phí thời gian. Tất cả những gì bạn có thể hy vọng làm là đào tạo người quản lý của bạn. Quản lý nên thích kiểm soát nguồn vì họ thích tất cả các hình thức kiểm soát. Làm cho họ cảm thấy quan trọng. Vít người khác; sửa chữa người lãnh đạo là hy vọng duy nhất của bạn vì bạn không thể thay thế anh ta. Bắt đầu kết nối với các nhà phát triển có thẩm quyền khác và cố gắng để họ tham gia nhóm của bạn khi bạn mở cửa hoặc khiến họ thuê bạn tại cửa hàng của họ.

Đây là một ví dụ tốt về một dự án nơi các thực tiễn xấu đã được sử dụng một cách phổ biến đến mức thực tế không thể sửa chữa nó. Sửa nó sẽ yêu cầu đóng băng, vì vậy mọi thứ có thể được làm sạch mà không bị gián đoạn. Thật không may, các dự án như vậy thường là (vì lý do rõ ràng) quá lỗi để bị đóng băng trong vài tháng, các lỗi nghiêm trọng phải được sửa mỗi ngày.

Bạn có thể bị cám dỗ rẽ nhánh dự án để tạo ra một phiên bản sạch trong khi phiên bản bẩn được xử lý với các lỗi đó hàng ngày; nhưng kết quả rất có thể là sau vài tháng, khi phiên bản "sạch" kết thúc, không ai có thể cho bạn biết những lỗi và thay đổi nào đã được đưa vào kể từ ngã ba (vì cùng một suy nghĩ cho phép mọi người trượt vào những thực tiễn như vậy khiến cho điều đó khó xảy ra họ giữ hồ sơ về những thay đổi họ thực hiện). Phiên bản sạch đã lỗi thời, phiên bản bẩn vẫn hoạt động, vậy chuyện gì xảy ra? Phiên bản sạch sẽ bị đổ, những ngày không được chứng minh là đúng.

Khác với điều hiển nhiên Tìm một công việc mới, tôi nghĩ câu trả lời là nhiều hơn tất cả những điều trên.

Trước tiên, hãy đến quản lý để đưa họ lên tàu với việc chuyển sang và thực thi việc sử dụng kiểm soát nguồn. Sau đó, đến những gì cần phải được thực hiện để giữ cho mọi thứ chạy, ngay cả khi điều đó có nghĩa là làm việc trực tiếp trên máy chủ. Bắt đầu quá trình nhận mọi thứ trong kiểm soát nguồn.

Một tùy chọn khác là đảm bảo mới nhất có trên máy chủ (mà bạn phải làm bất kể) và bắt đầu một kho lưu trữ mới hoàn toàn từ mới nhất. Bạn sẽ mất lịch sử, nhưng tại thời điểm này đó là khoai tây nhỏ.

Dường như từ mô tả của bạn rằng có một hoặc nhiều vấn đề với tình huống - hoặc nhóm phát triển ngoài tầm kiểm soát hoặc giải pháp kiểm soát nguồn xấu đã được triển khai. Dù bằng cách nào, nhóm phát triển sử dụng một số giải pháp kiểm soát nguồn - việc sửa đổi trực tiếp mã nguồn trên dịch vụ sản xuất chỉ là để cầu xin cho các vấn đề xảy ra.

Từ kinh nghiệm của tôi, bước đầu tiên phải diễn ra ngay lập tức là đồng bộ hóa kiểm soát nguồn với máy chủ sản xuất. Bước này có thể đơn giản như lấy một bản sao của mã sản xuất và kiểm tra nó - mã prod có lẽ là cơ sở mà nhóm của bạn đang phát triển. Bước này có thể cần được tăng cường bằng cách hợp nhất với mã đang trôi nổi trong hệ thống kiểm soát nguồn hiện có. Mã phải chuyển từ dev sang tích hợp / QA (hoặc cả hai), sau đó chuyển sang giai đoạn hoặc giai đoạn / sản xuất.

Tiếp theo, quản lý cần bắt buộc sử dụng kiểm soát nguồn. Rất đơn giản, nếu bản dựng không đến từ hệ thống kiểm soát nguồn, mã không nên được triển khai để sản xuất. Truy cập sản xuất chỉ cần giới hạn trong nhóm hỗ trợ, với quyền truy cập hạn chế được cung cấp cho nhà phát triển để khắc phục sự cố sản xuất. Các nhà phát triển nói chung không bao giờ nên triển khai mã nóng cho sản xuất - vấn đề sản xuất chắc chắn có thể xảy ra, đặc biệt nếu các nhà phát triển chịu áp lực.

Quản lý chắc chắn cần phải xử lý tốt hơn các vấn đề ở đây - gần như không thể duy trì sự phát triển nếu mã được áp dụng trực tiếp vào sản phẩm (và không được kiểm soát nguồn).

Vấn đề thực sự không phải là các lập trình viên cao bồi không sử dụng kiểm soát phiên bản. Vấn đề thực sự là họ đã chọn một số cách làm việc và bạn đang cố gắng thay đổi quy trình của họ. Quá trình được chọn không bao gồm kiểm soát phiên bản. Tất cả các thay đổi quá trình là khó khăn, trừ khi chính các lập trình viên nhận thấy một vấn đề. Nếu có cảm giác rằng hệ thống hiện tại đủ tốt, cố gắng áp đặt một số hệ thống khác nhau chỉ là vô ích. Chúng tôi là borg, bạn sẽ bị đồng hóa. Tất nhiên họ đang cố gắng chiến đấu để trở thành borg.

Vì sự tỉnh táo của riêng bạn, tôi khuyên bạn nên thiết lập Git hoặc DVCS khác trên máy của mình để bạn có thể theo dõi các thay đổi. Thường xuyên nhập các thay đổi của đồng nghiệp vào kho lưu trữ của bạn. Giải quyết xung đột tốt nhất có thể. Điều này sẽ bảo vệ bạn một phần khỏi sự điên rồ của đồng nghiệp.

Bạn đã đề cập rằng quản lý đã nói rằng các nhà phát triển nên sử dụng kiểm soát nguồn. Nếu bạn muốn trở nên xấu xa, bạn có thể thực thi điều này bằng cách kiểm tra các thay đổi trong TFS và định kỳ xuất bản kho lưu trữ, do đó ghi đè mọi thay đổi không có trong TFS. (Nếu bạn cũng đang duy trì DVCS của riêng mình, bạn nên giữ hai đồng bộ hóa.) Lý do của bạn để làm như vậy là bạn đang tuân theo lệnh của ban quản lý. Nếu đồng nghiệp của bạn cảm thấy mệt mỏi vì những thay đổi của họ bị ghi đè, hãy mời họ sử dụng TFS. Và tiếp tục ghi lại những thay đổi chưa được kiểm tra. Tiếp tục cho đến khi đồng nghiệp của bạn đồng ý hoặc bạn bị sa thải.

Khóa bất kỳ máy chủ nào khác ngoài sự phát triển của họ. Sử dụng trình quản lý cấu hình. Làm các bản dựng nhận dạng thường xuyên (chống lại các thẻ). Gắn thẻ cho mỗi bộ thay đổi (nghĩa là 1 bộ thay đổi cho mỗi lỗi). Chúng tôi cũng đặt một thẻ trên mỗi bản dựng. Có hệ thống loại QA giữa dev và sản xuất (tối thiểu). Xây dựng hệ thống QA bằng thẻ xây dựng chính xác. Cung cấp cho họ đau buồn cho "phá vỡ xây dựng".

Tôi chưa bao giờ gặp phải tình huống không thể tạo lại / khắc phục sự cố (điều này chỉ hiển thị trên sản xuất). Có, tôi đã dành hàng giờ để khắc phục sự cố trên hệ thống phát triển (cộng với khi bạn tìm ra vấn đề, bạn có thể thêm nó vào kiểm tra hồi quy của mình).

Chúng tôi đã làm một dự án với một loạt các nhà thầu cao bồi, những người đã làm tất cả những điều xấu đó. Tôi dành 4 tuần để dọn dẹp sau đó và sau đó áp dụng các thực hành trên. Dự án đã không có vấn đề với bất kỳ những điều đó kể từ đó.

Trích dẫn:

Nhóm không quen sử dụng TFS

TFS hóa ra là Microsoft Team Foundation Server.

Bản năng đầu tiên của tôi nói: "đây là bản phát hành mới nhất của Microsoft Visual SourceSafe"

Tôi sẽ đứng về phía các đồng nghiệp của bạn và thực sự chống lại điều này.