Làm thế nào để đối phó với một phương pháp chưa được thực hiện sẽ được thực hiện bởi một lập trình viên?

Đây là một câu hỏi về cách làm việc theo nhóm.

Gần đây tôi đã làm việc trong dự án lập trình lớn hơn (~ 80 lớp, Java) đầu tiên của mình với một nhóm gồm 6 người, mặc dù chỉ có 4 người chúng tôi liên tục làm việc về mã. Chúng tôi đã phân phối công việc sẽ được thực hiện sớm và đến một lúc nào đó tôi cần gọi một phương thức chưa được thực hiện bởi một trong những lập trình viên của tôi. Làm thế nào là cách được đề nghị để đối phó với điều này?

Các tùy chọn tôi đã thấy, mặc dù tôi không thực sự thích bất kỳ tùy chọn nào trong số chúng:

Viết cho mình một bản //TODOvà xem lại dòng mã này sau để kiểm tra xem phương thức này đã được thực hiện chưa.
Yêu cầu thành viên nhóm tương ứng thực hiện điều đó ngay bây giờ .
Ném một thời gian chạy tùy chỉnh Ngoại lệ với một mô tả rõ ràng về những gì chưa được thực hiện. (Ít nhất chúng ta không phải tìm kiếm trong một thời gian dài để tìm ra những gì còn thiếu)
Thêm phương thức cần thiết vào lớp của họ và viết cho họ một //TODOnội dung thư, cũng có thể gửi cho họ một tin nhắn nhanh về sự thay đổi đó. (Bây giờ không còn là vấn đề của tôi nữa, nhưng điều này có thể gây ra xung đột hợp nhất gây phiền nhiễu nếu họ đang làm việc với phương pháp này trong thời gian này)
Xác định các lớp hoặc giao diện trừu tượng cho mọi thứ trước khi thực sự viết mã thực hiện công việc. (Không hoạt động quá tốt vì các giao diện này thường được thay đổi)

teamwork

— lucidbrot
nguồn

Tôi nghĩ rằng quy trình làm việc mà bạn cần một phương pháp được viết bởi người khác là không đúng. Bạn đang làm việc trên một tính năng. Nếu tính năng đó yêu cầu một phương pháp, BẠN thực hiện nó. Nếu hai người thực hiện một tính năng duy nhất, họ có thể ghép nối hoặc tích hợp và liên lạc thường xuyên đến mức trông giống như họ ghép nối.

— Euphoric

@Euphoric Đã nhiều lần tôi bắt gặp một tình huống trong đó một tính năng mới khá lớn được phát triển trong một khung thời gian tương đối ngắn và như vậy, giao diện người dùng, logic nghiệp vụ và các lớp API phải được chia thành các nhiệm vụ khác nhau để được xử lý đồng thời, nếu không thì thời hạn không bao giờ có thể được đáp ứng. Đó chính xác là nơi một người làm việc trên UI chỉ nên khai báo các phương thức và lệnh truy cập dữ liệu tới BL làm giao diện và để những người khác làm việc khi thực hiện, trong khi chỉ làm việc trên UI.

— Andy

@DavidPacker Những gì bạn mô tả không phải là cách duy nhất để giải quyết vấn đề đó. Các lát cắt dọc, tích hợp thường xuyên, các tính năng nhỏ là tất cả các giải pháp tốt hơn so với các lát cắt ngang với mỗi người làm việc trên một phần riêng biệt.

— Euphoric

@Euphoric Tôi không thể đồng ý nhiều hơn với bạn. Khi có thể, chúng tôi thực hiện theo cách tước bỏ tính năng mới phức tạp của các phần không quan trọng (nghĩa là những phần chỉ cải thiện UX nhưng không cần thiết ngay lập tức). Đáng buồn thay, đôi khi các tùy chọn bạn đã đề cập, không phải là tính năng tước, không thể. Doanh nghiệp nói, nhà phát triển làm. Vì vậy, trong khi điểm của bạn là vững chắc, cũng có khả năng ai đó sẽ và sẽ gặp phải tình huống phải thực hiện một số loại tính năng phân chia công việc để đáp ứng nhu cầu của doanh nghiệp.

— Andy

những gì về nói chuyện với anh như thế nào anh ta muốn xử lý nó?

— Aganju

Câu trả lời:

Đó là một câu hỏi thú vị và câu trả lời có thể dễ dàng hơn bạn nghĩ.

Đơn giản chỉ cần đặt, viết các bài kiểm tra xác nhận các giả định của bạn. Không thành vấn đề nếu bạn thực hiện hoặc các lập trình viên đồng nghiệp của bạn

Câu trả lời dài.

Bất kỳ tùy chọn nào bạn liệt kê đều hơi bị động và yêu cầu bạn quay lại và xem lại mã (nếu có) sớm hay muộn.

Nhận xét cần phải được đọc và xử lý bởi đối tác của bạn chịu trách nhiệm thực hiện. Mã của bạn không thể được biên dịch trong khi chờ đợi. Nếu bạn kiểm tra trạng thái như vậy trong kho lưu trữ mã, đường dẫn tích hợp liên tục của bạn sẽ không hoạt động và dù sao đi nữa, đó là cách thực hành tồi ... không bao giờ kiểm tra mã bị hỏng
Các ngoại lệ thời gian chạy có vẻ tốt hơn, nhưng vẫn độc hại, bởi vì lập trình viên đồng nghiệp của bạn có thể cho rằng việc triển khai đã được thực hiện mà không cần kiểm tra, khiến hệ thống cũng ở trạng thái không ổn định. Nếu phương thức được kích hoạt không thường xuyên, nó có thể dẫn đến mã sản xuất bị hỏng ... thực tế xấu cũng ... không bao giờ kiểm tra các ngoại lệ "không được thực hiện"
Chờ đợi các lập trình viên đồng nghiệp của bạn để thực hiện các phương pháp hoặc còn sơ khai cũng rất khó khăn. Nó phá vỡ quy trình làm việc của bạn và quy trình làm việc của các lập trình viên đồng nghiệp của bạn. Điều gì xảy ra nếu họ bị ốm, trong một cuộc họp, khi nghỉ giải lao, bạn có muốn dành thời gian chờ đợi không? ... đừng đợi ai đó nếu bạn không phải
thực hiện các phương pháp còn thiếu chắc chắn là cách tốt nhất để đi tiếp. Nhưng điều gì xảy ra nếu việc triển khai của bạn không thỏa mãn toàn bộ trường hợp sử dụng và các lập trình viên đồng nghiệp của bạn cần sửa đổi hoặc thay đổi nó? Làm thế nào để bạn và họ đảm bảo rằng nó vẫn tương thích với dự định của bạn? Câu trả lời là dễ dàng một lần nữa. Viết các bài kiểm tra xác minh, mô tả và ghi lại ý định của bạn. Nếu các bài kiểm tra bị phá vỡ, nó rất dễ nhận thấy. Nếu những thay đổi trong phương pháp đó cần được thực hiện, phá vỡ tính năng của bạn ... bạn sẽ thấy nó ngay lập tức. Cả hai bạn có một lý do để giao tiếp và quyết định phải làm gì. Chia chức năng? Thay đổi triển khai của bạn, v.v ... không bao giờ kiểm tra mã không đủ tài liệu bằng các thử nghiệm

Để đạt được một mức độ kiểm tra đủ, tôi khuyên bạn nên xem xét hai nguyên tắc.

TDD - phát triển dựa trên thử nghiệm - điều này sẽ đảm bảo bạn mô tả ý định của mình và kiểm tra đầy đủ. Nó cũng cung cấp cho bạn khả năng giả định hoặc các phương thức và lớp giả (cũng bằng cách sử dụng các giao diện) chưa được triển khai. Mã và các bài kiểm tra vẫn sẽ biên dịch và cho phép bạn kiểm tra mã của riêng bạn tách biệt với mã lập trình viên của bạn. (xem: https://en.wikipedia.org/wiki/Test-driven_development )
ATDD - phát triển dựa trên kiểm tra chấp nhận - điều này sẽ tạo ra một vòng lặp bên ngoài (xung quanh vòng TDD) giúp bạn kiểm tra toàn bộ tính năng. Các thử nghiệm này sẽ chỉ chuyển sang màu xanh khi toàn bộ tính năng được triển khai, do đó cung cấp cho bạn một chỉ báo tự động khi các đồng nghiệp của bạn hoàn thành công việc của họ. Khá gọn gàng nếu bạn hỏi tôi.

Hãy cẩn thận: Trong trường hợp của bạn, tôi sẽ chỉ viết các bài kiểm tra chấp nhận đơn giản và không cố gắng mang lại quá nhiều khía cạnh kinh doanh, vì nó sẽ là quá nhiều để bắt đầu. Viết các bài kiểm tra tích hợp đơn giản kết hợp tất cả các phần của hệ thống mà tính năng yêu cầu. Đó là tất cả những gì cần thiết

Điều này sẽ cho phép bạn đặt mã của mình vào một đường dẫn Tích hợp liên tục và tạo ra một triển khai có độ tin cậy cao.

Nếu bạn muốn biết thêm về chủ đề đó, hãy kiểm tra các liên kết sau:

— Jesko R.
nguồn

103

Yêu cầu sơ khai.

Hoặc tự viết chúng. Dù bằng cách nào, bạn và đồng nghiệp của bạn cần phải đồng ý về các giao diện và cách chúng được sử dụng. Thỏa thuận đó cần phải được củng cố tương đối để bạn có thể phát triển chống lại các sơ khai - không đề cập đến, vì vậy bạn có thể tạo các bản giả của riêng mình để thử nghiệm đơn vị của bạn ...

— Svidgen
nguồn

^^ Cái này Nếu bạn đang sử dụng đúng giao diện, bạn không cần thực hiện cho đến khi người kia viết xong chúng.

— Robert Harvey

Và để nhận xét thêm của Robert, nếu bạn không sử dụng đúng giao diện trong một dự án được thiết kế riêng để chia cho nhiều người, thì bạn sẽ có một khoảng thời gian tồi tệ ...

— corsiKa

Thật xấu hổ khi Java không có các tệp tiêu đề. Trong thế giới C / C ++, bạn có thể tìm ra các API của mình và viết tất cả các tiêu đề của bạn trước, việc thiếu triển khai sau đó trở thành một vấn đề đối với trình liên kết. (Đơn giản hóa một chút, ABI cần duy trì không đổi cũng như chỉ là vấn đề liên kết).

— Wes Toleman

@WesToleman Thật thú vị, một trong những điều yêu thích của tôi về Java là nó không có các tệp tiêu đề. Các "giao diện" mà Robert và corsiKa đề cập đã hoàn thành vai trò đó một cách hoàn hảo. Trước tiên, bạn xử lý các API của mình, viết các giao diện và việc thiếu triển khai cụ thể không phải là vấn đề đối với trình biên dịch.

— GrandOpener

@WesToleman Điều đó có tốt cho bạn không? Trong tai tôi nghe có vẻ rất giống phong cách thác nước, và tôi đoán là bạn phải cập nhật giao diện hơn nữa khi bạn nhận ra rằng bạn đã hiểu sai "thông số quan trọng" này?

— netigger

Trong tình huống của bạn, tôi sẽ nói chuyện với thành viên trong nhóm chịu trách nhiệm về chức năng đó. Có thể là họ đang ở vị trí ưu tiên phát triển chức năng đó để bạn có thể bắt đầu sử dụng nó sớm hơn.

Tôi sẽ tránh xa lựa chọn thứ tư của bạn. Bạn đã viết tất cả mã của mình và như bạn nói, bạn không còn coi đó là vấn đề của mình nữa. Đồng nghiệp của bạn sau đó viết việc thực hiện chức năng, và không còn coi đó là vấn đề của họ. Ai thực sự sẽ kiểm tra xem mã BẠN viết có hoạt động chính xác không?

— Pete
nguồn

Bạn nên yêu cầu API cho chức năng đó sẽ dẫn đến một hoặc nhiều giao diện. Có thể là một ý tưởng tốt để làm điều này cùng nhau, vì bạn sẽ cần sử dụng giao diện này để bạn có thể thiết kế các trường hợp thử nghiệm ban đầu dựa trên đầu vào của bạn. Việc triển khai thực tế sau đó có thể đến sau (bao gồm các thay đổi API có thể)

— Thorbjørn Ravn Andersen