Làm thế nào để thực hiện một quá trình phát triển với sinh viên đại học


9

Ở công việc đầu tiên của tôi là một nhà phát triển phần mềm, nhóm của tôi đã sử dụng agile / scrum để quản lý quy trình làm việc dự án của chúng tôi và nó hoạt động khá tốt. Tôi đã có một số cố vấn có kinh nghiệm đã đưa tôi đi đúng hướng - tôi nợ họ một khoản nợ lớn của lòng biết ơn. Tôi đã làm việc ở đó một vài năm, sau đó chuyển sang một cơ hội mới vài tháng trước.

Nhanh chóng chuyển tiếp đến công việc hiện tại của tôi. Tôi làm việc tại một trường đại học dưới sự chỉ đạo của giáo sư. Vì tôi ở trường đại học, gần như mọi lập trình viên đều là sinh viên (họ rẻ và dồi dào!) Sếp tôi có kinh nghiệm quản lý, nhưng không phát triển phần mềm và nhóm phần mềm không phải luôn đi đầu trong suy nghĩ của sếp tôi . Những điều kiện này đã tạo ra môi trường hoàn hảo để tạo ra một số phần mềm chất lượng rất kém. Các dự án phần mềm dường như chạy một chút bất hảo, không có ý tưởng thiết kế và đã sử dụng một số thực tiễn thực sự đáng sợ. Tôi biết mọi thứ có thể tốt hơn.

Tôi muốn thực hiện quy trình phát triển để giúp mọi người đi đúng hướng, tăng chất lượng mã và triển khai phần mềm ổn định hơn. Tôi chỉ không chắc bắt đầu từ đâu.

Tôi không tìm kiếm các câu trả lời như "Sử dụng Scrum", "Thiết lập bảng kanban" hoặc "Hãy xem nhanh!" (mặc dù ý tưởng được đánh giá cao). Cụ thể hơn, tôi hy vọng sẽ hiểu rõ hơn về cách thực hiện quy trình phát triển cho môi trường làm việc này . Nhân viên thường làm việc từ 1 đến 2 năm trước khi chuyển đi, thường không có kinh nghiệm và các cuộc họp thường trực hàng ngày bao gồm tất cả mọi người gần như không thể lên lịch.

Làm thế nào để một người bồi dưỡng chất lượng, hiệu quả và giao tiếp ở nơi làm việc như vậy?

Cập nhật: Sau khi đọc một số câu trả lời và nhận xét, tôi nghĩ rằng tôi sẽ cung cấp một số nền tảng bổ sung.

Tôi sẽ không xem mình là một bậc thầy trong việc nghệ thuật phát triển phần mềm, nhưng tôi đủ kinh nghiệm để nhận ra lập trình xấu khi tôi nhìn thấy nó. Tôi có thể xác định xem một nhà phát triển có tài năng hay không sau khi dành chỉ một hoặc hai phút làm việc với họ. Tôi thoải mái với khả năng của mình để tìm cách giải quyết vấn đề một cách thông minh , tuy nhiên, lĩnh vực tôi thực sự thiếu kinh nghiệm là quản lý dự án nơi các nhà phát triển khác tham gia (đó là lý do tại sao tôi ở đây hỏi tất cả những người tuyệt vời của bạn khuyên bảo).

Tôi làm cho nó có vẻ như mọi sinh viên đến văn phòng này là một dimwit hoàn chỉnh. Có một số trứng xấu ở đây, nhưng phần lớn các sinh viên tôi từng gặp đều thông minh, muốn học hỏi và đam mê công việc. Một số chỉ mới bắt đầu, và họ không biết những gì họ không biết. Và thế là ổn. Khi tôi mới bắt đầu lập trình, tôi không khá hơn!


Các nhà phát triển có chịu trách nhiệm cho QA của riêng họ không?
Svidgen

Khi một dự án xuất hiện, các nhà phát triển được đưa ra một loạt các yêu cầu và từ thời điểm đó, mọi thứ đã phụ thuộc vào họ. Vì vậy, hỏi xem các nhà phát triển có chịu trách nhiệm cho câu hỏi và trả lời của họ không giống như đưa cho trẻ một khẩu súng và hỏi liệu đứa trẻ đó có chịu trách nhiệm xử lý an toàn vũ khí không.
bóng tối

Vì vậy, tôi cho rằng chúng ta đang nói về một nhóm các nhà phát triển sinh viên bán thời gian? Còn bạn? ... Có bất kỳ nhà phát triển toàn thời gian hoặc cao cấp nào (> = 10 năm kinh nghiệm) trong nhóm không?
Svidgen

Có một vài nhà phát triển toàn thời gian làm việc từ xa, nhưng chúng tôi không thấy họ nhiều (hoặc cả). Trong văn phòng, vâng, nhân viên đều là sinh viên bán thời gian. Tôi hiện đang làm việc toàn thời gian, nhưng sớm bắt đầu một chương trình Thạc sĩ, do đó có thể thay đổi;) Tôi có 5 năm kinh nghiệm, không có nhiều kinh nghiệm quản lý dự án.
bóng tối

Chưa có thời gian cho câu trả lời đầy đủ. Nhưng, chỉ cần một điều cần xem xét: Tôi đã viết mã được khoảng 20 năm. Ít nhất 10 năm trong môi trường chuyên nghiệp, trong số những người có trình độ khá cao cấp khác. Sự đa dạng trong những gì các nhà phát triển phần mềm có kinh nghiệm gọi là mã "tốt" và "xấu" là rất lớn . Bước đầu tiên tốt có thể là làm rõ những gì làm cho mã "tốt" hoặc "xấu" theo cách có thể cung cấp ranh giới trong đó thử nghiệm được khuyến khích, sáng tạo và đổi mới được khen thưởng, và kinh nghiệm và ý kiến của bạn được thừa nhận là có giá trị, nhưng cuối cùng bị hạn chế .
Svidgen

Câu trả lời:


4

Phải mất nhiều thời gian để làm sạch một sai lầm hơn để kiểm tra trước nó. Nếu bạn đang làm việc với các nhà phát triển (có thể) không có kỹ năng hoặc không biết về thực tiễn tốt, điều đó có nghĩa là họ sẽ không thể thay đổi cơ sở mã (chính) cho đến khi mã của họ được xem bởi người có kinh nghiệm.

Bạn không muốn giải thích về phương pháp luận, vì vậy hãy để tôi lướt qua phần đó: sử dụng các tác vụ nhanh để thiết lập các tính năng khác nhau có thể được phát triển độc lập.

Bắt đầu sử dụng các nhánh tính năng, để mọi người làm việc trên một nhánh riêng biệt. Khi một tác vụ kết thúc, nhà phát triển không thể hợp nhất mã của họ với nhánh chính. Nếu bạn đang sử dụng Git, họ vẫn có thể khởi chạy yêu cầu kéo. Mặt khác, sử dụng bất kỳ phương pháp nào để theo dõi các tác vụ đã hoàn thành (/ chi nhánh) mà bạn thích.

Sau đó, chúng tôi nhận được để quá trình xem xét . Điều bạn thắc mắc là hơi mơ hồ về việc liệu có những nhà phát triển có kinh nghiệm mà khả năng phán đoán của họ có thể được tin tưởng hơn sinh viên hay không. Vì vậy, hãy để tôi giải thích một trong hai cách:

Nếu có các nhà phát triển có kinh nghiệm, hãy giao nhiệm vụ cho họ xem xét mã của các tác vụ đã hoàn thành. Nếu nó tốt, họ có thể hợp nhất nó vào nhánh chính. Nếu không, họ có thể tự cấu trúc lại hoặc đưa ra phản hồi cho nhà phát triển về những gì cần cải thiện.

Nếu không có nhà phát triển có kinh nghiệm, thì bạn sẽ luôn gặp vấn đề. Nếu không có ai phát hiện ra mã tốt từ mã xấu, thì không thể theo kịp chất lượng mã.
Điều tốt nhất bạn có thể làm là có các cuộc họp đánh giá, nơi các nhà phát triển trình bày và giải thích việc triển khai của họ trước các nhà phát triển khác. Mặc dù điều này không thể đảm bảo ngăn chặn mọi vấn đề (ví dụ: nếu tất cả các nhà phát triển có cùng quan niệm sai về thực tiễn tốt, thì nó vẫn sẽ ngăn chặn phần lớn các vấn đề (ví dụ: nếu ít nhất một nhà phát triển có ý tưởng đúng và có thể nêu rõ vấn đề; từ các nhà phát triển hiểu vấn đề khác nhau)

Làm thế nào để một người bồi dưỡng chất lượng, hiệu quả và giao tiếp ở nơi làm việc như vậy?

  • Chất lượng - Xem lại mã bởi các nhà phát triển có kinh nghiệm. Trong trường hợp không có các nhà phát triển có kinh nghiệm, hãy làm cho nó trở thành một đánh giá nhóm để ít nhất bao quát các cơ sở của bạn tốt nhất có thể.
  • Hiệu quả - Nếu bạn đặt các nhiệm vụ độc lập một cách chính xác, bạn sẽ giảm thiểu mọi người phải chờ đợi nhau. Trong một môi trường mà không phải ai cũng có sẵn cùng một lúc, tôi cho rằng bạn đang phải đối mặt với rất nhiều sự chậm trễ "chờ đợi người A". Theo dõi các nhà phát triển không đạt được tiến bộ, chỉ để kiểm tra xem họ có cần giúp đỡ hay thậm chí chỉ cho phép họ trút nỗi bực dọc (những sự thất vọng đó có thể tiết lộ những quan niệm sai lầm về các vấn đề có thể tránh được).
  • Giao tiếp - Đặt chính sách mở cửa để các nhà phát triển có thể nhờ ai đó giúp đỡ, phản hồi hoặc truyền cảm hứng. Trong trường hợp không có người cố vấn có trình độ, hãy cố gắng tạo điều kiện cho sự tương tác của nhóm (tất nhiên bạn vẫn có thể làm điều này ngay cả khi bạn có sẵn người cố vấn, nhưng tầm quan trọng của việc làm đó tăng lên khi không có người cố vấn). Đặc biệt trong tình huống mọi người làm việc từ xa và theo lịch trình khác nhau, các nhà phát triển thường không gần gũi với đồng nghiệp của họ và có xu hướng không giao tiếp với nhau. Ngay cả một số ít các cuộc tụ họp xã hội cũng có thể làm nên điều kỳ diệu để cải thiện giao tiếp liên quan đến công việc vào những thời điểm khác.

Có một số câu trả lời tốt, nhưng đây là cách thấu đáo và trực tiếp nhất, cảm ơn!
bóng tối

1
Đây là gần nhưng không hoàn toàn ở đó. Tôi đồng ý với các đánh giá mã nhưng tôi không đồng ý với nhà phát triển có kinh nghiệm thực hiện các sửa lỗi này thiết lập một vòng phản hồi cực kỳ tồi tệ, nơi các lập trình viên trượt dốc nhất đã quét sạch các lập trình viên có kinh nghiệm với công việc nhanh hơn họ có thể làm sạch nó. Tốt hơn nhiều để gửi các đánh giá trở lại cho lập trình viên ban đầu và để họ thực hiện công việc. Điều này đạt được mục đích dạy cho họ cách viết mã tốt hơn, nhưng nó cũng có lợi ích làm chậm các bộ mã hóa cẩu thả bằng cách làm chậm chúng trong quá trình làm lại cho đến khi họ sản xuất phần mềm theo tiêu chuẩn chấp nhận được.
đánh dấu

@mcottle Bạn đang phản bác một điểm tôi chưa bao giờ thực hiện. Tái cấu trúc không giống như sửa chữa. Nếu mã không hoạt động, nó cần phải được gửi lại, như bạn đã nói. Nếu vấn đề là một đối số phong cách nhỏ, việc chuyển tiếp lại cho nhà phát triển vẫn rất quan trọng, nhưng đôi khi việc sửa nó lại dễ dàng hơn thay vì phải giải thích chi tiết. Nó có lợi ích là bạn có thể hiển thị deceloper mã được cải tiến để họ thấy ý của bạn.
Flater

8

Điều lớn nhất đối với loại môi trường nơi mọi người mới và có khả năng rời đi là các đánh giá mã bắt buộc.

Họ giúp truyền bá kiến ​​thức về những gì nên được thực hiện. Chúng giúp ngăn chặn mã xấu nhất xâm nhập vào cơ sở mã. Họ thúc đẩy tính nhất quán trong việc thực hiện.

Bởi vì với nhiều doanh thu và thiếu kinh nghiệm, giao tiếp quan trọng hơn bình thường.


2
Tôi thực sự có một chút hoài nghi về điều này. Tôi không đồng ý rằng cần phải đánh giá mã ... Nhưng, bạn đang nói về một nhóm các nhà phát triển không biết gì về yêu cầu phản hồi từ các nhà phát triển không biết gì khác - trừ khi bạn nghĩ OP có thời gian để xem xét và để lại nhận xét về mọi thứ . .. Ý tôi là. Có lẽ nó không quá xa vời. Phụ thuộc vào dòng vào. Nhưng, "đánh giá mã" dường như không (với tôi) giống như hơn một phần tư giải pháp. Ý tôi là, tốt nhất
Svidgen

@svidgen: Tôi không nghĩ anh ấy ủng hộ đánh giá của các nhà phát triển không biết gì khác. Anh ấy không bao giờ chỉ định rõ ràng (vì vậy nó có thể đi theo bất kỳ cách nào), nhưng theo kinh nghiệm của tôi, các đánh giá xảy ra phổ biến hơn bởi các đồng nghiệp có kinh nghiệm hoặc những người trong chuỗi (nhà phát triển chính), đặc biệt là trong trường hợp một số khả năng của nhà phát triển bị phát hiện hoặc chưa được chứng minh
Flater

1
@svidgen - ban đầu họ có thể cần được thực hiện bởi người dẫn đầu, nhưng có một thuyền tải hoặc nhà phát triển không biết gì là vấn đề. Bạn không giải quyết điều đó mà không làm cho một số không phải là không biết gì. Lý tưởng nhất, sẽ có một vài nhà phát triển nhận được nó và sau đó có thể giúp thực hiện đánh giá mã trên các công cụ ít quan trọng hơn.
Telastyn

2

Nhiều ý tưởng hơn là một giải pháp, nhưng hãy tìm một phần quan trọng của cơ sở mã có chứa các tính năng và yếu tố tương tự cho các dự án mà các nhà phát triển sinh viên của bạn có thể làm và dọn dẹp RẤT tốt. Một vấn đề lớn với các nhà phát triển mới là họ không biết các quy tắc và quy ước của cơ sở mã, và họ sẽ xem xét các mã khác để có ý tưởng về cách thiết lập riêng. Có rất nhiều nhà phát triển mới làm việc trong một cơ sở mã lộn xộn có nghĩa là họ sẽ thấy sự lộn xộn và nghĩ rằng đó là cách chấp nhận được hoặc cách tốt nhất để làm mọi việc. Thực hành xấu sau đó tự tồn tại ngay cả trong một môi trường cao.

Bằng cách có ít nhất một phần mã nguyên sơ, được viết tốt (hoặc thậm chí chỉ một tệp), bạn có thể nói với các nhà phát triển sinh viên của mình sử dụng nó như một ví dụ về các thực tiễn tốt nhất. Nói với họ rằng bạn sẽ rất hồi hộp nếu họ có thể viết mã tương tự như vậy, và phần lớn các mã khác có thể không phải là một ví dụ tốt về cách làm việc đúng đắn.

Thêm ý kiến ​​hoặc tài liệu khác với một lời giải thích về lý do tại sao mọi thứ được thực hiện theo một cách nhất định cũng sẽ giúp các nhà phát triển mới có thể tăng tốc nhanh hơn với các thực tiễn mã tốt hơn.


2

Tích hợp liên tục -

Đây là một khung thực tế và khái niệm để thực hiện gia tăng và linh hoạt các công cụ, kỹ năng và quy trình của nhóm.

CI là ý tưởng của một luồng công việc từ viết mã đến triển khai. Những nhiệm vụ này là khái niệm và thực sự độc lập.

CI là tự động hóa, đặc biệt. Điều này có ý nghĩa sâu sắc đối với chất lượng và năng suất, bắt đầu từ thời điểm mã được gõ trên màn hình.

  • Thực hiện nhiệm vụ CI có thể được giải quyết độc lập, chi tiết và đồng thời. Tập trung có thể thay đổi khi cần thiết.
  • Không giới thiệu công cụ CI-to-nut
    • Bạn sẽ bị phân tâm bởi quá trình và có xu hướng minh oan cho các kỹ năng nhiệm vụ được gói gọn.
  • Giới thiệu những thứ trên một cơ sở cho buck
  • Hy vọng sẽ là tác nhân thay đổi toàn thời gian. Trở thành người lãnh đạo; không chỉ là một người quản lý, không chỉ đơn thuần là lập trình viên cao cấp.

  • Hãy chiến lược

    • Chén Thánh của CI là một sản phẩm hoàn chỉnh, được biên dịch để tự động hóa triển khai. Họ không thể FUBAR nó nếu họ không thể chạm vào nó.
    • Tài liệu đào tạo và huấn luyện.
      • Quy trình tài liệu.
      • Tạo Sổ tay Lập trình viên , để cho nó phát triển hữu cơ.
      • Bắt buộc.
      • Thăm dò phác thảo nhắm mục tiêu các kỹ năng cụ thể và cơ sở mã.
    • Thấm nhuần các giá trị lập trình viên chuyên nghiệp, chẳng hạn như:
      • TDD hoàn toàn tạo ra chất lượng
      • Đánh giá mã bao gồm tất cả các tạo tác: nhận xét, nhận xét mã, kiểm tra đơn vị, v.v.
      • "Tôi xấu hổ về số lượng lỗi được tìm thấy"
      • Tính khách quan không bị cản trở bởi ý thức sở hữu mã cá nhân và nỗi sợ "xúc phạm" chủ sở hữu.
  • Hãy chiến thuật

    • Các tác vụ CI rời rạc có thể tự động, ví dụ, kiểm soát phiên bản cam kết kích hoạt kiểm thử biên dịch và đơn vị.
    • Quy tắc thực thi tự động hóa, chẳng hạn như định dạng mã.
      • Cẩn thận với quá nhiều chi tiết vụn vặt. Công cụ sẽ bắt đầu bị bỏ qua. Điều chỉnh thực thi quy tắc để nó không áp đảo.
    • Triển khai thử nghiệm hướng phát triển ngay lập tức
    • Ưu tiên và nhấn mạnh từng thay đổi
      • Đừng cho rằng kiến ​​thức chính và bước nhảy kỹ năng đơn giản xảy ra.
    • Không cho phép khẩn cấp để lật đổ thực hiện đúng
    • Dẫn dắt sự thay đổi và làm theo
      • Định hướng chàng mới và một số đào tạo tối thiểu là cần thiết.
      • Đào tạo rõ ràng và hướng dẫn rõ ràng cho những điều mới
      • Đào tạo ít nhất đến một số tiêu chuẩn tối thiểu, ghi chú. Không phải là chính thức thực sự nhưng một bước đi ngẫu nhiên thông qua YouTube không phải là đào tạo. Cá nhân xác minh - một lần nữa hình thức eschew.
    • Hãy là người xem mã, xem lại tất cả mã.
      • Hướng dẫn rõ ràng các bản sửa lỗi đầy thách thức và chia sẻ kinh nghiệm học tập đáng chú ý.
    • Linh hoạt cứng nhắc. Thành thật xin lỗi. Nhưng đó là sự thật.
  • Tạo văn hóa
    • Có kỳ vọng nghề nghiệp
    • Chuẩn hóa công cụ
    • Nhấn mạnh việc học qua các số liệu sản xuất
    • Làm cố vấn
    • Khi giới thiệu thay đổi, chỉ cần phụ thuộc vào sáng kiến ​​của từng cá nhân "để làm cho nó" thay đổi hoàn toàn sự phát triển nhóm. Một bản sắc nhóm gắn kết bao gồm điểm chung: công cụ, kiến ​​thức và trình độ kỹ năng. Sự tôn trọng lẫn nhau phát triển đến mức mỗi thành viên chấp nhận luận điểm như những giá trị xứng đáng. Trưởng nhóm là người mẫu, nó không thể thiếu được; không mô hình một thái độ và kỳ vọng "bất cứ điều gì".

Con đường đến chất lượng

  • Kiểm tra đơn vị

    • chìa khóa để thử nghiệm phát triển
      • Đọc toàn bộ sách về nó là không cần thiết
      • Điều này sẽ trở thành các mô hình mã hóa
      • Là người lãnh đạo, bạn phải giữ vững điều đó cho đến khi mọi người thực hiện "bước nhảy thử nghiệm đơn vị". Mô hình đó thay đổi từ "Tôi đang viết hai lần mã!" để nắm lấy năng suất tuyệt vời của nó.
    • Kiểm tra đơn vị là bắt buộc trong cửa hàng của chúng tôi. Nhưng nhiều người đã không làm điều đó bởi vì họ không muốn. Sự thiếu thuyết phục của ban quản lý đã gửi thông điệp rằng các bài kiểm tra đơn vị không thực sự hoạt động.
  • Kiểm soát phiên bản

    • Tôi muốn đặt cái này trước nhưng thử nghiệm đơn vị dễ dàng hơn để bắt đầu với
    • đừng trì hoãn các sáng kiến ​​khác vì việc kiểm soát phiên bản không quá dễ dàng
    • Lập kế hoạch kiểm soát phiên bản.
      • Bạn phải viết nó ra.
      • Làm điều này ngay cả khi nó đơn giản như "ném mọi thứ vào thân cây và không phân nhánh".
  • Nhận xét mã

    • Điều này có tiềm năng lớn nhất để cải thiện chất lượng mã một cách chi tiết.
    • Sử dụng quy trình 2 đánh giá.
      • Tôi đã rất ngạc nhiên về số lượng lỗi mà bài đánh giá thứ 2 bắt được.
      • Tin tưởng nhưng xác minh. Chạy mã. Tại sao bạn thậm chí phải nói điều này? Xem ngay ở trên.
      • Ban đầu bạn sẽ là người đánh giá duy nhất. Có nhóm xem bạn xem lại "trực tiếp." Họ sẽ không bao giờ học cách nghĩ khác.
      • Bạn sẽ sớm trở thành người đánh giá thứ hai. Khi bảo đảm kỹ năng cá nhân có họ xem xét; cuối cùng cả hai nhà phê bình. Tất nhiên bạn sẽ luôn luôn nhìn vào mã, không có ngoại lệ.
  • Tái cấu trúc

    • Đây là một kỷ luật riêng biệt, chính thức.
    • Tái cấu trúc: Cải thiện thiết kế mã hiện có của Martin Fowler
      • Công thức tái cấu trúc được mã hóa để đảm bảo thay đổi mã miễn phí gây ra lỗi.
      • Bắt đầu một thư viện chuyên nghiệp với cuốn sách này.
    • Hình thức sang một bên, giới thiệu nó ad hoc thông qua đánh giá mã
  • Nắm bắt môi trường của bạn

    • Cấu hình công cụ cơ bản: kiểm soát phiên bản, IDE, công cụ CI, HĐH, v.v.
    • Mã nguồn, tài liệu, cấu hình nên đồng bộ hóa trong kiểm soát phiên bản.

Một từ về quá trình

Agile (và các thể loại phụ của nó như Scrum): Quên nó đi. "Bạn nhanh nhẹn, bạn không làm nhanh nhẹn." Xem những điều này của Dave Thomas, một trong những người ký ban đầu của Tuyên ngôn Agile .

Với các nhóm nhỏ, thiếu kinh nghiệm, cảm giác khó chịu của tôi sẽ mất đi khi tôi thấy các công cụ tích hợp nhóm như Visual Studio Team Services. Kinh nghiệm của tôi bị hạn chế ở đây nhưng tôi cảm thấy quá trình áp đặt, thừa thãi, cứng nhắc. Tôi biết nhiều người sử dụng những điều này để có hiệu quả tuyệt vời nhưng hãy cẩn thận có khả năng mua một giải pháp tìm kiếm một vấn đề.


Một từ về công cụ

Chỉ mình tôi. Không phải từ những "công cụ phần mềm tốt nhất hiện nay ..."

Jenkins

Một công cụ tích hợp CI. Dựa trên web, được sử dụng rộng rãi. Về cơ bản, thông qua GUI web, bạn tùy chỉnh cấu hình và tự động hóa các tác vụ và thứ tự thực hiện khác nhau như biên dịch, chạy thử nghiệm đơn vị, cập nhật kiểm soát phiên bản. Nó rất A-La Carte vì vậy nó phù hợp với môi trường CI non trẻ của bạn.

Kiểm soát phiên bản

Tôi thích Mercurial hơn Git. Bài đăng trên blog này là lý do ban đầu tôi chọn Mercurial: Git là MacGyver, Mercurial là James Bond

Lật đổ là tốt. Mercurial & Git có kiến ​​trúc khác biệt so với Subversion.

Môi trường phát triển tích hợp

Đây là một sự cân nhắc lớn nếu tất cả mọi người sử dụng các công cụ mã hóa khác nhau: Không có gì là văn bản đơn giản


Lời về Thư viện chuyên nghiệp

Internet rộng, nông và vô tổ chức.

  • Mã hoàn thành bởi Steve McConnell
    • Làm cho tất cả mọi người đọc thứ ba giữa.
    • Có một phụ lục của sách chuyên nghiệp được đề xuất.
  • Tái cấu trúc: Cải thiện thiết kế mã hiện có
    • Công thức tái cấu trúc được mã hóa để đảm bảo thay đổi mã miễn phí gây ra lỗi.
  • Lỗi phần mềm. Không có khuyến nghị cụ thể nhưng nó nên là những câu chuyện về một chuyên luận.

0

tôi đề nghị sử dụng một phương pháp khác để quản lý quy trình của bạn, vì như bạn nói không thể lên lịch các cuộc họp (điều này hoàn toàn quan trọng đối với scrum!). Vẫn không có gì xấu để tạo ra một khái niệm tốt để mọi người đều biết những gì đang xảy ra (có thể cũng sử dụng nguyên mẫu đỉnh) và sử dụng mô hình thác nước. Dù bằng cách nào, giao tiếp là phần lớn nhất của công việc.


1
một nguyên mẫu đỉnh là gì; bạn có thể cân nhắc mở rộng câu trả lời của mình.
esoterik ngày

Tôi xin lỗi, tôi đã có ít thời gian sáng nay. Thứ nhất, [nguyên mẫu dọc] (guidespoint.com/sdlc/sdlc_software_prototyping.htmlm) là một kiểu tạo mẫu có nghĩa là bạn hoàn toàn xây dựng phần mềm của mình mà không thực hiện bất kỳ chức năng nào. Ưu điểm là trước hết khách hàng được cho là có thể thấy sản phẩm trông như thế nào, thứ hai là nó mang lại cho nhà phát triển cảm giác tốt về chức năng "cần phải có" / dữ liệu cần cung cấp.
gkhaos

bạn có ý gì bởi "khá ngắn gọn"? Loại quản lý dự án khá khó xác định vì nó phụ thuộc vào nhiều thứ khác nhau, như dự án của bạn là gì? Đội của bạn lớn như thế nào? Ngoài ra, ví dụ như trong scrum, bạn cần một người quản lý chuyên môn cần có kiến ​​thức sâu về scrum. Tôi chỉ cố gắng xem xét rằng scrum không phải là câu trả lời duy nhất cho quản lý dự án.
gkhaos

0

Tôi sẽ khuyến khích bạn sử dụng kiểm soát nguồn nếu bạn chưa có. Điều này cho phép bạn xem những gì đã được đăng ký bởi mỗi nhà phát triển và cho phép hồi quy nơi một lỗi được đưa ra.

Tôi sẽ thiết lập một số loại thử nghiệm. Đó có thể là phát triển dựa trên thử nghiệm trong đó bạn viết thử nghiệm cho từng chức năng mà bạn cam kết hoặc đó có thể là một cách tự động để chạy (các) ứng dụng của bạn và đưa chúng ra kết quả cho một tệp có thể so sánh với mong muốn đầu ra. Nếu điều này được chạy sau mỗi lần xác nhận hoặc chạy ít nhất một lần mỗi đêm, bạn sẽ nhanh chóng tìm thấy hồi quy.

Điều cuối cùng tôi sẽ làm là thực hiện 2 chính sách: 1) tất cả các bản dựng phải có cảnh báo được đặt thành lỗi và tất cả các lỗi được bật 2) Tất cả mã phải đi qua bộ phân tích tĩnh mà không tạo ra bất kỳ lỗi hoặc cảnh báo nào trước khi nó được cam kết. Tôi thậm chí sẽ biến điều này thành một hành động trước khi cam kết. Hai điều này sẽ giữ cho mã không nhanh chóng trở nên khủng khiếp theo một số cách phổ biến. (Họ không bắt tất cả mọi thứ, nhưng họ bắt được rất nhiều.)

Điều này cũng sẽ chuẩn bị cho sinh viên của bạn về những công việc sẽ như thế nào trong "thế giới thực" và thấm nhuần một số thói quen hợp lý tốt trong đó.

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.