2009-06-19 11 views
5

Tôi chạy nhiều lần vào một vấn đề mà một người nào đó hỏi tôi về một lỗi hoặc một tính năng tôi đã làm việc trên. Và theo nghĩa đen, tôi mất rất nhiều thời gian để nhớ lại nó, thường là bằng cách xem Bugzila cũng như các báo cáo CVS của tôi. Vì vậy, tôi đang cố gắng tìm một cách tốt để ghi chép những gì tôi đã làm việc, và tìm kiếm các đề xuất của bạn. Trong thực tế, tôi thường lấy gần như ZERO ghi chú về những gì tôi đã làm, mặc dù tôi viết ghi chú khi nhận được đặc điểm kỹ thuật hoặc một số kỹ thuật.Các cách hiệu quả để ghi chú "lập trình" là gì?

Tôi nghe nói rằng một số người tạo một tài liệu mới cho mỗi vấn đề hoặc lỗi mà họ đang làm việc, và nối thêm thông tin cấu hình, đầu ra nhật ký, suy nghĩ của tôi và mọi thứ. Tôi nghĩ rằng nó tốt cho báo cáo hàng tuần/hàng tháng và như vậy, cộng với giúp ghi nhớ những điều bạn đã làm việc trên hoặc lỗi tương tự bạn đã cố định.

Vui lòng đề xuất cách bạn lưu ý?

+0

tôi sử dụng một wiki intranet. – jjclarkson

+0

chúng tôi cũng có wiki, nhưng bạn có nhập tất cả thông tin vào wiki liên quan đến lỗi của bạn không? Làm thế nào để bạn tìm kiếm nó? –

Trả lời

7

Sự đồng thuận dường như là blog hoặc sổ ghi chép vật lý là cách để đi. Chặn những người đó, bạn có thể sử dụng một wiki hoặc một ứng dụng như OneNote.

Xin xem câu hỏi này: https://stackoverflow.com/questions/78756/what-do-you-use-to-keep-notes-as-a-developer

+0

OneNote hoặc Evernote, tùy thuộc nếu bạn muốn có nhận dạng chữ viết tay (OneNote) hoặc đồng bộ hóa chung (Evernote trên PC/Mac/iPhone/v.v.). –

+5

FYI, Liên kết bị hỏng – Span

6

Bàn + Crayola

+0

Phiên bản mẫu giáo của Paper + Pen của tôi! – TheTXI

+0

Tường tầng hầm + Crayola? – rotard

+5

Điều tuyệt vời về điều này là bút chì sẽ tăng gấp đôi thức ăn nếu bạn bị đói. –

5

Một hệ thống kiểm soát nguồn tốt với ý kiến ​​mã tốt và một chính sách checkin bình luận tốt công trình kỳ diệu.

+0

Đó là câu trả lời _good_, ý định của pun :-) –

0

Ngoài trình theo dõi lỗi hoặc ghi chú trên máy vi tính, tôi luôn có sổ nhật ký mà tôi sẽ sử dụng để ghi lại mọi thứ có tầm quan trọng đối với mỗi ngày. Bằng cách đó tôi có thể dễ dàng quay trở lại thông qua nó và tìm ngày cụ thể và xem những gì tôi đã viết ở đó.

Paper + Pen vẫn là một công cụ tuyệt vời.

2

Hãy viết blog. Hoặc thiết lập một Wiki nội bộ cho ghi chú của nhà phát triển.

2

Bạn muốn đơn giản để bạn có thể tham gia rất nhanh. Tôi sử dụng một tập tin văn bản và thêm nó vào máy tính để bàn và giữ một tên tiêu chuẩn như NOTES, NOTES2 loại trong một định dạng README hoặc TODO với một ngày bất cứ khi nào bạn thêm mục mới.

Mọi thứ sẽ hoạt động miễn là đơn giản. Nếu bạn bắt đầu thêm các máy chủ và wiki và tất cả những thứ đó thì bạn đã quá phức tạp những gì bạn muốn.

+0

Các tệp văn bản cũng có thể dễ dàng tìm kiếm bằng các công cụ mạnh mẽ như grep. Chúng thậm chí là bằng chứng tương đối trong tương lai: Tệp văn bản ASCII dựa trên trung bình của bạn có thể được đọc bởi máy tính từ năm 1989 và gần như chắc chắn có thể đọc được bằng máy tính vào năm 2029. –

0

tôi đã được sử dụng máy tính xách tay Moleskine trong một thời gian dài tốt và bất cứ khi nào tôi chuyển sang cái gì khác (tôi đã sử dụng OneNote, WikidPad, Tomboy .. vv) Tôi luôn luôn trở về máy tính xách tay của tôi

Moleskine có tất cả các kích cỡ chưa kể đến ít nhất 3 loại giấy: đồng bằng, cai trị, lưới

http://www.moleskines.com/moleskine-softcover-xlarge-squared.html

Hope this helps

1

tôi là một phút thực tế imalist.

Notepad ++ mở trên màn hình bên phải của tôi mỗi ngày. Tôi thêm vào nó như tôi thấy phù hợp nhưng tôi luôn luôn đặt ghi chú vào lật đổ khi tôi cam kết thay đổi. Mọi thứ thay đổi nhanh chóng.

Tôi từng sử dụng tiddlywiki nhiều nhưng Notepad ++ hoạt động tốt hơn cho tôi và bị loại bỏ theo những gì tôi cần - một nơi để nhập mà tôi có thể tìm kiếm sau này.Điều tôi không thích về máy tính xách tay vật lý là tôi phải là công cụ tìm kiếm khi tìm kiếm những thứ trong một.

Đó là cách tôi thực hiện.

+0

Tương tự ở đây, tôi giữ một danh sách thay đổi/ghi chú/danh sách việc cần làm ngắn gọn trong notepad ++ cho từng dự án mà tôi làm việc. – RYFN

0

Tôi sử dụng cat >> ~/TODO, blog hoặc viết xuống trong sổ ghi chép (vật lý).

3

Mọi người đã gợi ý nhiều cách để ghi lại thực tế ghi chú, nhưng tôi nghĩ cách tiếp cận là quan trọng nhất. Ở đây tại công việc của tôi, chúng tôi làm việc trên phần mềm tùy chỉnh cho nhiều công ty khác nhau và vào cuối mỗi giai đoạn trả tiền, chúng tôi gửi cho họ một bảng chấm công mà họ phải ký tên để chúng tôi lập hoá đơn cho họ. Nó chỉ như vậy sẽ xảy ra rằng Timesheet này vạch ra tất cả các công việc mà một nhà phát triển đã làm, và thường là cấu trúc là một cái gì đó như thế này.

Đồng hồ In - 8:00 AM

Phân tích - 10:30 AM
Mô tả công việc phân tích được thực hiện.

Mã hóa - 12:30 PM
Mô tả tất cả công việc mã hóa được thực hiện.

Ý tưởng là để chứng minh cho khách hàng rằng bạn không ở trên StackOverflow cả ngày khi bạn thanh toán cho họ. Kết quả là bạn đăng nhập tất cả các mã hóa, gỡ lỗi, vv mà bạn làm.

Mặc dù tôi là người đầu tiên thừa nhận rằng quá trình này là một nỗi đau, tôi không thể đếm số lần tôi quay lại để xem các bảng chấm công trước đây của mình để xem cách tôi giải quyết vấn đề mà tôi ' m gặp lại một lần nữa, hoặc để tìm ra nơi tôi rời đi trên một số dự án tôi đã không xúc động trong một thời gian. Thật tuyệt vời.

0

Tùy thuộc vào môi trường của bạn, bạn có thể tạo thẻ tùy chỉnh dọc theo dòng // TODO: Ngoài ra, bạn nên đặt hệ thống kiểm soát nguồn của mình từ chối đăng ký mà không có nhận xét.

Cách tốt nhất tuyệt đối để ghi lại điều gì đó theo thời gian, để cho bạn biết những gì bạn đã làm và người tiếp theo biết cách duy trì nó, là các bài kiểm tra đơn vị chống lại tất cả các thay đổi của bạn. Chuyển sang chế độ xem có chú thích của nguồn cho các bài kiểm tra đơn vị và bạn có ngày và giờ.

Tôi cũng thích một lưu ý, thật dễ dàng để kéo và thả bất kỳ định dạng nào vào và bạn không lo lắng về việc mở, lưu, bất cứ điều gì, chỉ cần để nó chạy và nó sẽ xử lý các chi tiết.

4
  • có blog, ngay cả khi không ai đọc blog. Viết một bài báo/howto/những gì tôi đã làm trên bất cứ điều gì bạn tìm ra rằng bạn có thể muốn nhớ tháng hoặc năm kể từ bây giờ. Ai biết được, ai đó khác cũng có thể thấy nó hữu ích.
  • sử dụng Trac hoặc Github cung cấp một wiki tuyệt vời cho từng dự án. Ngoài các thông điệp cam kết của bạn, bạn có thể giữ các ghi chú và cách thức trong wiki cụ thể cho một dự án. Obv. điều này giúp trong tài liệu và với phần còn lại của nhóm của bạn
  • để ghi chú ngắn hạn, hãy giữ sổ tay và bút chì tiện dụng. Nhưng nếu bạn giống tôi, bạn sẽ mất hoặc thất lạc những điều này trước khi dài
  • lưu giữ tệp TODO và CHANGELOG trong từng dự án. Đôi khi rất khó để duy trì, nhưng tôi đã có nhiều lần khi những người đó cứu tôi ##
  • nếu thực sự quan trọng, hãy xăm nó trên cánh tay của bạn giống như anh chàng trong Memento.

Tôi có trí nhớ khá tệ và không nhớ bất cứ điều gì sau 2 tuần (thường là tôi làm, nhưng tại thời điểm đó bạn không thể dự đoán có hay không bạn sẽ nhớ một thứ nhất định). Vì vậy, đây là những thích ứng của tôi và làm việc khá tốt.

+0

+1 cho thay đổi. –

0

hệ thống riêng của tôi là:

  • Index cards cho giấy ghi chép ngay lập tức xuống thứ tôi cần phải nhớ hoặc tài liệu tham khảo. (Hầu như tất cả trong số này được vứt bỏ vào cuối ngày.)
  • OmniOutliner cho các ghi chú cá nhân
  • OmniFocus cho công việc phải làm liệt kê
  • comments hệ thống Bug-theo dõi để biết về việc theo dõi xuống và sửa chữa lỗi
  • Wiki để biết được chia sẻ với đội
  • Blog cho các công cụ mà có thể là mối quan tâm chung để các lập trình viên ở khắp mọi nơi

Thông thường, mọi thứ bắt đầu trong OmniOutliner sau đó được sao chép-và-dán vào các hệ thống khác cho phù hợp.

Tìm kiếm Spotlight của Macbook của tôi rất hữu ích trong việc tìm kiếm mọi thứ, vì vậy tôi không lo lắng quá nhiều về tổ chức.

0

Tôi tìm thấy TodoList từ trang web này: http://www.abstractspoon.com/ Dễ sử dụng, không yêu cầu cài đặt và có các tính năng đẹp.

Và để xử lý các ghi chú khác, tôi khuyên bạn nên WikiPad, cho phép bạn cấu trúc thông tin.

0
  • Trình theo dõi lỗi cho các lưu ý liên quan đến việc điều tra một vấn đề cụ thể. Điều này có thể bao gồm mã kiểm tra, kết quả đầu ra nhật ký, cập nhật về cách bạn thu hẹp mọi thứ xuống và những gì bạn đã loại trừ. Tôi cố gắng giả định rằng tôi sẽ bị một chiếc xe buýt chạy qua, và ai đó sẽ tiếp quản lỗi này vào ngày mai. Họ sẽ có các ghi chú theo dõi lỗi, bất kỳ mã nào trong thư mục làm việc hiện tại của tôi trên máy tính của tôi và có thể giả định là không thể đọc được chữ viết tay của tôi. Họ muốn trở thành nơi tôi đến muộn nhất là 10 giờ sáng. Nó chắc chắn sẽ bao gồm một mô tả đầy đủ về vấn đề gây ra lỗi, và nó đã được sửa chữa như thế nào, đối với hồ sơ lịch sử. Đây là những gì bạn sẽ đến khi ai đó hỏi "bugfix đó là gì?". Các chi tiết liên tục là những gì bạn đề cập đến nếu ai đó nói, "Tôi đã nhìn thấy một vấn đề tương tự ở một nơi khác, tôi nên kiểm tra những gì?"
  • Tương tự với các tính năng và thay đổi mới, sử dụng trình theo dõi lỗi, trình theo dõi yêu cầu, tài liệu thiết kế hoặc bất kỳ thứ gì bạn có.
  • Nhận xét bằng mã cho các ghi chú giải thích lý do tại sao việc triển khai thực hiện như thế nào.
  • Nhận xét trong tài liệu cho các ghi chú giải thích lý do giao diện là như thế nào ("lý do").

Tôi không thích lưu ý cá nhân về mã của mình chỉ cho tôi, ngay cả trên Wiki hoặc blog về mặt lý thuyết. Không ai khác có thể tìm thấy chúng khi họ cần chúng, trừ khi có thể (1) bạn có một công cụ tìm kiếm nội bộ thực sự tốt, và (2) mọi người đều viết blog một cách công phu, như những người khác mong đợi có một thứ đáng để tìm kiếm. Nếu các ghi chú liên quan đến mã, thì chúng phải ở trong mã, hoặc tài liệu của nó, hoặc ít nhất là trong trình theo dõi lỗi (giải thích điều gì sai với mã trước đó, trong khi các chú thích giải thích điều gì đúng với phiên bản hiện tại) .

Lưu ý rằng, "tôi phải làm gì để cài đặt và làm việc IDE", chắc chắn, chúng đi trong một wiki hoặc blog. Nội dung nào đó công khai hoặc đồng nghiệp của bạn có thể xem và tìm kiếm nhưng điều này dành riêng cho bạn vì bạn là người có nhiều khả năng muốn có nó nhất.

Nếu bạn đang làm việc trên mã nguồn mở, thì việc viết blog có thể là một lựa chọn tốt hơn vì mọi người trên thế giới có thể muốn biết về nó và có thể sẽ tìm kiếm toàn bộ trang web để biết thông tin. Nhưng tôi chưa bao giờ làm việc trên một dự án mã nguồn mở quan trọng.

0

Tôi là người hâm mộ lớn của Nick Cernis 'Todoodlist.

1

Tôi nhận thấy rằng TiddlyWiki thực sự hữu ích. Đó là một wiki khép kín mà tôi sử dụng để theo dõi các ghi chú về mọi thứ - từ việc cần làm cá nhân đến ghi chú về việc thực hiện các tính năng cụ thể. Kết hợp với Dropbox và nó hiển thị trên tất cả các hệ thống của tôi.

1

Cài đặt công cụ tìm kiếm trên máy tính để bàn. Ghi chú tệp văn bản chỉ mục, nhật ký email và IM.

Ngoài ra, đôi khi tôi sẽ thêm nhận xét vào thẻ yêu cầu lỗi/tính năng với ghi chú kỹ thuật - được gắn nhãn rõ ràng để không gây nhầm lẫn cho người xem không có kỹ thuật.

0

Mặc dù đây không phải là tất cả những kỹ thuật đó, tôi đã trở thành người hâm mộ lớn của Hipster PDA.

(Nói tóm lại:. Một chồng thẻ 3x5 và một clip chất kết dính Nó thực sự khá hữu ích.)

0

I Like jira của nó thiết kế rất tốt, nhưng không miễn phí

http: // www.atlassian.com/software/jira

0

Một cách khác để ghi chú là sử dụng Bản đồ tư duy. Phải mất một chút để có được hang của nó, nhưng tôi đã tìm thấy những điều này là vô cùng quý giá trong việc tổ chức những suy nghĩ của tôi về các chủ đề khác nhau, bao gồm các nhiệm vụ lập trình. Tôi thậm chí còn vá một trong những công cụ để chuyển đổi tâm thức của tôi trực tiếp thành các danh sách lồng nhau có thể dán vào một chú thích Jira :) Làm cho ghi chú đọc mã và ghi chú thiết kế/ước tính rất dễ dàng để xây dựng và thay đổi.

Một vài công cụ mà làm việc tốt cho bản đồ tâm trí: