Có thể cho một lập trình viên giỏi chưa bao giờ sử dụng kiểm soát phiên bản? [đóng cửa]

Tôi đang tìm kiếm một lập trình viên chuyên gia để giúp giải quyết một tình huống khó khăn.

Các cuộc phỏng vấn cho đến nay đã gây thất vọng đáng ngạc nhiên. Ứng cử viên sáng giá nhất cho đến nay là một lập trình viên rất có kinh nghiệm, chưa bao giờ sử dụng phần mềm kiểm soát phiên bản.

Vấn đề tự nó có thể không quá nghiêm trọng bởi vì nó là thứ có thể học được trong một thời gian ngắn.

Nhưng có một khía cạnh sâu sắc hơn, khiến tôi lo lắng:

Làm thế nào có thể chủ động phát triển phần mềm trong vòng 10 - 15 năm mà không cần kiểm soát phiên bản?

Có phải thực tế là không tìm kiếm một giải pháp cho vấn đề theo dõi thay đổi là dấu hiệu của một thái độ sai lầm đối với lập trình?

Tôi đã làm việc khoảng 11 năm trong các công ty không sử dụng kiểm soát nguồn. Chúng tôi đã quản lý (chủ yếu bằng cách nhận xét các thay đổi và giữ mã trên máy chủ trung tâm có thể được phục hồi cho đến bất kỳ ngày nào). Chúng tôi không bao giờ thực sự hỏi liệu có cách nào tốt hơn không. Điều đó nói rằng, đây cũng là thời mà tôi có toàn bộ thư viện MSDN ở dạng sách trên bàn.

Vâng, đã có lập trình trước khi có internet.

Tôi đấu tranh để xem làm thế nào bạn có thể dành hơn 10 năm trong ngành mà không phải chạy vào kiểm soát nguồn. Nhưng, tôi sẽ có một số thiện cảm, tôi sẽ tin điều đó là có thể và tôi sẽ không từ chối ứng viên chỉ với một chi tiết đó. Tôi sẽ thăm dò và tìm hiểu làm thế nào các ứng cử viên đã quản lý này.

Ngoài ra, tôi có thể đặt câu hỏi liệu quá trình phỏng vấn của tôi có phải là vấn đề không. Bằng cách nào anh ấy là ứng cử viên tốt nhất? Có kỹ thuật lập trình hiện đại nào khác mà anh ta không có mà tôi chỉ không hỏi đúng câu hỏi không? Nếu tôi hỏi đúng câu hỏi, liệu một ứng cử viên khác có tỏa sáng?

Tuy nhiên, như một lưu ý cuối cùng, đừng ngại từ chối tất cả các ứng cử viên nếu bạn lo lắng. Bắt đầu lại rất tốn thời gian, nhưng việc thuê nhầm người sẽ tốn nhiều thời gian hơn.

Tôi nghĩ rằng nó phụ thuộc vào thái độ của anh ấy. Nếu anh ấy là một lập trình viên rất có kinh nghiệm và là một lập trình viên giỏi, tôi nghĩ anh ấy sẽ có thể nhanh chóng nhận được một hệ thống kiểm soát phiên bản. Anh ta có thể nói về nó theo hai cách:

• Tốt

  Tôi chưa bao giờ sử dụng kiểm soát phiên bản, nhưng tôi rất hào hứng tìm hiểu và có vẻ như nó thực sự sẽ giúp phát triển hiệu quả hơn. Tôi không cần nó nhiều vì tôi đã làm việc trên các dự án một mình.

• Xấu

  Kiểm soát phiên bản chỉ là một từ thông dụng đang dần chết trong ngành công nghiệp. Tôi ở trên kiểm soát phiên bản.

Hãy để tôi cung cấp cho bạn một số quan điểm từ việc phát triển phần mềm trong DOS và Windows trong hơn 20 năm.

Phần mềm kiểm soát phiên bản trong thế giới Windows / PC thường không đáng tin cậy vào đầu những năm 90. Visual Sourceafe (VSS) là về Windows tốt nhất dựa trên một cái nhưng nó có thể kỳ quặc và nhiều lập trình viên ghét nó. Một số đội chỉ đơn giản là không giải trí việc sử dụng của họ sau khi xử lý tình huống này.

Hầu hết các tùy chọn VCS khác tại thời điểm không dựa trên Windows và do đó, hiếm khi được sử dụng trong các nhóm phát triển Windows. Một số trong số đó là các giải pháp đắt tiền và các giải pháp nguồn mở không được chấp nhận dễ dàng như ngày nay.

Trong nhiều trường hợp, vào cuối những năm 90, đầu 00, nếu một nhóm Windows không sử dụng VSS, họ đã không sử dụng bất cứ thứ gì để kiểm soát nguồn ngoài các quy ước nội bộ. Một số trong số họ vẫn không sử dụng VCS bất chấp sự tinh vi của Team Foundation Server (TFS) và các tùy chọn miễn phí tuyệt vời như git và SVN.

Có thể ai đó đã làm việc nhiều năm trong một nhóm phát triển Windows nhỏ trong nhiều năm không sử dụng VCS. Tôi đã phỏng vấn tại và thậm chí đã thực hiện công việc hợp đồng tại một số nơi không sử dụng chúng hoặc điều đó rất khó hiểu về việc sử dụng chúng.

Vì vậy, tôi không nghĩ rằng ứng cử viên thiếu kinh nghiệm của bạn trong lĩnh vực này là 'không' nhưng bạn có thể muốn tìm hiểu sâu hơn về tình huống làm việc trước đây của họ để tìm hiểu lý do tại sao điều này bị thiếu trong kinh nghiệm của họ. Bạn cũng sẽ muốn khám phá thái độ của họ đối với việc kiểm soát phiên bản. Họ có nghĩ rằng đó là một ý tưởng tốt nhưng họ không được phép theo đuổi nó ở vị trí trước đây của họ hay họ nghĩ rằng đó là một sự lãng phí thời gian?

Bạn không thể kiểm soát phiên bản mà không có phần mềm kiểm soát phiên bản? Hỏi làm thế nào họ quản lý mã của họ. Có lẽ đã có một hệ thống trồng tại nhà.

Muốn làm mọi thứ bằng tay, phát minh lại bánh xe và chống lại sự thay đổi không có gì mới đối với lập trình. Bạn có định lướt qua một ứng cử viên sử dụng Visual Source Safe và "chỉ" VSS không?

Khi cố gắng tìm kiếm tài năng, bạn phải có khả năng phân biệt sự khác biệt giữa: không thể, không và không.

Không có lý do gì để không sử dụng kiểm soát phiên bản, ngay cả đối với một dự án nhỏ được phát triển bởi một nhà phát triển duy nhất. Thiết lập kiểm soát phiên bản cục bộ là vượt quá tầm thường, lợi ích rất lớn. Bất kỳ nhà phát triển không biết rằng không thể được coi là tốt cũng như không có kinh nghiệm.

Đối với các công ty nhận thấy kiểm soát phiên bản là "tính mới", điều mà họ không sẵn sàng giới thiệu:

• SCCS đã được phát hành vào năm 1972 ( 40 năm trước )
• RCS đã được phát hành vào năm 1982 ( 30 năm trước ) và nó hoàn toàn là nguồn mở và miễn phí
• CVS được phát hành vào năm 1990 ( 21 năm trước ), cũng hoàn toàn là nguồn mở và miễn phí

Một lập trình viên chưa bao giờ sử dụng kiểm soát phiên bản có lẽ chưa bao giờ hợp tác với các lập trình viên khác. Tôi có lẽ sẽ không bao giờ xem xét việc thuê một lập trình viên như vậy, bất kể thông tin nào khác.

Có vẻ như một lá cờ đỏ không sao, nhưng tìm hiểu sâu hơn về lý do tại sao anh ta không sử dụng nó. Tôi vẫn mong đợi một nhà phát triển solo sử dụng kiểm soát phiên bản, đặc biệt là trong mười năm nữa, nhưng tôi sẽ tha thứ cho nó hơn là khi anh ta làm việc trong một nhóm và thậm chí không bao giờ cố gắng mang lại quyền kiểm soát phiên bản.

Tôi sẽ không tôn giáo về việc thiếu kinh nghiệm kiểm soát phiên bản. Nó chỉ là một công cụ. Cuối cùng, bạn có thể chọn những điều cơ bản của svn hoặc git trong một hoặc hai ngày. Phần còn lại bạn sẽ chọn theo thời gian. Và tôi không thể tin rằng bất kỳ ứng cử viên nửa vời nào cũng không thể phù hợp nếu anh ta làm việc trong môi trường sử dụng kiểm soát nguồn.

Sử dụng kiểm soát nguồn là một thói quen hơn là một kỹ năng. Một người chưa bao giờ sử dụng nó có thể phóng đại những nỗ lực cần thiết và đánh giá thấp những lợi ích thu được. Rốt cuộc, anh đã làm tốt cho đến bây giờ. Chỉ sau khi anh ta thực sự sử dụng kiểm soát nguồn, anh ta sẽ phát triển để đánh giá cao nó.

Câu hỏi bạn nên đặt ra là, làm thế nào anh ta quản lý trong trường hợp không kiểm soát nguồn? Điều này có thể cho bạn biết điều gì đó về anh ấy và cách anh ấy quản lý công việc của mình.

Bạn để lại rất nhiều thông tin về kinh nghiệm của anh ấy.

Về cơ bản, tôi sẽ nói rằng rất có thể một lập trình viên có thể có 10-15 năm kinh nghiệm mà không cần phải biết về kiểm soát phiên bản. Viết mã trong 10 năm không bằng việc không ngừng học các kỹ thuật lập trình mới trong 10 năm.

Tôi còn rất trẻ và tôi đã thấy các kỹ sư phần mềm già và "có kinh nghiệm" có mã mà tôi sẽ không bao giờ muốn chạm vào. Điều đó nói rằng, anh ta có thể rất tài năng, nhưng tôi sẽ đoán từ những thông tin nhỏ cho rằng anh ta không.

Chúc may mắn.

Cá nhân, điều đáng báo động nhất đối với tôi là ứng viên chưa bao giờ gặp phải các hệ thống kiểm soát phiên bản như một khái niệm hoặc đã quyết định rằng nó không đáng để sử dụng. Tôi thấy kịch bản đầu tiên rất khó xảy ra, nhưng nếu đó là trường hợp, thì điều đó dẫn đến việc tôi cho rằng ứng cử viên đã bị cô lập đáng kể trong suốt sự nghiệp của họ, điều này sẽ gây nghi ngờ nghiêm trọng về giá trị của họ như là một phần của một đội. Cụ thể, họ có thể có những khái niệm rất kỳ quái về cách làm một số việc nhất định và không biết bất kỳ cách "đúng" nào để làm việc.

Nếu đó là trường hợp thứ hai, nơi họ đã chủ động quyết định chống lại kiểm soát phiên bản, thì điều đó khiến tôi cho rằng họ sẽ không bao giờ làm việc gì có ý nghĩa, hoặc cực kỳ kiêu ngạo. Hoặc, tốt nhất, họ có những cách thực sự khủng khiếp để duy trì mã như nhận xét các khối và gán mọi dòng mã cho tác giả, ngày tháng và số lỗi.

Tôi đang thấy một số câu trả lời khá phán xét ở đây mà không thực sự tính đến người bị phán xét.

Cá nhân tôi thấy phần mềm kiểm soát phiên bản là một công cụ vô giá. Nhưng, tất cả chúng ta không có sự lựa chọn và kiểm soát về các công cụ và quy trình được sử dụng trong môi trường làm việc của chúng ta. Tôi đã làm việc trong sự phát triển của Windows từ năm 1990. Như được đăng bởi những người khác, vào thời điểm đó, không có sẵn nhiều cho VCS trong Windows. Chúng tôi sẽ không đưa vào các máy chủ UNIX chỉ để có được một VCS. Điều đó làm cho tôi một lập trình viên xấu? Sau này trong sự nghiệp, tôi làm việc cho một công ty với một sản phẩm thương mại thị trường dọc, trong đó kiểm soát phiên bản là một quá trình không phải là một công cụ. Điều đó làm cho tôi một lập trình viên xấu? Ba công việc cuối cùng của tôi đều phụ thuộc rất nhiều vào các công cụ VCS. Điều đó làm cho tôi một lập trình viên tốt?

Sẽ thật tuyệt nếu tất cả chúng ta chỉ được sử dụng các công cụ, ngôn ngữ và công nghệ mới nhất và tốt nhất. Nhưng nghề phát triển phần mềm không phải lúc nào cũng hoạt động như vậy. Có một chút lý tưởng khi nói "Tôi sẽ rời bỏ công việc ngay lập tức, nếu họ không ..." hoặc "Tôi sẽ không bao giờ nhận một công việc không sử dụng ..." hoặc "Tôi sẽ buộc họ sử dụng. .. ". Tất cả chúng ta không bị bao vây bởi một nguồn cung cấp cơ hội việc làm vô hạn, nơi mọi thứ hoạt động chính xác như chúng ta muốn. Chúng tôi có hóa đơn để thanh toán và cần một công việc, vì vậy chúng tôi giải quyết những gì xung quanh chúng tôi.

Cuối cùng, câu trả lời cho câu hỏi của bạn là: Đánh giá lập trình viên này bằng kỹ năng, triết lý và quyết định của anh ta, chứ không phải quyết định (có thể sai lầm) của những người phụ trách trong công việc trước đây của anh ta.

Tôi chưa bao giờ coi mình là một "lập trình viên" cho đến khi tôi bắt đầu kiếm tiền bằng cách làm việc đó một cách chuyên nghiệp.

Tôi đã kiếm được khá nhiều tiền tạo ra các hệ thống khiến khách hàng kiếm được nhiều tiền hơn. Có hay không tôi là một nhà phát triển "tốt" là chủ quan.

Tôi có thể nhanh chóng GSD (Get Something Done), điều này để phát triển web thường làm hài lòng khách hàng của tôi. Họ có thể không thấy một số mã xấu xí đằng sau hậu trường, thiếu bình luận, v.v.

Tôi đã không sử dụng Git và không có hồ sơ Github cho đến năm nay, điều mà tôi cảm thấy là "đằng sau thời đại" về các tiêu chuẩn lập trình viên hiện đại. Tôi cũng mới bắt đầu thực hiện các dự án Rails và Django sau khi chỉ thực hiện PHP, Flash và iOS trong quá khứ. Kể từ khi tôi nhận được hợp đồng phát triển các trang web cho cả khách hàng và cho tôi, không quá khó để học được điều gì mới ở tuổi 30 và vài năm lập trình.

Quá nhiều trong xã hội hiện đại tập trung vào việc theo kịp Jones và quan tâm đến những gì người khác nghĩ. Nếu bạn có thể phá vỡ những xiềng xích đó và xem xét những gì bạn cần cho sự phát triển phần mềm của mình (tốc độ / thời gian để tiếp thị, quản lý tài nguyên được tối ưu hóa, mã tài liệu tốt, khả năng mở rộng, v.v.), thì điều đó có thể quan trọng hơn nhiều so với việc ai đó biết Mercurial, SVN , Git hoặc bất kỳ hệ thống kiểm soát phiên bản nào khác.

Tôi thích hỏi các ứng viên phát triển những gì họ đam mê, hệ thống tuyệt vời nhất họ từng làm theo ý kiến ​​của họ là gì và họ dành thời gian rảnh để phát triển kỹ năng của họ. Nếu mọi người không nâng cao kỹ năng của họ trong thời gian của họ, điều đó làm tôi sợ hơn những thứ khác, nhưng không có nghĩa là nó phải làm bạn sợ.

Tôi nghĩ rằng bạn đã có một số câu trả lời tuyệt vời cho câu hỏi này từ những người ở đây và điều đó sẽ giúp bạn đưa ra quyết định sáng suốt của riêng bạn dựa trên yêu cầu của bạn.

Tôi thấy thật đáng kinh ngạc khi một chuyên gia phần mềm chưa bao giờ sử dụng kiểm soát nguồn và tôi rất lo lắng về việc thuê anh ta.

Ông có kinh nghiệm gì. Tôi sẽ tự hỏi những gì anh ấy không biết rằng cho đến nay bạn không tìm ra.

Kinh nghiệm phát triển phần mềm của bạn là gì? Bạn có thể hỏi anh ấy về kiến ​​trúc, các mẫu thiết kế, các vấn đề phát triển phần mềm phổ biến, câu hỏi về hiệu năng hệ thống, câu hỏi bảo mật hệ thống, v.v.?

Nếu anh ấy trở nên mạnh mẽ với loại công cụ đó, thì có lẽ tôi có thể bỏ qua việc thiếu kiến ​​thức kiểm soát nguồn.

Có thể cho một lập trình viên giỏi chưa bao giờ sử dụng kiểm soát phiên bản?

Đúng. Nhiều công ty nhỏ với các lập trình viên tự học không sử dụng nó.

Làm thế nào có thể chủ động phát triển phần mềm trong vòng 10 - 15 năm mà không cần kiểm soát phiên bản?

Cá nhân tôi đã giới thiệu kiểm soát phiên bản cho 2 công ty nhỏ, đã nâng cấp 1 công ty vừa từ một thứ thần thánh khủng khiếp lên SVN (tùy chọn tốt nhất vào thời điểm đó) và làm việc trong một công ty nhỏ khác chỉ có một số VC, đã viết giải pháp VC của riêng họ cho một số mã và có rất nhiều mã không có trong bất kỳ VC nào.

Có phải thực tế là không tìm kiếm một giải pháp cho vấn đề theo dõi thay đổi là dấu hiệu của một thái độ sai lầm đối với lập trình?

Chà, đó không phải là một thất bại tức thì, nhưng tôi chắc chắn sẽ hỏi rất nhiều câu hỏi tiếp theo. Những thứ như:

Bạn đã bao giờ thử bất kỳ phần mềm VC? Gì? Bạn nghĩ gì về nó? Có bất kỳ lý do bạn sẽ không sử dụng nó? Những gì bạn đã sử dụng trước đây để quản lý mã? Bạn đã từng làm việc với bất kỳ ai trước đây trên cùng một cơ sở mã, và bạn đã sử dụng phương pháp nào để tránh xung đột?

Tôi muốn đồng ý với Thuốc nổ (nhưng đại diện của tôi quá thấp, atm ...) ... thái độ quan trọng hơn nhiều.

Có một vài điều để tìm kiếm, mà tôi tin rằng làm cho chương trình xuất sắc:

1. Giao tiếp
2. Sáng tạo
3. Từ bi (nói gì?)

Và, thường xuyên, nhiều hơn một chút OCD.

Bạn biết loại ... những người ngồi đó giải quyết vấn đề, hoàn toàn đánh mất mã của họ khi họ khám phá các tùy chọn. Đây là những người ghi chú khi họ đi cùng, để lại nhận xét trong mã của họ để đảm bảo rằng họ hiểu các đường dẫn logic của riêng họ (và để làm sáng tỏ chính họ hoặc các lập trình viên khác có thể phải xử lý mã trong tương lai. .. do đó, "lòng trắc ẩn" trong danh sách của tôi ở trên!), và nhanh chóng và rõ ràng truyền đạt những ý tưởng phức tạp cho những người ra quyết định lên chuỗi để các vấn đề có thể được giải quyết một cách hiệu quả.

Một lập trình viên xuất sắc có thể đã bị mắc kẹt trong nhiều năm trong môi trường không mua ý tưởng về VCS, có kinh nghiệm tồi với VCS (a la VSS) khiến họ ngại ngùng khi thử các hệ thống mới, nhưng tôi sẽ đảm bảo rằng một lập trình viên xuất sắc trong tình huống đó vẫn sẽ thiết lập một số thói quen để bảo vệ bản thân khỏi mất tất cả công việc vào một vài lần lặp lại thiết kế tồi.

Do đó, loại lập trình viên phải cẩn thận là người tuyên bố rằng họ không bao giờ cần đến VCS, cũng như bất kỳ biện pháp bảo vệ nào khỏi những vụ lừa đảo không thể tránh khỏi. Thái độ của họ là một trong "tốt, tôi đã xây dựng nó, do đó không thể sai được." Đó là những người tôi sợ hơn bất kỳ người mới ra trường nào, bởi vì một người mới có thể học cách đánh giá cao những điểm mạnh của VCS bởi vì họ nhận ra họ thực sự biết ít như thế nào.

Làm thế nào có thể chủ động phát triển phần mềm trong vòng 10 - 15 năm mà không cần kiểm soát phiên bản?

Nếu anh ta đến từ các đội trường cũ, nơi các dự án nhỏ được quản lý bởi một người duy nhất, điều đó là rất có thể. Anh ta có thể có 10 năm kinh nghiệm trong cùng một bộ công nghệ mà không cần học hỏi và cải thiện bản thân.

Có phải thực tế là không tìm kiếm một giải pháp cho vấn đề theo dõi thay đổi là dấu hiệu của một thái độ sai lầm đối với lập trình?

Nếu ứng viên của bạn đã ở trong môi trường phát triển nhóm (ít nhất 4 lập trình viên trở lên) thì đó là một câu hỏi không quan trọng. Tuy nhiên, có thể có sự phân chia công việc giữa các lập trình viên, làm việc trên các mô-đun chỉ được gán cho họ, điều này có thể làm giảm nhu cầu kiểm soát mã nguồn.

Tuy nhiên, không được nghe về kiểm soát nguồn trong kỷ nguyên internet là tình huống thực sự đáng ngạc nhiên. Vì vậy, tôi sẽ nhìn vào sự sẵn lòng của anh ấy để học những điều mới (liên quan đến môi trường phát triển của bạn) và anh ấy cởi mở với môi trường làm việc năng động như thế nào.

Vấn đề kinh nghiệm và bạn đúng là các cơ chế sử dụng các công cụ kiểm soát nguồn có thể được học khá nhanh. Nhưng bạn có quyền nhìn thấy một lá cờ đỏ.

• Là ứng cử viên của bạn bị cô lập với nghề nghiệp và xu hướng của nó?
• Nhiều khía cạnh khác của làm việc trong một nhóm cũng sẽ cần phải học?

Đối với tôi, vấn đề về kiểm soát phiên bản là một triệu chứng nhiều hơn là bệnh. Nguyên nhân có thể khác nhau, và khá lành tính. Rất nhiều lập trình viên đặc biệt chỉ bắt đầu làm những gì họ nghĩ có ý nghĩa, bắt đầu với một vài cuốn sách về lập trình và không thực hiện một nghiên cứu có hệ thống về phát triển phần mềm. Đôi khi, ngày xưa, các chuyên ngành khoa học máy tính sẽ tốt nghiệp mà không cần sử dụng hệ thống kiểm soát nguồn vì tất cả các dự án của họ là các dự án riêng lẻ và họ đã đến các công ty có quy trình phần mềm chưa trưởng thành.

Tuy nhiên, anh ta đã đến đó, nếu anh ta là một con sói đơn độc trong một thập kỷ trở lên, điều đó có thể khiến việc sống với mọi người trở nên khó khăn.

Có thể đáng để hỏi nếu ứng cử viên của bạn có thêm một vài câu hỏi thăm dò.

• Hãy cho tôi biết về một thời gian bạn làm việc như là một phần của một nhóm?
• Hãy kể cho tôi nghe về một thời gian khi một nhóm bạn làm việc có mâu thuẫn giữa các thành viên trong nhóm?
• Hãy cho tôi biết về một thời gian khi bạn nhận được mã từ một nhà phát triển khác và thực hiện dự án của mình về phía trước?
• Hãy cho tôi biết làm thế nào bạn và các thành viên khác trong nhóm của bạn tránh xa nhau khi tạo mã cùng nhau?
• Hãy cho tôi biết về một khách hàng đã báo cáo sự cố liên quan đến một tính năng đã từng hoạt động, nhưng không hoạt động trong phiên bản mới hơn? Làm thế nào bạn giải quyết nó?
• Bạn thích gì khi làm việc trong một nhóm?

Anh ta cũng có thể quen với việc kiểm soát gần như hoàn toàn các phương pháp, quy trình của mình và ở trong vai trò mà anh ta là chuyên gia phần mềm duy nhất. Bạn sẽ muốn một người nào đó sẽ cởi mở với một cách làm việc mới. Thêm câu hỏi:

• Hãy cho tôi biết về thời gian bạn sử dụng hoặc giúp tạo ra một tiêu chuẩn mã hóa?
• Những loại điều bạn muốn thấy trong một tiêu chuẩn mã hóa?
• Bạn cảm thấy thế nào về việc viết lại mã của người khác?
• Hãy cho tôi biết về một thời gian bạn đã tham gia vào các đánh giá ngang hàng về phần mềm hoặc tài liệu?
• Bạn có thể cho tôi biết về một đề xuất hoặc hợp đồng phát triển phần mềm mà bạn đã tham gia viết không?
• Hãy cho tôi biết về người quản lý hoặc giám sát phần mềm yêu thích của bạn?
• Hãy cho tôi biết về đồng nghiệp yêu thích của bạn hoặc cấp dưới?

Trong năm 2012, đối với một người có 15 năm kinh nghiệm trong ngành chưa bao giờ sử dụng kiểm soát phiên bản là cờ đỏ. Nó có thể không phải là một lá cờ đỏ như vậy nếu năm đó là năm 1982, hoặc thậm chí là năm 1992. Nhưng ngày nay, có một lời giải thích tuyệt vời hơn cho khoảng cách khó hiểu này trong nền tảng của nhà phát triển.

Tình huống bất thường đòi hỏi giải thích phi thường.

Điều này có phần giống như một thợ sửa xe tuyên bố rằng anh ta đã sửa xe trong 15 năm, nhưng bản thân anh ta không bao giờ có quá nhiều vết dầu mỡ.

Tất nhiên, bôi nhọ bản thân bằng mỡ sẽ không khắc phục được đường truyền và không có bước nào trong hướng dẫn sửa chữa gọi cho điều đó, nhưng đó không phải là vấn đề. Vấn đề là việc sạch sẽ không phù hợp với những gì các thợ sửa xe thực sự trông giống như khi họ đang làm việc. Trong công việc đó, bạn có được dầu mỡ trên chính mình.

Nếu bạn đang phỏng vấn ai đó có kinh nghiệm thừa nhận anh ta không có kinh nghiệm kiểm soát phiên bản, anh ta có thể phóng đại hoặc bịa đặt một số kinh nghiệm của mình (và thậm chí không biết rằng kiểm soát phiên bản là thứ được sử dụng rộng rãi và quan trọng, và anh ta cũng nên nói dối! )

Có thể thấy tất cả các loại người thích đùa trong các cuộc phỏng vấn. Tôi đã thấy những người không thể vẽ sơ đồ của một danh sách được liên kết hoặc viết một hàm chèn một nút ở đầu danh sách được liên kết. Tuy nhiên, họ tuyên bố 20 năm kinh nghiệm làm việc.

Ngay cả những sinh viên mới từ khoa học máy tính cũng có thể mong đợi có được sự quen thuộc thụ động với kiểm soát phiên bản, ngay cả khi họ chưa sử dụng rộng rãi nó.

Tôi sẽ thấy lạ, nhưng không phải là không thể đối với một chương trình có kinh nghiệm chưa bao giờ sử dụng kiểm soát nguồn chuyên dụng. Tại một công ty tôi làm việc cùng, họ đã sử dụng kiểm soát nguồn rộng rãi cho mã C # và VB truyền thống của họ. Nhưng mã cơ sở dữ liệu thuần túy (các thủ tục và tập lệnh được lưu trữ cũng như các định nghĩa bảng) không nằm trong kiểm soát nguồn mặc dù có hai Nhà phát triển SQL chuyên nghiệp có công việc chính là viết, duy trì và thực thi mã cơ sở dữ liệu thuần túy. Tôi đã vô địch kiểm soát nguồn cho các thực thể cơ sở dữ liệu ở đó và chỉ thành công một phần.

Tại một công ty khác, nhóm phát triển còn nhỏ (một người đàn ông mua sắm trong một thời gian dài, sau đó hai người). Kiểm soát nguồn của nhà phát triển trước đó có nhiều bản sao của tệp nguồn có ngày được thêm vào cuối. Ngoài việc thiếu một hệ thống kiểm soát nguồn tốt hơn, người tiền nhiệm của tôi chắc chắn có một người đàn ông thông minh và có năng lực.

Trước khi tôi trở nên chuyên nghiệp, tôi là người có sở thích và hoàn toàn không sử dụng bất kỳ kiểm soát nguồn nào, tôi mơ hồ biết đó là gì nhưng không bận tâm.

Nói tóm lại, tôi nghĩ thật kỳ lạ khi một chuyên gia sẽ không quen thuộc với nó, nhưng đặc biệt nếu anh ta quen với các đội rất nhỏ thì chắc chắn có thể thành thạo nếu không có nó. Trong tuyển dụng, tôi sẽ không chống lại anh ta. Tôi hoàn toàn không muốn học và bắt đầu sử dụng nó trong công việc chống lại anh ta mặc dù ...

2c của riêng tôi là nó phụ thuộc vào cách anh ta phản ứng khi được hỏi về VC. Các phản ứng có thể xảy ra là:

1. Huh? Cái gì vậy
2. Không, chúng tôi đã làm thay
3. Không có shuffle xấu hổ , quản lý sẽ không cho phép chúng tôi
4. Không xấu hổ , nhưng tôi đã tự mình điều tra một chút và nghĩ rằng nó trông giống như một việc gì đó chúng ta nên làm.

Trong trường hợp 4, anh chàng sẽ nhận được một đường chuyền từ tôi, anh ta có thái độ đúng đắn và có thể sẽ nhận nó tốt. Trong trường hợp 3, anh ta nhận được tín dụng vì hiểu rằng đó là việc nên làm nhưng không phải là tín dụng nhiều như 4. Nếu anh ta có thể đặt tên cho một vài thông tin thực tế về VC (liệt kê một số gói VC ngoài đó) Tôi ' Tôi lấy đó làm bằng chứng cho sự tò mò và có thể vượt qua anh ta.

Nếu anh ta trả lời 1 hoặc 2, nghĩa là, nếu anh ta biết và không quan tâm đến việc biết về VC, tôi sẽ nghiêm túc đặt câu hỏi cho sự đánh giá của ứng viên. Sẽ có các công cụ khác (theo dõi lỗi, số liệu chất lượng, tự động hóa xây dựng, v.v.) mà anh ấy sẽ cần phải làm việc và có thể bạn sẽ thấy bạn có một trận chiến khó khăn trong tất cả các vấn đề này nếu anh ấy không mở thử cách tiếp cận.

Giống như hầu hết mọi người ở đây, tôi nghĩ sẽ không công bằng khi gây bất lợi cho ứng viên chỉ vì chủ nhân của họ không tăng tốc; Đối với tôi, tất cả phụ thuộc vào cách họ phản ứng với nó.

Viết những gì thay đổi là tốt khi nhìn lại. Nó đã giúp tôi tiết kiệm rất nhiều lần khi nhận ra có gì sai và vô số vấn đề được khắc phục nhanh chóng vì tôi đã viết nó ra. Theo tôi, thật tốt khi giữ một bản ghi. Đặc biệt nếu bạn đang lập trình với nhiều người hơn mình.

Nếu bạn đang viết một ứng dụng web, bạn có thể tiếp tục thêm các hình ảnh không có kiểm soát phiên bản vì bạn liên tục chỉ thêm những thứ mới vào nó. Nhưng có thể bạn sẽ viết một bản ghi hoặc một bài đăng tin tức với những điều mới.

Đó là tất cả về những gì bạn đang lập trình.

Tôi đã làm việc tại các địa điểm nơi quá trình nhận phần mềm được phê duyệt là 12 đến 18 tháng. Nếu nó chưa có trong danh sách các phần mềm được phê duyệt thì không có cách nào để đưa nó vào máy. Ổ đĩa CD / DVD đã bị khóa và các máy không được kết nối với internet.

Nơi đầu tiên tôi chạy vào kiểm soát nguồn giải pháp là để một nhà phát triển tự viết, vào thời điểm nó sẵn sàng để thử nghiệm dự án nhiều năm đang đi xuống. Họ đánh bạc rằng viết nó từ đầu nhanh hơn quá trình phê duyệt.

Vị trí thứ 2 mà tôi gặp phải vấn đề này đã sử dụng kiểm soát nguồn trong vài tháng đầu tiên, nhưng sau đó khách hàng muốn tất cả sự phát triển được thực hiện trên mạng nội bộ của họ. Họ một lần nữa khóa tất cả mọi thứ, vì vậy nó đã trở lại với rất nhiều thư mục được nén.

Tôi biết các nhà phát triển chỉ làm việc trong những điều kiện này. Họ muốn sử dụng những công cụ này, họ rất thích sử dụng những công cụ này, nhưng họ không được phép sử dụng những công cụ này.

Điều tra tại sao họ không sử dụng chúng. Không hiểu các thủ tục vì không có kinh nghiệm, khác xa so với việc từ chối các công cụ.

Tôi đang phát triển trong 15 năm qua. Được sử dụng kiểm soát phiên bản chỉ vài lần. Tôi vẫn đang sử dụng các tập lệnh và chương trình theo lịch trình của riêng mình để sao lưu tất cả các thư mục phát triển. Tôi không biết phải nói gì nếu ai đó hỏi tôi Nếu tôi sử dụng Kiểm soát phiên bản. Tôi chưa bao giờ cần hệ thống kiểm soát phiên bản, tôi luôn làm việc trong các dự án nhỏ. Ý tôi là tôi không phải là lập trình viên giỏi nhất ngoài kia nhưng tôi chắc chắn mình không phải là người tồi tệ nhất. Hầu hết thời gian tôi cảm thấy xấu hổ khi nói với mọi người rằng tôi không thường xuyên sử dụng hệ thống kiểm soát phiên bản, nhưng đó là cách nó phù hợp với tôi.

Phát biểu từ kinh nghiệm của tôi với tư cách là một lập trình viên trên các hệ thống MVS của IBM: trong mười năm đầu tiên trong sự nghiệp làm việc của tôi, hệ điều hành mà tôi đã làm việc có chính xác một loại tệp có thể phiên bản có sẵn cho lập trình viên: bộ dữ liệu thế hệ. Đây thực chất là một tệp có số lượng phiên bản cố định và bạn phải nhớ phiên bản đó là gì - khá vô dụng đối với việc kiểm soát phiên bản hiện đại. Cùng với một hệ thống tập tin không có thư mục thực, chỉ cần nhiều hơn hoặc ít hơn (8 ký tự), khái niệm hệ thống quản lý mã nguồn hoàn toàn xa lạ với bất kỳ ai làm việc trong môi trường đó.

Tôi thực sự không thấy một hệ thống kiểm soát mã nguồn cho đến khi tôi chuyển sang SunOS 3 và phải sử dụng RCS. Vào thời điểm đó, tôi là một lập trình viên hệ thống IBM cực kỳ yếu đuối, năng suất cao và rất giỏi trong công việc. Tất cả các phiên bản đã được xử lý bằng cách sao chép các bản sao lưu vào băng và ghi lại những gì đang ở đâu.

Nếu tôi vẫn đang làm việc trên các máy tính lớn vào thời điểm này, thì hoàn toàn có thể tôi vẫn chưa bao giờ được tiếp xúc với một hệ thống kiểm soát phiên bản chính thức; các lựa chọn thay thế được hỗ trợ cụ thể là ClearCase và Rational, cả hai đều không miễn phí (và thực tế là cả hai đều khá đắt).

Vì vậy, nói rằng ai đó theo định nghĩa là không đủ năng lực bởi vì người đó chưa bao giờ sử dụng kiểm soát phiên bản là một đối số cụ thể. Nó là cần thiết để đào sâu và xem xét các chi tiết. Nếu họ tuyên bố là nhà phát triển hệ điều hành Linux / Unix / Mac nhưng chưa bao giờ sử dụng kiểm soát phiên bản, điều đó sẽ không tốt cho họ và bạn có thể cân nhắc xem liệu trải nghiệm chung của họ có phù hợp đến mức bạn sẵn sàng không đào tạo họ về kỹ thuật phần mềm hiện đại. Nếu họ và lập trình viên máy tính lớn ở trường cũ - và đó là những gì bạn cần - thì hãy tập trung vào việc họ có chính xác các kỹ năng lập trình cần thiết mà bạn muốn hay không, và cam chịu với thực tế là bạn sẽ cần dạy điều này cho họ. Như những người khác đã nói, phản ứng của họ đối với khái niệm này sẽ là yếu tố quyết định trong trường hợp đó.

Khá vui lòng! Toàn bộ cộng đồng của chúng tôi không sống trong các cộng đồng xã hội phát triển cao, nơi các sự kiện táo tợn và các sự kiện hack quá nhiều, chúng tôi cũng không làm việc trong các công ty phát triển phần mềm và một số người trong chúng tôi thậm chí không thể tìm thấy các tài nguyên được xuất bản liên quan hoặc cập nhật bằng ngôn ngữ mẹ đẻ của chúng tôi, được in hoặc trực tuyến, hãy gặp gỡ một lập trình viên bằng xương bằng thịt.

Đối với tất cả những gì tôi có thể hiểu, nếu anh ta là một nhà phát triển phần mềm có kinh nghiệm như bạn nói, thì anh ta có khả năng là một con sói đơn độc làm việc tự do cho các doanh nghiệp nhỏ.

Có một vài lý do có thể không sử dụng kiểm soát phiên bản:

1. Làm việc trong các công ty không phát triển phần mềm là ngành kinh doanh chính của họ.
2. Hoặc nếu nhà phát triển đã quyết định sử dụng một số hệ thống khác - chỉ hợp lệ cho những người có kinh nghiệm.
3. Hoặc nếu nhà phát triển chưa tìm hiểu cách mỗi hệ thống hoạt động
4. Hoặc đó là vấn đề về thái độ đối với các công cụ mà họ không quen thuộc

Nhưng bạn nên cẩn thận khi gặp những người giả định:

1. Rằng chỉ có một cách để làm một cái gì đó
2. Hoặc là mọi lập trình viên phải làm điều đó giống như cách họ đang làm
3. Hoặc là các thực tiễn mọi người đang sử dụng rất dễ thay đổi

Cũng giống như một lập trình viên nghèo là một chuyên gia về kiểm soát phiên bản. Quan điểm của tôi là, tôi không biết kiểm soát phiên bản nào cho kỹ năng lập trình hoặc khả năng giải quyết vấn đề của bạn. Đó là một câu hỏi kinh nghiệm. Nhiều cửa hàng nhỏ hơn không sử dụng nó hoặc để nó cho những người không chuyên (những người thường xuyên làm việc một mình) để tự mình tìm ra.

Tôi nghĩ rằng nó không phải là quá nhiều vấn đề "Làm thế nào là nó có thể chủ động phát triển phần mềm cho 10-15 năm mà không bao giờ cần kiểm soát phiên bản?", Nhưng "Làm thế nào là nó có thể chủ động phát triển phần mềm cho người cuối cùng 10-15 năm mà không bao giờ cần kiểm soát phiên bản? ".

Chắc chắn lập trình là có thể mà không cần kiểm soát phiên bản, nhưng một chuyên gia phải làm quen với tình trạng hiện đại và có thể chọn đúng công cụ để thực hiện công việc. Không sử dụng phần mềm quản lý phiên bản phù hợp làm cho công việc của bạn gặp rủi ro và không đáng tin cậy, và một trong những lý do bạn muốn thuê một nhà phát triển chuyên nghiệp là họ phải có khả năng quản lý rủi ro.

Một cơ sở mã được chú thích chính xác trong một VCS có giá trị hơn nhiều so với cơ sở không có. Lý do cho mọi thay đổi có thể được theo dõi và hiểu rõ, giúp người bảo trì có thể nắm bắt sâu hơn những gì họ cần biết. Không làm điều này là không chuyên nghiệp, và lý do duy nhất cho nó sẽ là nếu anh ấy / cô ấy bị hạn chế bởi các nhà quản lý kém trong công việc trước đây của anh ấy / cô ấy. Ngay cả sau đó, họ không nên sử dụng phiên bản cho các dự án riêng tư của họ?