Các tiêu chuẩn cho cách các nhà phát triển làm việc trên các máy trạm của riêng họ


18

Chúng tôi vừa gặp một trong những tình huống thỉnh thoảng xuất hiện khi một nhà phát triển bị ốm trong vài ngày giữa dự án.

Có một vài câu hỏi về việc liệu anh ta đã cam kết phiên bản mã mới nhất của anh ta hay liệu có một cái gì đó gần đây hơn trên máy cục bộ của anh ta mà chúng tôi nên xem xét và chúng tôi đã giao hàng cho một khách hàng đang chờ xử lý để chúng tôi không thể chờ đợi Anh trở về.

Một trong những nhà phát triển khác đã đăng nhập khi anh ta nhìn thấy và tìm thấy một không gian làm việc lộn xộn, nhiều dự án dường như giống nhau, với dấu thời gian làm cho nó không rõ là "hiện tại" (anh ta đang tạo ra một số bit trên các phiên bản của dự án khác với "cốt lõi" của mình).

Rõ ràng đây là một cơn đau ở cổ, tuy nhiên giải pháp thay thế (dường như là tiêu chuẩn nghiêm ngặt về cách mỗi nhà phát triển làm việc trên máy của họ để đảm bảo rằng bất kỳ nhà phát triển nào khác có thể chọn mọi thứ với nỗ lực tối thiểu) có thể sẽ phá vỡ nhiều nhà phát triển dòng công việc cá nhân và dẫn đến không hiệu quả ở cấp độ cá nhân.

Tôi không nói về các tiêu chuẩn cho mã đăng ký, hoặc thậm chí các tiêu chuẩn phát triển chung, tôi đang nói về cách nhà phát triển làm việc tại địa phương, một miền thường được coi là (theo kinh nghiệm của tôi) gần như hoàn toàn dưới sự kiểm soát của chính nhà phát triển.

Vậy làm thế nào để bạn xử lý các tình huống như thế này? Là một trong những điều vừa xảy ra và bạn phải đối phó, cái giá bạn phải trả cho các nhà phát triển được phép làm việc theo cách phù hợp nhất với họ?

Hoặc bạn có yêu cầu các nhà phát triển tuân thủ các tiêu chuẩn trong lĩnh vực này - sử dụng các thư mục cụ thể, tiêu chuẩn đặt tên, ghi chú trên wiki hoặc bất cứ điều gì không? Và nếu vậy thì tiêu chuẩn của bạn bao gồm những gì, chúng nghiêm ngặt đến mức nào, làm thế nào để bạn cảnh sát chúng và vân vân?

Hoặc có một giải pháp khác tôi đang thiếu?

[Giả sử vì lý lẽ rằng nhà phát triển không thể liên lạc để nói chuyện về những gì anh ta đang làm ở đây - ngay cả khi anh ta có thể biết và mô tả không gian làm việc nào mà từ bộ nhớ sẽ không đơn giản và hoàn hảo và đôi khi mọi người thực sự có thể sẽ không được liên lạc và tôi muốn một giải pháp bao gồm tất cả các tình huống.]

Chỉnh sửa: Tôi hiểu rằng việc đi qua máy trạm của ai đó là một hình thức tồi tệ (mặc dù đó là một điều thú vị - và có thể ngoài chủ đề - câu hỏi chính xác là tại sao) và tôi chắc chắn không nhìn vào truy cập không giới hạn. Hãy suy nghĩ nhiều hơn về các tiêu chuẩn nơi các thư mục mã của chúng được thiết lập với chia sẻ chỉ đọc - không có gì có thể thay đổi, không có gì khác có thể được nhìn thấy, v.v.


8
-1 để đi Gestapo trên trung tâm chỉ huy của lập trình viên.
systemovich

17
Đợi đã, làm thế nào mà nhà phát triển thứ hai biết mật khẩu của nhà phát triển đầu tiên?
TheLQ

12
+1 cho một câu hỏi xuất sắc. Theo quan điểm của tôi, "Đi cử hành" không liên quan đến môi trường doanh nghiệp vì các nhà phát triển đang làm việc cho tập đoàn và do đó từ bỏ quyền truy cập vào các máy cục bộ của họ. Bạn muốn riêng tư, sử dụng phần cứng của riêng bạn.
Gary Rowe

4
Nếu nhà phát triển có thể được liên lạc để lấy mật khẩu, tại sao bạn không hỏi anh ta phiên bản nào là phiên bản hiện tại?
Ben L

2
@Gary: cái gì? không, đó là hoàn toàn (và rất nguy hiểm) vô nghĩa. Đó là một phát súng looong (cả về mặt logic và pháp lý) từ làm việc cho một công ty đến từ bỏ quyền cá nhân vì quyền riêng tư. Tôi sẽ không gọi hành động của Jon là Gestapo Lần (ngay cả trước khi anh ấy giải thích thêm) nhưng đôi khi các công ty lại đi Gestapo và đây là điều cần được ngăn chặn và chiến đấu ở mọi cấp độ. Tôi chỉ có thể nói cho Đức nhưng ở đây bạn làm có quyền riêng tư nhất định, ngay cả khi làm việc trên phần cứng công ty sở hữu.
Konrad Rudolph

Câu trả lời:


64

" Nếu nó không nằm trong kiểm soát nguồn, thì nó không tồn tại. "

Đây là một trong số ít những điều trong nghề nghiệp của chúng tôi mà tôi bị giáo điều. Vì những lý do sau đây:

  1. Mặc dù máy trạm là tài sản của công ty, chúng ta hãy đối mặt với nó - có một chút quy tắc bất thành văn rằng máy trạm của lập trình viên là lâu đài của anh ấy / cô ấy. Tôi chỉ cảm thấy khó chịu với văn hóa nơi làm việc, nơi mọi người có thể thường xuyên đăng nhập vào đó và đi qua nó.
  2. Mọi người đều có dòng chảy riêng của họ (như bạn đã nói). Cố gắng buộc tất cả các nhà phát triển tổ chức các không gian làm việc cục bộ của riêng họ theo một cách nhất định có thể đi ngược lại cách làm việc cụ thể của họ, và phá vỡ dòng chảy của họ và làm cho chúng kém hiệu quả hơn.
  3. Thứ không được kiểm soát nguồn là mã nửa nướng. Nếu mã được nướng hoàn toàn sẵn sàng để phát hành, nó sẽ nằm trong sự kiểm soát nguồn. Mà trở lại một lần nữa đến điểm chính ....
  4. "Nếu nó không nằm trong kiểm soát nguồn, thì nó không tồn tại."

Một cách khả thi để giảm thiểu vấn đề muốn xem mã trên máy trạm của mọi người là thúc đẩy văn hóa kiểm tra thường xuyên. Tôi đã từng làm việc tại một công ty ở đó - mặc dù không có nhiệm vụ chính thức nào để làm điều đó - nó được nhìn thấy là một điểm tự hào để luôn luôn kiểm tra mọi thứ vào cuối tuần. Trong các giai đoạn bảo trì và phát hành ứng cử viên, các vật phẩm CR được cố tình tạo hạt rất mịn để cho phép thay đổi nhỏ, rõ ràng và kiểm tra thường xuyên để theo dõi chúng.

Ngoài ra, có tất cả mọi thứ được kiểm tra trước khi bạn đi nghỉ là bắt buộc .

Phiên bản TL; DR : Súng trường qua máy trạm của mọi người là hình thức xấu. Thay vì cố gắng nuôi dưỡng văn hóa giúp dễ dàng đi qua các máy trạm của mọi người để tìm thấy những gì chúng ta muốn, tốt hơn hết là nên nuôi dưỡng văn hóa sử dụng kiểm soát nguồn hợp lý và kiểm tra thường xuyên. Thậm chí có thể kiểm tra siêu thường xuyên và các nhiệm vụ chi tiết khi ở giai đoạn quan trọng của dự án.


10
+1: Ai đó bị ốm, làm rối tung máy trạm của họ có lẽ sẽ tốn nhiều chi phí hơn giá trị. Một người đã biến mất. Bây giờ một người khác đang lãng phí thời gian để cố gắng tìm hiểu những gì đang xảy ra. Cơn ác mộng quản lý lớn không có giá trị. Cho đến khi nó trong kiểm soát nguồn, nó không bao giờ tồn tại.
S.Lott

1
Nếu anh ấy nghỉ cả ngày? Yup, cho phần còn lại của tuần? Có lẽ, trong một tháng? Không có cơ hội. Đây là một trong những vấn đề "màu xám" khó chịu ... chúng tôi quay lại, để cam kết sớm, cam kết thường xuyên - vì vậy các mẫu không nhất thiết phải là máy trạm mà sử dụng kiểm soát phiên bản, nhưng rõ ràng đó là thứ gì đó đáng suy nghĩ về.
Murph

Khi bạn nói phát hành, bạn có nghĩa là phát hành cho bản dựng hoặc phát hành cho người dùng?
JeffO

2
@Murph: Nếu các thay đổi được cam kết ở đâu đó cứ sau X ngày, số lượng công việc tối đa có thể bị thất lạc là giá trị của X ngày và điều đó đúng cho dù nhà phát triển không thể tránh khỏi bao lâu. Điều đúng đắn cần làm là có các chính sách về việc kiểm tra thường xuyên đủ để số lượng công việc bị mất nằm trong giới hạn chấp nhận được.
David Thornley

1
@David nhận xét của tôi là phản hồi của @ S.Lott - về mặt tranh luận về "mất". Vâng loại. Tôi muốn cam kết trở thành nguyên tử theo nghĩa là một tập hợp thay đổi hoàn chỉnh (Tôi bắt đầu hiểu tại sao rebase lại hấp dẫn như vậy) - vì vậy tôi thấy "cam kết tiết kiệm" là có vấn đề (trong trường hợp chung và khi vắng mặt của một rebase tương đương). Và trong mọi trường hợp, nên có các bản sao lưu máy trạm tự động hàng ngày khá khác biệt với kiểm soát phiên bản.
Murph

22

Thay vì thực thi một tiêu chuẩn cho cách các nhà phát triển của bạn tổ chức các máy trạm của họ, hãy thực thi một tiêu chuẩn nơi tất cả các công việc được kiểm tra vào cuối mỗi ngày . Việc đăng ký có thể đến các chi nhánh nếu vẫn chưa hoàn tất.

Bằng cách này, không ai cần phải truy cập vào máy trạm của nhà phát triển khác.

Tôi sẽ tưởng tượng rằng chính sách này sẽ gặp một số người phản đối, nhưng không có gì so với những gì tôi mong đợi nếu bạn thực thi các quy tắc về tổ chức của các máy trạm.


1
Bao lâu bạn sẽ hợp nhất chi nhánh? Mỗi khi bạn cảm thấy nó ổn định?
Jon Hopkins

2
@Jon Hopkins: "Releasable" dễ quản lý hơn "Ổn định". Releasable bao gồm ổn định cũng như chủ sở hữu sản phẩm đã sẵn sàng cho nó. Và bạn sẽ thực hiện nhiều quy trình xử lý phát hành chi nhánh. Chi nhánh ổn định có quá nhiều tiềm năng cho sự chủ quan và thảo luận "làm việc cho tôi".
S.Lott

2
-1 Tôi không đồng ý với điều này mà không có đủ điều kiện, việc đăng ký sẽ diễn ra ở điểm hợp lý - và không được tự ý vào cuối ngày. (Vâng, chúng ta nên cố gắng không rời khỏi cho đến khi chúng ta đã đến một điểm dừng hợp lý nhưng cuộc sống không phải lúc nào cũng hợp tác.) Sao lưu nên khác biệt. Và tất cả chúng ta cần phải bớt một chút quý giá về quyền truy cập vào các hộp của chúng tôi (không thay đổi , truy cập vào)
Murph

1
-1 bởi vì điều này không giải quyết các tình huống như "Tôi cảm thấy thực sự bị bệnh, tôi đang về nhà ngay bây giờ. Hmm, tốt hơn hết là hãy chuẩn bị thêm 30 phút nữa để tôi không phá vỡ công trình khi tôi cam kết."
Gary Rowe

2
@Murph Đăng nhập vào 'thân cây' hoặc đường chính (bất cứ điều gì bạn muốn gọi nó) chỉ nên xảy ra như bạn mô tả. Tuy nhiên, không có gì sai khi các nhà phát triển 'lưu công việc của họ vào cuối ngày' bằng cách cam kết với một chi nhánh cá nhân (mặc dù điều này dễ dàng hơn nhiều với git hoặc đồng bóng so với SVN). Và so với việc thực thi các hướng dẫn về cách các máy trạm của các nhà phát triển được cấu hình (vốn là điểm khởi đầu của chúng tôi) thì đó là một giải pháp hoàn toàn chính đáng.
Kris

6

Tôi sẽ nói cho bạn biết sự thật tôi cảm thấy không yên tâm về chính ý tưởng rằng ai đó sẽ đăng nhập vào máy của tôi và duyệt qua nội dung của tôi. Cấp, đó là thiết bị và tài sản của công ty, nhưng nó đơn giản là một điều xấu để làm.

Lần trước tôi rời đi vào cuối tuần, các anh chàng đã cấu hình lại các máy chủ với cơ sở dữ liệu và kiểm soát nguồn và vì một lý do nào đó cảm thấy cần phải đăng nhập vào máy của tôi và cấu hình lại hệ thống cho cài đặt mới.

Thật tệ là họ không biết họ đang làm gì và họ đã xóa một nguyên mẫu mà tôi đã làm việc trong hai tháng qua.

Nó sẽ không xảy ra nếu giao tiếp thích hợp được thực hiện. Đó là những gì bạn cần là tốt. Đến nhà phát triển đó và tìm hiểu trạng thái của sự việc. Thậm chí tốt hơn, yêu cầu mọi người báo cáo trước khi họ nghỉ phép để bạn đưa ra quyết định sáng suốt cho dù bạn có cần bất cứ điều gì của họ hay không.

Nhưng đừng gây rối với máy trạm của mọi người.

PS Chúng tôi có một quy ước cho cấu trúc thư mục nhưng lý do tồn tại chính của nó là sự pha trộn của lịch sử / cấu hình - đặt nó ở bất kỳ nơi nào khác và nó sẽ không được biên dịch.


3
@Murph: "hết bệnh" kèm theo nhu cầu cấp thiết để có được thứ gì đó từ hệ thống của anh ấy là một tình huống thực sự hiếm gặp. Có thể không có giá trị bất kỳ nỗ lực tiêu chuẩn hóa.

1
Tôi có thể hiểu tại sao ai đó nên đọc thư của bạn và không nên thay đổi bất cứ điều gì trên máy của bạn nhưng làm thế nào nếu nó là tiêu chuẩn để chia sẻ (chỉ đọc) thư mục mã của bạn? Điều đó sẽ làm tròn hầu hết những gì tôi cho là sự phản đối của bạn nhưng vẫn cho phép mọi người có khả năng đến nơi làm việc của bạn trong trường hợp khẩn cấp.
Jon Hopkins

3
Không có bản sao lưu trên nguyên mẫu đó?
JeffO

2
@ Nhà phát triển nghệ thuật, tại sao bạn không làm việc trong một nhánh của hệ thống phiên bản?

1
@DeveoperArt, ý bạn là gì "không sử dụng tùy chọn đó"? Bạn có nghĩa là không có cách nào để bạn tự tạo một chi nhánh? Có phải họ bằng cách nào đó vô hiệu hóa phân nhánh? Tôi chưa bao giờ nghe về khả năng đó. Thậm chí, bạn có thể đã tạo kho lưu trữ "git" (hoặc thậm chí "svn") của riêng mình trên máy cục bộ của riêng bạn (có thể được sao lưu vào Dropbox hoặc ổ đĩa mạng) mà không liên quan đến ai khác. Tôi chỉ không thể liên quan cá nhân để làm việc gì đó trong 2 tháng (hoặc thậm chí 2 giờ , thực sự) cho dù "quan trọng" hay không, và chỉ có 1 bản sao của nó.
JoelFan

6

Vài tháng trước, tôi đang thực hiện một dự án khá lớn và phải nghỉ việc đột ngột khi phát hiện ra mình đang phải nhập viện. Tôi không có thời gian để kiểm tra mã mới nhất của tôi cho dự án.

May mắn thay, đây là quy ước ở đây (mặc dù không "cần thiết") để lưu trữ mã /var/www/ourdomain.comđể bắt chước sản xuất. Với quy ước hợp lý và dễ thực hiện như vậy, thật dễ dàng để đồng nghiệp đăng nhập vào máy của tôi và truy xuất các thay đổi mới nhất của tôi.

Tôi nghĩ rằng một số quy ước là tốt. Mặc dù tôi đồng ý với Bobby khi anh ấy nói

"Nếu nó không nằm trong kiểm soát nguồn, thì nó không tồn tại."

Ngoài ra, một bổ sung hữu ích cho bất kỳ không gian làm việc của lập trình viên nào có thể là ổ đĩa SATA trao đổi nóng ở phía trước để lưu trữ tất cả các dự án nguồn và phát triển. Bằng cách này, nếu một vấn đề như vậy phát sinh, một nhân viên có thể dễ dàng truy xuất các thay đổi nguồn mới cho dự án mà không cần phải đăng nhập vào máy trạm của nhà phát triển.


"... nó không tồn tại". Đối với người khác, đó là.

4

Phần đầu tiên của câu hỏi của bạn xác định rõ các vấn đề giao tiếp trong nhóm của bạn. Bạn đã thử standups hàng ngày ?

Tôi đồng ý với bạn khi bạn nói rằng các tiêu chuẩn có thể sẽ dẫn đến không hiệu quả nếu chúng quá nghiêm ngặt. Các tiêu chuẩn phải được xác định bởi nhóm , liên quan đến tất cả mọi người.

Trong trường hợp của bạn, tôi sẽ đợi vài ngày sau khi nhà phát triển có liên quan trở lại làm việc. Sau đó tổ chức một cuộc họp để nói về những tiêu chuẩn đó.

Để tránh bất kỳ khối tâm lý và sự phản kháng nào, đừng gọi tên người hoặc những thứ cụ thể mà bạn đã thấy. Nói chung, mục tiêu ở đây là để có được đầu vào từ mọi người, bao gồm cả nhà phát triển mà bạn nghĩ nên cải thiện cách làm việc của mình. Các chàng có thể coi tổ chức của bạn là một mớ hỗn độn quá.

Trong cuộc họp trình bày vấn đề và hỏi rõ ràng làm thế nào nhóm có thể cải thiện tình hình.

Các (toàn bộ) nhóm quyết định phải làm gì.


2

Người dùng đó có lẽ đã bị thiếu công cụ thích hợp. Cụ thể, việc sử dụng một hệ thống kiểm soát phiên bản phân tán sẽ giúp loại bỏ nhu cầu có các thư mục mã khác nhau ở các trạng thái khác nhau. Anh ấy có thể giữ tất cả trong nhánh và hạnh phúc hơn nhiều.

Tuy nhiên, đến điểm chính, không, tôi không muốn các tiêu chuẩn được thi hành theo cách tôi tổ chức máy trạm của riêng mình. Tôi hiện đang đẩy lùi việc bộ phận của tôi chuẩn hóa một IDE (sếp của tôi THỰC SỰ muốn tất cả chúng ta trong Eclipse vì đó là những gì anh ta sử dụng và biết rõ, mặc dù IMO không phải là công cụ tốt nhất cho công việc của tôi ).

Hãy để các nhà phát triển làm bất cứ điều gì làm cho họ thoải mái. Một nhà phát triển thoải mái có năng suất cao hơn một người không thoải mái. Và nếu ai đó KHÔNG làm việc hiệu quả và bạn nghi ngờ họ đang dò dẫm các công cụ địa phương, thì đó là cơ hội để đào tạo, không phải là thời điểm tốt để đưa ra các quy tắc mới.


1
Điều đó sẽ giúp như thế nào? Câu hỏi vẫn còn tồn tại, chúng ta chỉ nói về nhánh nào trong kho DVCS cục bộ của anh ta hơn là không gian làm việc.
Jon Hopkins

Đừng cho rằng đó là các công cụ - nó cũng đánh giá cao cách sử dụng tốt nhất các công cụ có thể thiếu. Những gì rõ ràng đối với một số nhu cầu phải được hiển thị cho những người khác. Mô hình chống nhiều bản sao của cây nguồn là một trong những lần tôi đã thấy một vài lần. Có, DVCS có thể giúp - nhưng trong bối cảnh này, chúng tôi vẫn gặp vấn đề với việc xác định đúng nhánh và - nếu chúng tôi muốn đi xa hơn - với việc cung cấp các nhánh Work In Progress đó. @Jon DVCS cục bộ sẽ tự động đẩy vào "bản sao lưu" kho lưu trữ của người dùng đó. Ít nhất nếu di chuyển vấn đề ra khỏi hộp của họ.
Murph

@Jon - Tôi đoán vấn đề là, các nhánh đa dạng của anh ta sẽ nằm trong một cái gì đó có chức năng hợp nhất được tích hợp trong nó, thay vì chỉ là các thư mục phân tán của các tệp phân kỳ. Thêm vào đó, việc đưa anh ta lên và đi vào DVCS sẽ là một cơ hội đào tạo.
Dan Ray

1
@Dan - Nhưng một số trong những nhánh đó là ngõ cụt - bằng chứng về khái niệm, những thứ có mã gỡ lỗi các loại mà bạn không muốn hợp nhất trong các phiên bản cũ hơn. Thực tế là bạn có chức năng hợp nhất không giúp ích gì khi bạn không biết những gì bạn nên hợp nhất.
Jon Hopkins

@Jon - Tôi đoán đó là sự thật. Có lẽ không có sự phục hồi từ ai đó thực sự cam kết làm cho một mớ hỗn độn.
Dan Ray

2

Tại nơi làm việc cũ của tôi, chúng tôi đã có một hệ thống, theo đó mỗi nhiệm vụ trong việc sửa lỗi của chúng tôi đều có chi nhánh riêng trong việc kiểm soát nguồn. Điều này được hiểu rằng hầu hết thời gian, một lỗi / tác vụ bị xóa bởi một nhà phát triển nên mã bị hỏng được phép kiểm tra trong kiểm soát nguồn.

Khi mã ở trạng thái ổn định trên nhánh phát triển, một rebase đã được thực hiện kéo mã từ nhánh bạn sẽ tích hợp. Khi bạn đã kiểm tra việc hợp nhất đó, đó chỉ đơn giản là một trường hợp cam kết mã cho nhánh tích hợp - nó sẽ không yêu cầu hợp nhất vì bạn đã thực hiện hợp nhất trên nhánh của mình.

Bằng cách này, bạn sẽ giải quyết được vấn đề các nhà phát triển lo lắng về việc cam kết mã bị hỏng - và bạn có thể bắt đầu áp dụng chính sách xã hội để kiểm tra mã siêu chấp nhận trước khi bạn rời văn phòng vào ban đêm - tốt và an toàn.


2

Trong này tình hình cuộc gọi đặc biệt là người ở nhà, làm cho nó rất rõ ràng rằng bạn không phải nghi ngờ rằng ông bị ốm nhưng bạn cần phải có người khác tiếp tục công việc của mình, và hỏi nơi những thứ mới nhất là gì và trong trạng thái gì.

Sau đó, bạn cần xem xét những gì để làm từ đây. Nếu vấn đề là mọi người kiểm tra quá hiếm khi, hãy xem xét sử dụng hệ thống kiểm soát nguồn phân tán cho phép mọi người làm việc trong các chi nhánh mà không làm phiền nhau.

Nếu vấn đề là bạn không thích các nhà phát triển có nhiều không gian làm việc trên máy của họ, thì hãy vượt qua nó. Phong cách làm việc là cá nhân và về cơ bản bạn nên tránh xa hệ thống của họ miễn là họ làm việc tốt với các quy tắc cho kho lưu trữ nguồn. Cá nhân tôi kiểm tra một bản sao mới rất thường xuyên cho các dự án khác nhau và chỉ dọn dẹp một lần trong một thời gian.

Nếu vấn đề là bạn không biết nhà phát triển của mình đang làm gì, thì vấn đề là chính trị không mang tính kỹ thuật và bạn cần thay đổi phong cách quản lý. Xin nhớ rằng các nhà phát triển là những người có kỹ năng cao, những người hiếm khi thích quản lý vi mô và bạn phải ủy quyền. Nếu không bạn sẽ đẩy những cá nhân lành nghề nhất đi.

Vì vậy, tôi khuyên bạn nên khuyến khích một cách tốt hơn để làm việc với kho lưu trữ nguồn chung - nói rằng mọi người làm việc trong các chi nhánh đều tốt và để họ cam kết thường xuyên miễn là họ đồng bộ hóa bản sao cục bộ của họ với kho lưu trữ chính hàng ngày (vì họ sẽ luôn luôn làm công việc phát triển trong một chi nhánh này sẽ không ảnh hưởng đến người khác).


1
Tôi đã nói cụ thể trong câu hỏi để cho rằng người đó không thể liên lạc được.
Jon Hopkins

@Jon, trong trường hợp đó coi công việc còn dang dở của mình bị mất, giao nó cho một lập trình viên khác, và sau đó bắt đầu suy nghĩ về lý do tại sao điều này xảy ra ở nơi đầu tiên.

Có một mâu thuẫn logic trong đó - "bạn không biết những gì nhà phát triển đang làm" vs "bạn phải ủy thác" có nghĩa là bạn biết những gì ông ấy đang làm nhưng có thể không bao - do đó là lý do tại sao bạn cần phải nhận được vào mã ... (vâng, giao tiếp có thể giúp giải quyết vấn đề này nhưng nếu bạn tin tưởng các nhà phát triển của mình giải quyết vấn đề và một vấn đề nhỏ - đối với một nhà phát triển nhất định - thì "hãy sửa lỗi này, tạm biệt!" Có thể quản lý nhiều như vậy cần thiết).
Murph

@Murph, sau đó thực thi quy tắc "cam kết thường xuyên - trong một chi nhánh" và đẩy vào trung tâm ít nhất là hàng ngày.

1

Vậy làm thế nào để bạn xử lý các tình huống như thế này?

Bạn có thể giải quyết vấn đề này bằng hệ thống kiểm soát nguồn hỗ trợ các nhánh không ổn định cá nhân và bằng cách duy trì các cam kết thường xuyên. Một cam kết không phải đến khi toàn bộ vấn đề được giải quyết. Nó sẽ đến bất cứ khi nào bạn được hưởng lợi từ kiểm soát nguồn. Cuối ngày là một trong nhiều điểm khi một cam kết sẽ xảy ra để bạn có thể thấy nơi thay đổi của mình được thực hiện, sao lưu và giải thích chúng cho bản thân tương lai của bạn hoặc người khác.

Hoặc bạn có yêu cầu các nhà phát triển tuân thủ các tiêu chuẩn trong lĩnh vực này - sử dụng các thư mục cụ thể, tiêu chuẩn đặt tên, ghi chú trên wiki hoặc bất cứ điều gì không?

Chúng tôi có một tài liệu cấu hình môi trường rộng lớn biểu thị các quy ước, nhưng không phải là một tiêu chuẩn. Các tiêu chuẩn dành cho mã sản xuất và môi trường. Tuy nhiên, nhiều công cụ phát triển của chúng tôi được thiết lập để hỗ trợ các quy ước và hầu hết các nhà phát triển không tốn công sức theo xu hướng.

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.