Khi nào nên xem lại mã

15

Gần đây chúng tôi đã chuyển sang một quy trình scrum và đang thực hiện các tác vụ và câu chuyện của người dùng bên trong các lần chạy nước rút. Chúng tôi muốn thực hiện đánh giá mã thường xuyên để làm cho chúng bớt khó khăn hơn. Chúng tôi đang nghĩ rằng thực hiện chúng ở cấp độ câu chuyện của người dùng nhưng không chắc chắn làm thế nào để phân nhánh mã của chúng tôi để giải thích điều này.

Chúng tôi đang sử dụng VS và TFS 2010 và chúng tôi là một nhóm gồm 6 người.

Chúng tôi hiện đang phân nhánh cho các tính năng nhưng đang nghiên cứu thay đổi sang phân nhánh cho scrum.

Chúng tôi hiện không sử dụng kệ và không thực sự muốn thực hiện nếu có các kỹ thuật khác có sẵn.

Làm thế nào để bạn đề nghị chúng tôi thực hiện đánh giá mã cho mỗi câu chuyện của người dùng?

agile code-reviews scrum

— mc20
nguồn

3

Nó phụ thuộc vào bản chất của câu chuyện người dùng.

Có thể hiệu quả để tạo một nhánh cho mỗi câu chuyện của người dùng, tiến trình trên các câu chuyện khác nhau có thể nhìn thấy được, chúng có thể được chuyển qua nếu cần, nếu câu chuyện không được hoàn thành trong lần chạy nước rút thì tiến trình có thể ở lại nhánh cho lần chạy nước rút tiếp theo . Đánh giá cuối cùng sau đó có thể được thực hiện ở cuối câu chuyện của người dùng trong nhánh câu chuyện sử dụng và được hợp nhất nếu mã đạt tiêu chuẩn.

Để làm việc theo cách các câu chuyện cần phải được xử lý tốt để ngăn chặn các nhiệm vụ hợp nhất không thể quản lý ở cuối nước rút. Các câu chuyện nhỏ sẽ cho phép cập nhật ổn định nhánh dev thông qua giai đoạn nước rút mà các nhà phát triển làm việc trên các câu chuyện người dùng khác cần liên tục lấy từ (VCM cơ bản).

Điều này không tạo ra các chi phí quá trình phải tạo và hợp nhất các nhánh liên tục mà trong một số trường hợp có thể được giải quyết bằng các tập lệnh tự động hóa nhưng nhóm vẫn cần phải rất thoải mái với VCS.

Vào cuối giai đoạn nước rút, bạn hợp nhất chi nhánh dev của mình vào tích hợp / sản xuất, v.v.

Tôi cũng đã làm việc trong các nhóm nơi mọi người làm việc ở một nhánh dev, khi hoàn thành câu chuyện người dùng, mã được đẩy đến nhánh đó để xem xét và thử nghiệm và nếu ai đó đẩy thứ gì đó phá vỡ bản dựng dev, họ phải đưa bia vào nhóm.

13

Cách hiệu quả nhất để xem lại mã là đứng lên, tìm ai đó và yêu cầu họ ghé qua và thảo luận về mã bạn vừa phát triển.

Đừng sử dụng một công cụ trừ khi bạn không thể tìm thấy ai đó để xem lại mã của mình tại địa phương.

Bạn có thể tránh đánh giá mã hoàn toàn bằng cách ghép nối.

— Ryan Cromwell
nguồn

Tôi đã tự hỏi khi ai đó sẽ đề cập đến việc ghép đôi. Giữa đó và kiểm tra đơn vị bạn nhận được rất nhiều đánh giá.

— JeffO

Tôi đọc điều này là "đứng lên, sa thải ai đó và yêu cầu họ ghé qua và thảo luận về mã bạn vừa phát triển." Cảm ơn đã làm cho ngày của tôi.

— Will Morgan

4

Có phải tất cả mọi người trong đội địa phương? Nếu vậy, chỉ cần yêu cầu ai đó ghé qua và xem trước khi mã được kiểm tra. Không phải địa phương? Bật chương trình chia sẻ màn hình yêu thích của bạn và gọi cho ai đó. Cá nhân tôi làm điều này thường xuyên. Đôi khi tôi làm điều đó chỉ để nói "Này, hãy nhìn những gì tôi đã làm!"

Tôi rất thích phong cách đánh giá mã ad-hoc này cho phong cách nơi ai đó đang đứng lên và trình bày mã của họ cho nhóm. Đánh giá đặc biệt có thể cung cấp cho bạn nhiều (tất cả?) Những lợi ích của việc ghép đôi mà không có sự khó xử. Ngoài ra, "người đánh giá" của bạn có nhiều khả năng đặt câu hỏi và đề xuất cải tiến trong cài đặt không chính thức, một đối một.

— jgrim
nguồn

1

Tôi tin rằng đánh giá mã không phải là một phần chính thức của SCRUM, nhưng sửa đổi là một chiến thuật độc lập để đạt được chất lượng và cải thiện dự án / nhóm của bạn.

Vì vậy, bạn sẽ sử dụng SCRUM (hoặc phương pháp phát triển nhanh khác) để đảm bảo / cải thiện chất lượng DỰ ÁN và giữ đúng tiến độ. Ngoài ra, một chiến thuật tốt là thực hiện sửa đổi sản phẩm (không phải mã) một cách độc lập với các nhiệm vụ kiểm tra / QA thông thường của bạn. Nếu hoạt động này có thể được thực hiện trước nhóm / đối tác / khách hàng / khán giả của bạn thì sẽ tốt hơn.

Bạn nên sử dụng các sửa đổi mã (hoặc cụ thể khác) chủ yếu để cải thiện TEAM của mình, mong đợi kết quả trên cơ sở trung / dài hạn. Điều này sẽ ảnh hưởng đến DỰ ÁN của bạn, nhưng về lâu dài là một sản phẩm cải thiện TEAM của bạn.

Vì vậy, để trả lời câu hỏi của bạn, tôi tin rằng bạn đang cố gắng đẩy quá nhiều từ SCRUM, và tốt hơn hết bạn nên xem xét sửa đổi.

— Ron-Damon
nguồn

Scrum không nói hoặc tư vấn bất cứ điều gì liên quan đến lịch trình. Nó không mong đợi bạn cung cấp giá trị một cách thường xuyên. Nó cũng cung cấp những khoảnh khắc mà bạn có thể kiểm tra và điều chỉnh quy trình của mình để trở nên tốt hơn (tốt hơn không nhất thiết là nhanh hơn).

— Ryan Cromwell

Có, Scrum không nêu ra một lịch trình đầy đủ như là một phần của nó. Tuy nhiên, tôi có nghĩa là "lập kế hoạch" khi tôi tham gia lên lịch, lập kế hoạch có nghĩa là khách hàng của bạn mong đợi một giá trị nào đó trong một thời gian nhất định, để họ có thể thực hiện trao đổi giữa giá trị v / s tiền (nếu bạn cho rằng bạn đang cung cấp dịch vụ lập trình / phát triển ).

— Ron-Damon

Trong vấn đề đó, khách hàng của bạn nên có một ngân sách để chi tiêu trong một thời gian nhất định (ví dụ để trả cho bạn) và anh ta có thể có một lịch trình để tham dự. Tôi làm việc như một nhà cung cấp dịch vụ, đó là lý do tại sao tôi không thể bỏ sự thật này sang một bên.

— Ron-Damon

Hợp đồng sang một bên, các nhóm Scrum cung cấp giá trị không phải dịch vụ. Chúng tôi phát triển / chương trình như một phương tiện để cung cấp giá trị đó.

— Ryan Cromwell

Tôi không tin rằng bạn có thể tách biệt cụm từ "giá trị" và "dịch vụ" bạn bè. Tôi cũng tin rằng điều này rất lạc đề.

— Ron-Damon

0

Không rõ ràng để làm đánh giá mã trước khi kiểm tra mã của bạn?

TFS không hoạt động như GIT, vì vậy bất cứ khi nào bạn kiểm tra mã vào một nhánh hoặc thân cây, nó có sẵn cho tất cả mọi người.

Điều này có nghĩa là việc đánh giá sẽ diễn ra khi nhận phòng để những thay đổi xấu không được truyền tới mọi người đang làm bản sao.

— Byron Whitlock
nguồn

Tôi nghĩ rằng, nói chung, các bài kiểm tra đơn vị là những gì sẽ ngăn chặn những thay đổi xấu.

— John Saunders

@ John Saunders: Xem xét đánh giá mã như một loại thử nghiệm đơn vị khác.

— Gilbert Le Blanc

@Gilbert: Tôi có thể làm điều đó, nhưng sau đó tôi sẽ không nhận được lợi ích của họ khi thử nghiệm hồi quy. Tôi muốn dành thời gian để viết bài kiểm tra đơn vị nhiều hơn và tốt hơn.

— John Saunders

@John Saunders, @Gilbert Le Blanc đánh giá mã được thực hiện bởi một nhà phát triển khác, kiểm tra đơn vị thường được thực hiện bởi nhà phát triển ban đầu, quan điểm mới có thể rất quan trọng.

Tôi đã rất may mắn với các bài kiểm tra đơn vị (danh sách kiểm tra được thỏa thuận trước thời hạn) và phân tích mã tự động, có thể kết hợp với một công cụ phân tích kiểu như StyleCop. Nhưng sau đó, tôi không thường xuyên làm việc với các nhà phát triển cơ sở.

— John Saunders