Tôi có nên giữ danh sách việc cần làm trong điều khiển nguồn không?

Question

Tôi gặp một số khó khăn trong việc tìm ra cách tốt nhất để lưu trữ danh sách công việc lập trình của tôi.

tôi xem xét như sau: danh sách

• một todo trong kiểm soát nguồn cho từng dự án
• một danh sách tổng thể todo (với nhiệm vụ chung) trong một thư mục cá nhân trong kiểm soát nguồn

thế nào bạn có thấy không?

Bạn sẽ đề xuất điều gì?

Chỉnh sửa:

Cảm ơn bạn đã đề xuất. Tôi sử dụng một hệ thống theo dõi lỗi (BugTracker.NET) cho các lỗi và các nhiệm vụ liên quan đến các yêu cầu từ những người khác để họ có thể thấy trạng thái. Và tôi sử dụng // TODO trong mã.

Tôi có nhiều ghi chú bổ sung về việc cần làm. Bạn có khuyên bạn nên đặt nó vào trình theo dõi lỗi (đặc biệt nếu không thể đặt chúng dưới dạng // TODO trong mã)?

Answer 1

tại sao bạn không sử dụng hệ thống theo dõi lỗi?

ví dụ: Bugzilla Mantis Trac

và nhiều người khác ...

Answer 2

Bạn nên giữ bất kỳ văn bản đó được sửa đổi trong kiểm soát nguồn. Và điều đó không bao gồm mã được tạo ra (trừ khi bạn có trình tạo crappy không thể chạy như một phần của quá trình xây dựng) và tất cả các tệp nhị phân có ngoại lệ được ghi nhận của các phụ thuộc nhị phân.

Answer 3

Tôi muốn sử dụng http://rememberthemilk.com hoặc http://basecamphq.com

Answer 4

Một hệ thống theo dõi lỗi là một công cụ quan trọng để phát triển.

Bạn cũng có thể có danh sách Todo dựa trên web đơn giản, chẳng hạn như RtM.

Cuối cùng, bạn cũng có thể sử dụng // TODO "dấu trang" trong mã của mình, vì IDE cung cấp các hàm chức năng để định vị chúng dễ dàng.

Answer 5

Tôi sử dụng OnTime2008 có phiên bản phát triển đơn lẻ miễn phí (tối đa 5 khách hàng) để theo dõi các dự án phát triển của tôi. Bugzilla sẽ là một cách tiếp cận tốt. Không chắc chắn tôi muốn theo dõi những thay đổi trong danh sách 'todo' của tôi vì tôi không bao giờ cần phải quay lại những thay đổi đó, tôi muốn tất cả các hoạt động được ghi lại, warts-và-tất cả!

Answer 6

Bạn nên giữ mã số todos trong mã của mình. Thích hợp nhất với một chương trình bugtracking. Và sau đó bạn nên sử dụng một chương trình tạo tài liệu để nắm bắt tất cả các todos và ghi chúng vào một danh sách với các liên kết đến các phần có liên quan của mã.

Một ví dụ điển hình là Doxygen.Với todo trong mã:

// TODO: fix potential non-assigment of var 
int my_var; 

Doxygen sẽ có thể lấy thông tin này (thậm chí bạn có thể thiết lập các bộ lọc cho các chú thích tùy ý, như FIXME BUG LOOK_HERE và vân vân) và a) lại một bài viết todo cho cụ thể class/interface và b) biên dịch một danh sách các todos cho dự án hoàn chỉnh.

Ngoài ra, danh sách todos và todo của bạn sẽ được kiểm soát phiên bản và danh sách (ví dụ: tài liệu) dễ dàng được tạo từ đầu.

Vì vậy, để tổng hợp: Một sự kết hợp của Doxygen, một hệ thống SCM (any sẽ làm) và bugzilla sẽ giúp bạn có được và chạy trong thời gian không.

Cập nhật: Kiểm tra this git hook tạo ra các vấn đề Github từ Todos trong checkins bạn

Và một lưu ý chung cho câu hỏi có hay không sử dụng Todos trong mã của bạn là một điều tốt (TM): Một kẻ ngốc với một công cụ vẫn là một kẻ ngốc.

Answer 7

Tôi thường nghĩ đến các mục TODO trong khi tôi đang mã hóa. Thông thường, để không làm gián đoạn luồng suy nghĩ của tôi, tôi sẽ nhanh chóng ném vào // TODO: nhận xét nhanh chóng mô tả những gì tôi đang suy nghĩ và sau đó tiếp tục viết mã.

Điều quan trọng không phải là để mất thực tế rằng một cái gì đó cần phải được thực hiện!

Sau đó, tôi sẽ quay lại và tạo một vé trong phần mềm theo dõi vấn đề của tôi .. bạn đang sử dụng phần mềm theo dõi vấn đề không? :) Sau đó, TODO có thể được gỡ bỏ khỏi mã.

Cố gắng sử dụng thẻ nhận xét nhất quán để bạn có thể dễ dàng grep chúng sau này (tìm kiếm văn bản).

Nhiều môi trường phát triển nhận ra các thẻ cụ thể và hỗ trợ tìm và quản lý chúng.

Đừng ngại đặt chúng vào mã và cố gắng không duy trì hai bản sao khác nhau của một TODO duy nhất.

Answer 8

1. Một danh sách cần làm trong kiểm soát nguồn cho từng dự án. Với một chút cẩn thận, điều này sẽ trở thành dữ liệu Scrum burndown của bạn. Một chút cắt và dán tạo ra một biểu đồ để quản lý sử dụng.

2. Nhận xét TOD rõ ràng trong mã - những này cần khớp với danh sách việc cần làm. Đồng bộ hóa và ưu tiên thủ công định kỳ là quan trọng.

3. Bugzilla để theo dõi lỗi (khác với hướng tới tương lai todo của)

Answer 9

Nếu bạn sử dụng TFS, bạn có thể sử dụng hạng mục công trình để đại diện cho todo mục danh sách. Chúng có thể được giao cho người dân, gắn liền với check-in, có các chi tiết gắn liền với họ, vv

Answer 10

Tôi yêu Basecamp HQ

Bạn có thể kiểm soát được rất nhiều điều từ quản lý dự án có liên quan.

Tôi muốn giới thiệu trang web đó.

Answer 11

Có nếu bạn không có hệ thống theo dõi vấn đề. Hãy chắc chắn rằng nó ở định dạng văn bản thuần túy (các vấn đề được phân tách bằng dòng mới) để mọi người có thể chỉnh sửa-cam kết hợp nhất tệp đó cùng một lúc.

Nếu không, chỉ cần theo dõi vấn đề.

Answer 12

Trong Eclipse (cho Java), có một cái nhìn rất đẹp cho phép bạn quản lý TODOS của bạn:

• xem tất cả trong số họ, bất cứ điều gì (mở) dự án họ đang ở trên
• có ba cấp độ ưu tiên cho họ
• sử dụng một số từ khóa, có nghĩa là những thứ khác nhau cho nhóm của bạn (ví dụ, FIXME có thể gây nhiều bức xúc với ưu tiên cao, mở rộng có thể là một khả năng trong tương lai cho gia hạn với một ưu tiên thấp vv ..)