Làm thế nào để các lập trình viên làm việc cùng nhau trong một dự án?

Tôi luôn lập trình một mình, tôi vẫn còn là sinh viên nên tôi chưa bao giờ lập trình với bất kỳ ai khác, thậm chí tôi chưa sử dụng hệ thống kiểm soát phiên bản trước đây.

Hiện tôi đang thực hiện một dự án đòi hỏi kiến ​​thức về cách các lập trình viên làm việc cùng nhau trên một phần mềm trong một công ty.

Phần mềm được biên dịch như thế nào? Có phải từ hệ thống kiểm soát phiên bản không? Có phải do lập trình viên cá nhân không? Nó có định kỳ không? Đó là khi ai đó quyết định xây dựng hoặc một cái gì đó? Có bất kỳ thử nghiệm nào được thực hiện để đảm bảo rằng nó "hoạt động" không?

Bất cứ điều gì sẽ làm.

Trên thực tế, có nhiều biến thể về các quy trình này như nhiều công ty có. Có nghĩa là: mọi công ty đều có những quy ước khác một chút so với những công ty khác, nhưng có một số phương pháp hay nhất phổ biến thường được sử dụng ở hầu hết các nơi.

Các phương pháp hay nhất luôn hữu ích

• Tất cả mã nguồn của dự án và bất kỳ thứ gì được yêu cầu để xây dựng nó đều nằm dưới quyền kiểm soát phiên bản (còn gọi là kiểm soát nguồn). Bất kỳ ai cũng có thể xây dựng toàn bộ dự án chỉ với một cú nhấp chuột.
  Hơn nữa, các tệp không cần thiết (tệp đối tượng hoặc tệp nhị phân đã biên dịch) không nên được bổ sung vào kho, vì chúng có thể được tái tạo khá dễ dàng và sẽ chỉ lãng phí không gian trong repo.
• Mọi nhà phát triển nên cập nhật và cam kết kiểm soát phiên bản một vài lần mỗi ngày. Hầu hết khi họ đã hoàn thành nhiệm vụ, họ đang làm việc và thử nghiệm nó đủ để họ biết rằng nó không chứa những lỗi nhỏ.
• Một lần nữa: bất kỳ ai cũng có thể xây dựng dự án chỉ với một cú nhấp chuột. Điều này rất quan trọng và giúp mọi người dễ dàng kiểm tra. Lợi thế lớn nếu những người không phải là lập trình viên (ví dụ: ông chủ) cũng có thể làm như vậy. (Điều này khiến họ cảm thấy có thể xem chính xác những gì nhóm đang làm việc.)
• Mọi nhà phát triển nên thử nghiệm tính năng mới hoặc sửa lỗi mà họ đã thêm trước đó những tính năng đó vào kho lưu trữ.
• Thiết lập một máy chủ để cập nhật thường xuyên (trong khoảng thời gian định trước) từ kho lưu trữ và cố gắng xây dựng mọi thứ trong toàn bộ dự án . Nếu không thành công, nó sẽ gửi e-mail cho nhóm cùng với các cam kết mới nhất đến kiểm soát phiên bản (vì cam kết nào mà nó không xây dựng được) để giúp gỡ lỗi.
  Thực hành này được gọi là tích hợp liên tục và các bản dựng còn được gọi là bản dựng hàng đêm .
  (Điều này không ngụ ý rằng các nhà phát triển không nên xây dựng và kiểm tra mã trên máy của chính họ. Như đã đề cập ở trên, họ nên làm điều đó.)
• Rõ ràng là mọi người nên quen thuộc với thiết kế / kiến ​​trúc cơ bản của dự án, vì vậy nếu cần điều gì đó, các thành viên khác nhau trong nhóm không cần phải phát minh lại bánh xe. Viết mã có thể tái sử dụng là một điều tốt.
• Cần có sự giao tiếp nào đó giữa các thành viên trong nhóm. Mọi người nên biết những gì những người khác đang làm, ít nhất là một chút. Càng nhiều càng tốt. Đây là lý do tại sao dự phòng hàng ngày hữu ích trong các nhóm SCRUM.
• Kiểm thử đơn vị là một thực tiễn rất tốt giúp kiểm tra chức năng cơ bản của mã của bạn một cách tự động.
• Một phần mềm theo dõi lỗi (đôi khi được gọi là phần mềm theo dõi thời gian ) là một phương tiện rất tốt của việc theo dõi những gì đang có lỗi và những gì nhiệm vụ các thành viên trong nhóm khác nhau có. Nó cũng tốt cho việc thử nghiệm: những người thử nghiệm alpha / beta trong dự án của bạn có thể giao tiếp với nhóm phát triển theo cách này.

Những điều đơn giản này đảm bảo rằng dự án không nằm ngoài tầm kiểm soát và mọi người đều làm việc trên cùng một phiên bản mã. Quá trình tích hợp liên tục hữu ích khi có điều gì đó tồi tệ nghiêm trọng.

Nó cũng ngăn mọi người gửi nội dung không được xây dựng vào kho lưu trữ chính.
Nếu bạn muốn bao gồm một tính năng mới sẽ mất nhiều ngày để triển khai và nó sẽ chặn người khác xây dựng (và thử nghiệm) dự án, hãy sử dụng tính năng nhánh của kiểm soát phiên bản của bạn.

Nếu điều đó vẫn chưa đủ, bạn cũng có thể thiết lập nó để thực hiện kiểm tra tự động, nếu điều đó là có thể với dự án được đề cập.

Một số suy nghĩ thêm

Danh sách trên thoạt nhìn có thể rất nặng. Tôi khuyên bạn nên làm theo nó khi cần thiết : bắt đầu với kiểm soát phiên bản và trình theo dõi lỗi, sau đó thiết lập máy chủ tích hợp liên tục, nếu bạn cần. (Nếu đó là một dự án lớn, bạn sẽ cần nó rất sớm.) Bắt đầu viết các bài kiểm tra đơn vị cho những phần quan trọng nhất. Nếu vẫn chưa đủ, hãy viết thêm chúng.

Một số liên kết hữu ích:
Tích hợp liên tục , Bản dựng hàng ngày là bạn của bạn , Kiểm soát phiên bản , Thử nghiệm đơn vị

Ví dụ:

Để kiểm soát phiên bản, tôi có xu hướng sử dụng Git cho các dự án cá nhân của mình ngày nay. Subversion cũng phổ biến và chẳng hạn, VisualSVN khá dễ thiết lập nếu bạn sử dụng máy chủ Windows. Đối với khách hàng, TortoiseSVN hoạt động tốt nhất cho nhiều người. Dưới đây là so sánh giữa Git và SVN.

Đối với phần mềm theo dõi lỗi, Jira và Bugzilla rất phổ biến. Chúng tôi cũng đã sử dụng Mantis tại nơi làm việc trước đây.

Đối với phần mềm tích hợp liên tục, có Teamcity cho một (cũng đáng chú ý là CruiseControl và đối tác .NET của nó ).

Trả lời cho câu hỏi của bạn "ai là người quyết định thiết kế chính của dự án?"

Tất nhiên, đó sẽ là nhà phát triển hàng đầu.
Trong các công ty, nhà phát triển chính là người nói chuyện với nhân viên tài chính / tiếp thị của dự án và quyết định hình ảnh dựa trên khả năng tài chính của công ty, các tính năng được lên kế hoạch theo yêu cầu của người dùng và thời gian khả dụng.

Đây là một nhiệm vụ phức tạp và thường có nhiều người tham gia. Đôi khi các thành viên của nhóm cũng được yêu cầu tham gia hoặc động não về thiết kế của toàn bộ dự án hoặc các bộ phận cụ thể.

Tôi cũng là một sinh viên, người đã hoàn thành một khóa học kỹ thuật phần mềm gần đây, nơi toàn bộ học kỳ bao gồm một dự án nhóm khổng lồ. Hãy để tôi bắt đầu bằng cách nói rằng chúng tôi có thể đã làm với 3 người những gì mà 12 người trong chúng tôi phải mất cả học kỳ để làm. Làm việc với mọi người là một điều khó khăn. Giao tiếp là chìa khóa.

Chắc chắn sử dụng một kho lưu trữ. Mỗi người có thể truy cập từ xa tất cả các mã và thêm / xóa / thay đổi bất kỳ thứ gì. Nhưng phần tốt nhất của lật đổ là nếu ai đó phá vỡ mã, bạn có thể hoàn nguyên về phiên bản cũ hơn và đánh giá xem điều gì đã xảy ra từ đó. Tuy nhiên, giao tiếp vẫn là chìa khóa, hãy biết đồng đội của bạn đang làm gì để không xảy ra xung đột. Đừng ngồi trên mã của bạn, hãy thực hiện các cam kết nhanh chóng, có ý nghĩa để kho lưu trữ có hiệu quả nhất.

** Tôi cũng muốn giới thiệu một trình theo dõi lỗi, chẳng hạn như Redmine. Bạn có thể thiết lập tài khoản cho mọi người và giao nhiệm vụ cho mọi người với các mức độ ưu tiên khác nhau, đồng thời theo dõi và xem liệu mọi người đã quan tâm đến một số vấn đề nhất định chưa hoặc nếu có vấn đề khác.

Và, như đã nói trước đây, kiểm thử đơn vị sẽ giúp ích rất nhiều. May mắn nhất! Hy vọng điều này đã giúp :-)

Những điều quan trọng là:

• Một kế hoạch - Nếu mọi người không biết họ đang đi đâu, họ sẽ không đi đâu cả. Do đó, sự khởi đầu của bất kỳ dự án nào cũng cần một vài người (thường là những chú râu xám của dự án) tham gia một cuộc họp và đưa ra một kế hoạch; kế hoạch không cần quá chi tiết, nhưng nó vẫn được yêu cầu.
• Hệ thống kiểm soát phiên bản - Nếu không có điều này, bạn sẽ không làm việc cùng nhau. Bạn cũng cần có sự cam kết chắc chắn rằng nếu những điều không được cam kết, chúng sẽ không được tính. “Ồ, nó nằm trong một trong những hộp cát của tôi” chỉ là một cái cớ khập khiễng.
• Trình theo dõi sự cố - Bạn không thể theo dõi những điều này bằng các thư mục email. Chắc chắn phải được hỗ trợ cơ sở dữ liệu.
• Hệ thống thông báo - Mọi người cần biết khi nào mọi thứ được cam kết với mã mà họ duy trì hoặc nhận xét được đưa ra cho các lỗi mà họ chịu trách nhiệm. Email có thể làm việc này, IRC cũng vậy (tất nhiên là với điều kiện mọi người đều sử dụng nó).
• Xây dựng hệ thống - Điều này xảy ra như thế nào không thực sự quan trọng , miễn là với một hành động, bạn có thể có được một bản xây dựng hoàn chỉnh về trạng thái hiện tại của mọi thứ, cả hộp cát phát triển của bạn và kho lưu trữ chính. Tùy chọn tốt nhất cho việc này phụ thuộc vào (các) ngôn ngữ bạn đang sử dụng.
• Bộ thử nghiệm - Bộ thử nghiệm giúp mọi người tránh những lỗi ngớ ngẩn. Nó cần phải dễ chạy như bản dựng (là một phần của bản dựng là tốt ). Lưu ý rằng các thử nghiệm chỉ là sự thay thế thô thiển cho tính đúng đắn, nhưng chúng tốt hơn rất nhiều so với không có gì.

Cuối cùng, bạn cần sẵn sàng làm việc cùng nhau để hoàn thành kế hoạch. Đó thường là phần khó khăn.

Nói chung, bạn không nên kiểm tra các hiện vật xây dựng vào kho lưu trữ. Kho lưu trữ sẽ chứa cây nguồn, cấu hình xây dựng, v.v. - bất cứ thứ gì được viết bởi con người. Các kỹ sư phần mềm sẽ kiểm tra một bản sao mã của họ trên hệ thống tệp cục bộ của họ và xây dựng nó cục bộ.

Một thực tiễn tốt là có các bài kiểm tra đơn vị được chạy như một phần của quá trình xây dựng. Bằng cách này, một nhà phát triển sẽ biết ngay lập tức nếu các thay đổi của họ đã làm mất hiệu lực của bất kỳ bài kiểm tra đơn vị nào và sẽ có cơ hội sửa chúng trước khi kiểm tra các thay đổi của mình.

Bạn có thể muốn xem tài liệu về hệ thống kiểm soát phiên bản (một trong số Subversion, CVS, Git, v.v.) và hệ thống xây dựng (ví dụ: trong Java có Ant và Maven).

cách các lập trình viên làm việc cùng nhau trên một phần mềm trong một công ty

Các nhà phát triển không bao giờ làm việc theo nhóm. Các đội hút. Dilbert hài hước không phải vì anh ấy là một nhân vật hài hước như Goofy. Anh ấy hài hước vì anh ấy là người thật và mọi người nhận ra những tình huống mà anh ấy đang gặp phải.

Không có tiêu chuẩn nào cho những điều bạn đang hỏi. Đúng hơn, có những quy ước và những quy ước này phụ thuộc nhiều vào quy mô và sự trưởng thành của tổ chức. Nếu bạn đang ở trong một tổ chức nhỏ, chẳng hạn như một vài lập trình viên, thì mọi thứ có thể sẽ hơi không chính thức với các nhà phát triển cá nhân thực hiện viết mã, xây dựng và thử nghiệm.

Trong các tổ chức lớn hơn, có thể có một kỹ sư xây dựng và quy trình chuyên dụng. Loại tổ chức này thường sẽ thực hiện xây dựng chính thức một cách thường xuyên, chẳng hạn như mỗi ngày một lần, sử dụng bất kỳ mã nguồn nào được kiểm tra. Quá trình này cũng thường bao gồm BVT (Build Validation Tests) và có lẽ một số thử nghiệm hồi quy. Các nhà phát triển sẽ kiểm tra mã từ kho lưu trữ, làm việc trên phần của riêng họ cục bộ, sau đó kiểm tra nó.

Trong các tổ chức lớn nhất, như Microsoft hoặc Google, họ sẽ có một nhóm hoàn toàn chuyên dụng và phòng thí nghiệm đầy đủ sẽ xây dựng trên cơ sở ít nhiều liên tục, làm cho kết quả của mỗi lần chạy đều có sẵn. Các tổ chức này có các quy trình và thủ tục rất chính thức về những gì được đăng ký và khi nào, quy trình xem xét mã là gì, v.v.

Không có sách dạy nấu ăn nào để làm việc với phát triển phần mềm, nhưng nói chung hệ thống kiểm soát phiên bản phải là trung tâm của hệ thống xây dựng của bạn, ngay cả khi bạn đang làm việc trong một dự án mà bạn là nhà phát triển duy nhất. Ngay cả trong trường hợp này, việc có thể hoàn nguyên các phiên bản và đọc nhật ký phiên bản cũng rất đáng hoan nghênh trong việc sửa lỗi. Đây không phải là tính năng duy nhất của hệ thống kiểm soát phiên bản, nhưng chỉ điều này cũng đủ chứng minh cho việc cài đặt, cấu hình và duy trì hệ thống kiểm soát phiên bản.

Việc xây dựng có thể được thực hiện bởi từng nhà phát triển khi thêm mã mới hoặc định kỳ bởi "máy chủ xây dựng". Cách tiếp cận cuối cùng yêu cầu nhiều thiết lập hơn, nhưng giúp tìm ra lỗi bản dựng sớm hơn.

Câu trả lời ngắn gọn - "Nó phụ thuộc".

Hiện tại, tôi đang thực hiện một dự án của chính mình, vì vậy tôi là người xây dựng / sử dụng VCS. Tôi biết những nơi khác mà bạn có các nhóm làm việc cùng nhau trong dự án qua email rùng mình . Hoặc các đội lớn (+5) sử dụng VCS.

Lưu ý rằng, tôi thực sự khuyên bạn nên học ít nhất một số VCS và Joel Spolsky có một hướng dẫn giới thiệu tuyệt vời cho Mercurial. Bazaar (lựa chọn cá nhân của tôi) cũng tương tự, và sau đó Git là gần nhất tiếp theo về mức độ tương tự, nhưng có lẽ phổ biến hơn một trong hai (ít nhất là ATM). Sau đó, bạn có SVN là khá yếu so với.

Trên thực tế, Joel nói về hầu hết các câu hỏi của bạn - tôi khuyên bạn nên đọc 10 năm tài liệu lưu trữ mà anh ấy có - tất cả đều là thông tin rất hữu ích và hầu hết đều phù hợp với tình hình hiện tại và tương lai gần của bạn.

Lập trình phù hợp là một điều sâu sắc được hưởng lợi rất nhiều từ kinh nghiệm. Lập trình theo cặp giống như chạy nhiều bộ xử lý nhận biết ... một người có thể bỏ qua thứ gì đó mà người kia nhìn thấy và miễn là họ đang giao tiếp thì nó có thể dẫn đến tiến bộ vượt bậc.

Trước hết, các nhóm làm việc bằng cách sử dụng các kho lưu trữ (có thể là kiểm soát phiên bản chuyên nghiệp hoặc chỉ một loạt các thư mục được coi là 'sống', tuy nhiên hệ thống kiểm soát sửa đổi là tiêu chuẩn trên thực tế). Ngoài ra, chiến lược quản lý dự án như thế nào phụ thuộc vào cách bạn làm việc (thác nước, nhanh nhẹn, v.v.). Nếu bạn làm việc lặp đi lặp lại, bạn xây dựng các thành phần / plugin / mô-đun / thư viện có khả năng tự duy trì và bạn thực hiện kiểm thử đơn vị cho đến khi nó được ký kết là hoàn thành. Là một nhóm, bạn làm việc theo nhóm có nghĩa là bạn không làm việc trên toàn bộ dự án ở mọi nơi cùng một lúc. Thay vào đó, bạn nhận được một nhiệm vụ để thực hiện bên trong một khu vực của dự án. Đôi khi, bạn phải sửa mã không phải của mình, nhưng điều đó thường xảy ra khi một hành vi lạ xảy ra. Về cơ bản, bạn đang thực hiện kiểm tra các phần bạn phát triển.

Hãy để tôi kiểm chứng điều này cho bạn. Bạn đang ở bên trong một đội công nhân xây dựng. Kiến trúc sư đưa ra một kế hoạch cho một tòa nhà, quản đốc xem xét những gì cần thiết để xây dựng và sau đó thuê những người xây dựng. Người thợ xây tường, kiểm tra độ chắc chắn và dán chúng lên thật đẹp. Thợ điện đi tất cả hệ thống dây điện bên trong tòa nhà để dòng điện có thể chạy qua. Mỗi người có công việc riêng của họ. Đôi khi, thợ điện có thể muốn thảo luận với thợ xây xem có thể chạm khắc những bức tường nào đó hay không, nhưng phải luôn kết hợp với quản đốc.

Tôi hy vọng đây là một số giúp đỡ cho bạn!

Thông thường, hệ thống điều khiển nguồn chứa mã nguồn và thường không có mã nhị phân. Nếu bạn muốn xây dựng và chạy nó, bạn sẽ kiểm tra mã và xây dựng nó trên máy cục bộ của mình.

Một số nơi chạy các bản dựng hàng đêm để đảm bảo mọi thứ hoạt động. Thậm chí có thể có một số kiểm tra tự động được chạy phía máy chủ. Nếu quá trình xây dựng hoặc bất kỳ thứ gì khác không thành công, một người nào đó sẽ được thông báo tự động.

Phần giới thiệu hay về phương pháp sử dụng kiểm soát nguồn là Kiểm soát nguồn của Eric Sink HOWTO http://www.ericsink.com/scm/source_control.html

Trong các ví dụ của mình, anh ấy sử dụng SourceGear Vault kể từ khi anh ấy viết nó và tất cả, nhưng các phương pháp có thể được áp dụng cho các hệ thống kiểm soát phiên bản khác.

Đây lại là một lý do chính đáng tại sao người ta nên xem xét các dự án Nguồn mở.

Các nhà phát triển hàng đầu làm việc trong các dự án OpenSource lớn (như Chromium, Mozilla Firefox, MySQL, Phần mềm Gnu Phổ biến) là những người chuyên nghiệp. Họ có nhiều kinh nghiệm và những dự án này đã phát triển qua nhiều năm với ý tưởng từ hàng trăm chuyên gia như vậy.

Mọi thứ mà những người khác đề cập trong câu trả lời của họ (Kế hoạch, Hệ thống kiểm soát phiên bản, Trình theo dõi vấn đề, Hệ thống thông báo, Hệ thống xây dựng, Bộ thử nghiệm,) đều có thể tìm thấy trong các dự án OpenSource này.

Nếu bạn thực sự muốn trải nghiệm thực tế, tôi thực sự khuyên bạn nên xem qua một số dự án OpenSource phổ biến và lớn, sau đó lấy Nguồn từ bất kỳ dự án nào (sử dụng Kiểm soát phiên bản) và tự xây dựng nó.

Tái bút: Tôi cũng là một sinh viên và tham gia vào các dự án OpenSource là điều tốt nhất tôi từng làm trong đời. Hãy tin tôi! bạn cũng sẽ cảm thấy như vậy.