Nhảy xung quanh để làm việc trên các tính năng khác nhau khi bạn gặp khó khăn, đó có phải là một nguồn thất bại của dự án?

Trong các dự án cá nhân (hoặc công việc), nếu một người gặp vấn đề hoặc chờ đợi để tìm ra giải pháp cho vấn đề, nếu bạn chuyển sang phần khác của mã, bạn không nghĩ rằng đó sẽ là lý do chính đáng cho ứng dụng của bạn sẽ có lỗi hoặc tệ hơn nhưng không bao giờ được hoàn thành?

Giả sử bạn không sử dụng git và mã từng tính năng cho một nhánh cụ thể, mọi thứ có thể vượt khỏi tầm kiểm soát vì bạn có 3 tính năng khác nhau mà bạn đang làm việc và bạn có các vấn đề chưa được giải quyết trong mỗi tính năng.

Vì vậy, khi bạn hoàn thành công việc, bạn sẽ bị căng thẳng vì bạn có những vấn đề treo này và mã nửa nướng còn sót lại.

Cách tốt nhất để tránh vấn đề này là gì? (nếu bạn có nó)

Tôi đoán sử dụng một cái gì đó như git và tạo một nhánh cho mỗi tính năng là cách an toàn nhất để tránh thói quen xấu này.

Bất cứ một đề nghị nào khác?

Đây không phải là một vấn đề. Tạm thời bước ra khỏi một vấn đề rắc rối là một trong những cách tốt nhất để có một bước đột phá về vấn đề như vậy (sau này khi bạn đang nghĩ về nó hoặc lần sau khi bạn ngồi xuống với một quan điểm / tâm trí mới).

Luôn đảm bảo rằng bạn sử dụng phân nhánh kiểm soát nguồn đúng cách và bạn sẽ không phải lo lắng về một nửa giải pháp trong mã. Một số người không bao giờ cam kết nghỉ, nhưng đó chỉ là một lựa chọn cá nhân. Bạn không bao giờ nên thực sự đẩy nghỉ để chia sẻ với người khác mặc dù.

Như smp7d đã đề cập , nhảy xung quanh có thể giúp bạn giải tỏa tinh thần khỏi vấn đề trong tầm tay. Tuy nhiên, điều quan trọng là đừng quên rằng mã bạn đang làm việc vẫn chưa hoàn thành. Hãy chắc chắn rằng bạn biết nơi bạn rời đi.

Như smp7d đã đề cập, kiểm soát nguồn và phân nhánh là một cách tuyệt vời để tách mã tính năng mới của bạn ra và xem nó khác với cơ sở mã chính như thế nào.

Một gợi ý tôi có là nếu bạn đang làm việc trên một phương thức cụ thể, hãy đảm bảo rằng có một bài kiểm tra đơn vị được đặt tên tốt xung quanh phương thức đó. Theo cách đó khi bạn làm việc với mã đó vào ngày / tuần / tháng / năm tiếp theo, bạn sẽ có thể nói rõ phương pháp được cho là làm gì, ngay cả khi hiện tại nó không vượt qua bài kiểm tra.

Đó có phải là vấn đề? Không phải khi nó xảy ra với bạn 10% các tính năng bạn đang cố gắng thực hiện. Đôi khi bạn có được đầu óc minh mẫn hơn khi bạn làm điều gì đó khác biệt trước.

Rõ ràng đó là một vấn đề khi bạn gặp khó khăn với 90% các tính năng bạn cố gắng thực hiện - sau đó bạn cần sự giúp đỡ của người khác, hoặc một cú đá nhẹ từ sếp của bạn để hoàn thành những gì bạn đã cầu xin (tất nhiên, sau này sẽ được chống lại năng suất nếu bạn gặp khó khăn vì một vấn đề kỹ thuật thực sự).

Tùy chọn tốt nhất cho trường hợp này thường là cố gắng phân chia tính năng bạn đang làm việc thành các tính năng phụ nhỏ hơn hoặc "lát cắt tính năng", có thể được triển khai, thử nghiệm và gỡ lỗi từng cái một. Đối với tôi, nó giúp viết các lát cắt tính năng, các vấn đề mở, các phần cần hoàn thành trong danh sách, ưu tiên cho chúng (A, B, C là đủ) và làm việc với những thứ được ưu tiên cao nhất trước tiên.

Đó là kinh nghiệm của tôi rằng "nhảy lung tung", hay rõ ràng hơn là "Nhảy ngẫu nhiên xung quanh" là một triệu chứng của một vấn đề cấp bách hơn, một trong những mục tiêu được nêu rõ.

Nếu bạn có một ý tưởng rất rõ ràng, bằng văn bản, cho dù ghi chú sau nó ở bên cạnh màn hình của bạn hoặc trong thông số kỹ thuật chính thức được đính kèm theo trình theo dõi vấn đề của bạn, thì bạn hầu như luôn biết chính xác những gì sẽ làm việc tiếp theo . Nếu bạn luôn làm việc với một trong những điều tiếp theo, thì bạn sẽ có cơ hội thành công với dự án.

Mặt khác, nếu ý tưởng của bạn về điều quan trọng nhất tiếp theo là mơ hồ, thì thực sự khó tìm ra một thứ để giải quyết vấn đề thực sự mà dự án của bạn nhắm đến, hay cụ thể hơn, nó ít bị cắt hơn - và khô khan khi quyết định rằng sự thay đổi cụ thể này đã hoàn tất và giải quyết một vấn đề cụ thể.

Nếu bạn có một mục tiêu như "làm cho giao diện người dùng dễ sử dụng hơn", thì không thể nói được cách khắc phục tiếp theo là gì, hoặc khi bạn đã hoàn thành "sửa giao diện người dùng" và có thể chuyển sang một thứ khác. Mặt khác, nếu bạn có một mục tiêu như "kết hợp các trình đơn thả xuống này vào trường tìm kiếm với tự động hoàn thành" và "'foo" nên tự động hoàn thành để' Đánh lừa thương hiệu ', hoàn toàn rõ ràng khi bạn đã sửa Vấn đề đó.

Đừng viết bất kỳ mã nào cho đến khi bạn có ý tưởng thực sự rõ ràng về thời điểm dừng và nếu bạn không có ý tưởng rõ ràng nào, hãy tìm một trong số đó thay vì bắt đầu một nhánh khác cho một số tính năng chung.

Nếu bạn có một công việc tốt như vậy (ngay cả đối với các dự án cá nhân), thì "nhảy lung tung" là hoàn toàn tốt và an toàn và hữu ích.

Trong khi tránh xa một vấn đề có thể giúp bạn giải quyết nó, hãy nhớ rằng có một chi phí để chuyển đổi bối cảnh. Bạn chỉ nên cố gắng làm điều đó khi bạn thực sự bế tắc hoặc một nhiệm vụ quan trọng xuất hiện (ví dụ: một khách hàng không hoạt động).

Nếu bạn liên tục chuyển đổi qua lại giữa các tác vụ, bạn có thể kết thúc với một số tính năng đã hoàn thành một nửa và rất nhiều thời gian lãng phí. Đây là lý do tại sao các thực hành như kan-ban khuyến khích bạn đặt công việc trong giới hạn tiến độ. Bằng cách này, bạn có thể tập trung vào việc hoàn thành, nhiều nhất, chỉ một vài nhiệm vụ tại một thời điểm, do đó tăng thông lượng.

Đôi khi nó có thể hữu ích để giới hạn số lượng các tính năng được triển khai song song. Từ chối bắt đầu triển khai một tính năng bổ sung nếu vượt quá giới hạn đó cho đến khi một tính năng khác kết thúc. Cách tiếp cận này được gọi là Kanban