Tôi nên làm gì khi chờ xem xét?

Trước khi đặt câu hỏi của tôi, tôi phải giải thích tình hình.

Tôi đang làm việc cho một công ty như là một kỹ sư phần mềm cơ sở. Một trong những người cao niên luôn ngăn cản tôi khi tôi đã hoàn thành sự phát triển của mình và muốn cam kết.

Anh ấy luôn muốn tôi đợi anh ấy xem lại. Điều này là ổn, bởi vì anh ta thường tìm thấy một số lỗi và thực hiện một số tối ưu hóa.

Tuy nhiên tôi phải cam kết mã của mình trước thời hạn. Khi tôi kết thúc, tôi gọi cho anh ta và nói rằng nó đã kết thúc. Anh ấy thường đến muộn. Vì vậy, mã của tôi là muộn quá.

Câu hỏi của tôi là, tôi nên làm gì? Tôi có nên chờ đợi anh ta để xem xét?

EDIT: Bổ sung cho câu hỏi. Tôi tò mò về một vấn đề nữa.

Tôi muốn được tự do khi viết mã. Làm thế nào tôi có thể có được sự tin tưởng cho tự do phát triển?

_{Một số giải thích: Tôi đã nói chuyện với anh ta về điều này. Nhưng nó không giúp được gì. Chúng tôi đã sử dụng trình theo dõi vấn đề, nhưng không có nhiệm vụ nào để đánh giá. Chỉ có nhiệm vụ phát triển và thử nghiệm.}

Vì vậy, mã của tôi là muộn quá.

Không, đó không phải là mã của bạn , nó là mã của bạn và cấp cao. Bạn đang làm việc theo nhóm, bạn có trách nhiệm chung và khi hai bạn bỏ lỡ thời hạn, đó là lỗi của cả hai bạn. Vì vậy, hãy chắc chắn rằng người đưa ra thời hạn thông báo rằng. Nếu người đó cũng coi đó là một vấn đề, anh ta chắc chắn sẽ nói chuyện với cả hai bạn với nhau - điều đó có thể giúp nhiều hơn một cuộc nói chuyện với đồng nghiệp của bạn.

Và với EDIT của bạn:

Tôi muốn được tự do khi viết mã. Làm thế nào tôi có thể có được sự tin tưởng cho tự do phát triển?

Xem lại mã là một trong những trình tiết kiệm chất lượng quan trọng nhất. Hầu như không thể viết mã xuất sắc mà không có đôi mắt thứ hai, ngay cả khi bạn có> 20 năm kinh nghiệm lập trình. Vì vậy, trong một nhóm tốt, mã của mọi người phải được xem xét liên tục - mã của cấp cao cũng như mã của bạn. Điều này không liên quan gì đến sự ngờ vực đối với bạn trong người (hoặc, ít nhất, nó không nên). Miễn là bạn tin rằng "mã hóa miễn phí" mà không cần đôi mắt thứ hai thì tốt hơn, bạn vẫn là một lập trình viên cơ sở.

Trong một nhóm tốt, bạn nên có một hàng các nhiệm vụ phát triển được giao cho bạn trong một trình theo dõi vấn đề .

Bằng cách đó, trong khi bạn đang chờ người đánh giá, bạn có thể ( nên ) làm việc với nhiệm vụ tiếp theo đang chờ trong hàng đợi đó. Khi bạn đã quen với công việc theo kiểu đó, điều này sẽ mở ra một cơ hội để các thay đổi của bạn được xem xét trong "đợt", do đó giảm độ trễ.

• ^{Nếu bạn không có "hàng đợi" như vậy, hãy thảo luận vấn đề này với người quản lý của bạn hoặc tốt hơn là với người đánh giá. Nếu nhóm của bạn không có trình theo dõi vấn đề thuận tiện một cách hợp lý cho những thứ như vậy, hãy xem xét nghiên cứu bảng công việc hoặc cơ hội việc làm nội bộ của công ty để tìm một nhóm tốt hơn (bạn cũng có thể thảo luận vấn đề này với người quản lý / người đánh giá nhưng đừng hy vọng điều này sẽ giúp - thiếu của một người theo dõi vấn đề tốt thường là một triệu chứng của một cái gì đó bị phá vỡ nghiêm trọng trong một nhóm).}

Tôi muốn được tự do khi viết mã. Làm thế nào tôi có thể có được sự tin tưởng cho tự do phát triển?

Để tìm hiểu, trước tiên bạn cần hiểu mục đích của đánh giá mã. Bạn đã đề cập đến niềm tin - đó là một "xấp xỉ" tốt, nhưng không hoàn toàn chính xác.

• ^{Ví dụ, trong một trong những dự án phát triển gần đây của tôi đã được thực hiện bởi một nhóm nhỏ gồm tôi và đồng nghiệp của tôi. Chúng tôi hoàn toàn tin tưởng lẫn nhau và tôn trọng lẫn nhau - nhưng mặc dù vậy, chúng tôi đã xem xét 100% mã. Chúng tôi đã làm điều đó bởi vì điều này cho phép chúng tôi tìm và nhanh chóng sửa một số lỗi và điều này cũng rất quan trọng, vì các đánh giá không mất nhiều thời gian và không chặn công việc của chúng tôi.}

Bạn thấy đấy, sẽ chính xác hơn khi nghĩ về các đánh giá mã về các nỗ lực được đầu tư để ngăn ngừa các rủi ro nhất định . Trong một nhóm tốt, bạn có thể mong đợi loại hiểu biết được chia sẻ về cách "cân bằng hợp lý" điều này. Lưu ý rằng không có sự cân bằng phù hợp một kích thước phù hợp, nó phụ thuộc rất nhiều vào một dự án - rủi ro và tác động của các lỗi trong một phần mềm quan trọng khác với tự nhiên trong một ứng dụng không quan trọng.

Sử dụng ví dụ của bạn, bạn có thể mong đợi "chặn đánh giá" miễn là những nỗ lực được đầu tư bởi người đánh giá của bạn được chứng minh bằng cách tìm ra các lỗi và cải tiến tốt hơn để được sửa trước khi cam kết mã của bạn.

Họ có thể mong đợi rằng với thực tiễn và với hướng dẫn nhận được khi đánh giá, bạn sẽ trở nên tốt hơn trong việc mã hóa, do đó họ sẽ tìm thấy ngày càng ít vấn đề đáng sửa chữa trước khi cam kết. Ngay khi họ phát hiện ra rằng mã của bạn đã "đủ an toàn" để cho phép các "biện pháp phòng ngừa rủi ro" ít cồng kềnh hơn, bạn có thể mong đợi quy trình thay đổi, ví dụ như đánh giá sau khi cam kết .

Tùy thuộc vào một dự án, tại một số điểm, mã của bạn thậm chí có thể được coi là đủ an toàn để bỏ qua các đánh giá, để lại phát hiện lỗi cho người kiểm tra (nhưng điều đó không nhất thiết sẽ xảy ra, xem ví dụ của tôi ở trên).

Có nhiều câu trả lời có thể có ở đây, tùy thuộc vào chính xác vấn đề của bạn là gì.

• Nếu mối quan tâm chính của bạn là "Tôi đang thiếu thời hạn", thì không. Hai bạn đang thiếu thời hạn. Bạn có thể (với sự tự tin) có thể nói "Tôi sẽ hoàn thành trong một giờ, chúng ta có thể thực hiện đánh giá mã sau đó không"? Điều đó có thể là đủ. Bạn có thể hoàn thành mã ngày trước hạn chót không? Đó nên là một bộ đệm dồi dào. Bạn đang hoàn thành mã của mình, với rất nhiều bộ đệm giữa "vui lòng xem lại" và thời hạn? Nếu sau này, nó thậm chí không phải là một lỗi chung, tôi nói.

• Mã phải luôn luôn được xem xét. Tôi không thể kiểm tra bất cứ thứ gì mà không có (ít nhất) một đôi mắt thứ hai và một người khác sẽ "không sao". Điều đó áp dụng cho các dự án mà tôi là lập trình viên chính cũng như cho các dự án mà tôi thường không đóng góp (nhưng đã tìm được một lỗi ảnh hưởng đến tôi mà tôi muốn sửa). Tuy nhiên, sự nghiêm ngặt của một đánh giá là rất nhiều dựa trên niềm tin. Nếu tôi tin rằng người muốn gửi mã biết rõ cơ sở mã, tôi sẽ không nghiêm khắc như thể tôi không biết người đó biết cơ sở mã tốt như thế nào.

Câu hỏi của tôi là, tôi nên làm gì? Tôi có nên chờ đợi anh ta để xem xét?

Không, bạn không nên ngồi không. Luôn luôn có một cái gì đó để làm. Như Gnat đề xuất , nên có một hàng các nhiệm vụ. Hoặc, theo cách phát triển nhanh, danh sách các nhiệm vụ được giao cho bạn cho lần lặp hiện tại. Nếu bạn ngồi không, có một cái gì đó sai trong tổ chức của công ty hoặc nhóm của bạn.

Một điều nữa là: người giám sát cấp cao của bạn có thực sự kiểm tra từng đoạn mã bạn làm không? Nếu có, bạn cũng có thể làm lập trình cặp.

Tôi muốn được tự do khi viết mã. Làm thế nào tôi có thể có được sự tin tưởng cho tự do phát triển?

Có một số quy định yêu cầu cấp cao kiểm tra công việc của thiếu niên (tôi nghĩ y tế iso 62304 yêu cầu điều này). Nếu nó là như vậy, bạn không thể làm bất cứ điều gì.

Những gì bạn có thể thay đổi là yêu cầu cấp cao không kiểm tra mọi thứ theo nghĩa đen. Bạn có thể thiết lập quy trình xem xét mã và kiểm tra những thứ quan trọng.

Sử dụng git cục bộ, cam kết thay đổi của bạn với một nhánh và bắt đầu nhiệm vụ 2 trong khi bạn chờ đợi. Sau đó, khi anh ta hoàn thành, bạn có thể hợp nhất các thay đổi của anh ta vào công việc mới của bạn và bạn đã đi trước đường cong trong nhiệm vụ tiếp theo.

Làm điều này đủ lâu và khá sớm, anh ta có thể xem lại 2 hoặc nhiều thứ trong một lần ngồi. Chọn những thứ mà các đường không có khả năng trùng nhau để giảm thiểu xung đột.

Một giải pháp cho vấn đề này có thể là khiến nhà phát triển cấp cao tham gia sớm hơn nhiều bằng Lập trình cặp về công việc của bạn.

Trang Wikipedia về Lập trình cặp

Lợi thế rõ ràng nhất đối với bạn là việc đánh giá diễn ra sớm hơn nhiều trong quy trình để bạn không còn phải chờ nhà phát triển cấp cao.

Cũng như điều này, bạn sẽ có thể thấy các quy trình và kỹ thuật suy nghĩ của nhà phát triển cao cấp khi anh ta viết mã và học hỏi từ điều này.

Bạn có thể có vấn đề của nhà phát triển cấp cao có thể không muốn ghép với bạn. Điều đó có thể khó khăn, nhưng kinh nghiệm của riêng tôi là cả nhà phát triển cấp cao và cấp dưới đều có được nhiều kinh nghiệm từ lập trình cặp.

Cũng thường có mối quan tâm rằng bạn sẽ giảm một nửa năng suất bằng cách có 2 nhà phát triển làm việc trên cùng một công việc. Thật khó để đo lường mức độ ảnh hưởng đến năng suất là gì với Lập trình cặp, câu trả lời phổ biến nhất tôi từng nghe là năng suất của các đội kết hợp và những đội không giống nhau. (Nếu bất cứ ai biết bất kỳ nghiên cứu tốt về điều này, tôi rất thích nghe về nó)

Không phải là một câu trả lời đầy đủ, chỉ là một bổ sung cho các câu trả lời xuất sắc ở trên ...

Bạn có xem lại mã của riêng mình trước khi kiểm tra nó không? Tôi biết đó không phải là niềm vui nhất, nhưng tôi cố gắng làm cho mình làm điều đó hầu hết thời gian. Tôi đã lập trình chuyên nghiệp được 20 năm (tổng cộng 34 năm), nhưng tôi thường tìm thấy ít nhất một lỗi và / hoặc một điều tôi quên, hoặc ít nhất có thể làm cho tốt hơn. Tôi đồng ý với tình cảm rằng mã của bạn phải luôn được xem xét và một đôi mắt thứ hai tốt hơn một cặp. Nhưng ngay cả cùng một cặp đi qua mã hai lần vẫn tốt hơn một lần.

Bạn có viết bài kiểm tra đơn vị cho mã của bạn? Ngoài các bài kiểm tra đơn vị, tôi cũng có một tập lệnh shell nhỏ tìm kiếm các lỗi phổ biến nhất mà cá nhân tôi mắc phải. Một số trong đó là ngữ pháp và chính tả tiếng Anh, một số là các vấn đề về mã hóa mà trình biên dịch không nắm bắt được. Tôi chạy nó trước khi kiểm tra các thay đổi lớn như một phép lịch sự cho mọi người ở hạ lưu.

Tôi thường để mọi người viết mã của họ và thỉnh thoảng phàn nàn về nó sau đó, nhưng tôi không xem lại mỗi lần đăng ký. Tôi đã từng làm việc với một lập trình viên rất trẻ có mã mà tôi phải xem lại và thường hoàn tác vì họ đã phạm rất nhiều lỗi. Điều đó đã không kết thúc tốt đẹp. Bạn đang ở trong một nghề mà việc hoàn thành công việc đúng giờ thường rất quan trọng. Nếu bạn học hỏi từ những sai lầm của bạn, bạn sẽ đi xa.

Nếu bạn có thể giảm thiểu số lượng thay đổi mà người đánh giá của bạn cần thực hiện đối với mã của mình, bạn sẽ tối đa hóa cơ hội họ sẽ tin tưởng bạn viết mã mà không phải lúc nào cũng cần được xem xét cẩn thận. Nếu bạn muốn tự do đánh giá, chịu trách nhiệm tối đa về chất lượng đầu ra của riêng bạn.

Một số hoặc tất cả các đề xuất này có thể được thực hiện trong khi chờ người khác xem lại mã của bạn.

Tôi nghĩ rằng việc thực hiện đánh giá mã thủ công là ... à ... khoảng 80. Chà, có lẽ là 90

Trong kỷ nguyên hiện đại của các hệ thống đánh giá mã trực tuyến và tích hợp liên tục, bạn thực sự không muốn giữ lại bất kỳ cam kết mã nào chỉ vì bạn sợ rằng "nó có thể phá vỡ kiểm soát nguồn".

Thôi nào mọi người. Đó là những gì thay đổi (hoặc danh sách thay đổi) là dành cho. Bạn làm cho các lập trình viên của bạn nuôi những con mồi đói của hệ thống kiểm soát nguồn của bạn. Sau đó, máy chủ tích hợp liên tục của bạn khởi động với một loạt các bản dựng được nhắm mục tiêu (tốt, hy vọng chỉ là bản dựng hàng ngày, nhưng một số người trong chúng ta sẽ bị mang đi). Nếu bất cứ điều gì phá vỡ, bạn đặt chiếc cúp khỉ mã (thường là đồ chơi bằng nhựa mà ai đó tìm thấy từ hộp ngũ cốc Lucky Charm) trên bàn của hung thủ và lật lại danh sách thay đổi phá vỡ. Chà, một số hệ thống tích hợp liên tục sẽ tự động gửi thông báo email / IM / máy tính để bàn tới mọi người trong nhóm / bộ phận / tổ chức rằng bản dựng bị hỏng, cùng với một siêu liên kết tiện lợi để hiển thị cho mọi người đã phá vỡ chính xác bản dựng trong tệp hoặc kiểm tra. Bây giờ là lập trình viên không may '

Khi quá trình này chạy, hệ thống xem lại mã sẽ khởi động (một lần nữa, được kích hoạt bởi đăng ký). Danh sách các thành viên nhóm đủ điều kiện được thông báo về danh sách thay đổi được cam kết kiểm soát nguồn, đánh giá được bắt đầu trong hệ thống đánh giá và mọi người bắt đầu chú thích đến các thay đổi trong danh sách thay đổi. Hy vọng mọi người sẽ nói "LGTM". Nếu lập trình viên thông minh, anh ta sẽ nhớ cầu nguyện / mua chuộc / giấu. Nếu có vấn đề nghiêm trọng, người đánh giá có thể tạo ra lỗi (có thể được nối vào hệ thống theo dõi lỗi) hoặc thậm chí yêu cầu người thay đổi phải sao lưu. Vâng, ủng hộ những thay đổi làm tổn thương không chỉ bản ngã, mà cả tâm trí, đó là sự thật. Đó là một gia vị tốt cho các nhà phát triển cơ sở, để tái hòa nhập danh sách thay đổi bị từ chối.

Nếu môi trường dev của bạn thiếu CI hoặc hệ thống đánh giá mã, bạn nên nghiêm túc điều tra những điều này. Một vài liên kết có thể giúp bạn:

Atlassian Crucible
JetBrains TeamCity giới
thiệu lại
điều khiển hành trình

Nếu bạn sắp có một máy chủ CI, bạn cũng nên nghiêm túc suy nghĩ về các khung kiểm tra đơn vị. Nếu bạn là nhà phát triển C #, hãy xem xét một cái gì đó như NUnit để bắt đầu.

Bạn nói với anh ta trước khi mã của bạn sẽ sẵn sàng, không phải lúc này khi nó hoàn thành. Bạn sẽ có thể xác định rằng khoảng. một tuần nữa Điều đó cho anh ta thời gian để chuẩn bị và lên kế hoạch đánh giá sao cho phù hợp với cả quy hoạch của bạn.