Làm thế nào tôi nên nhớ những gì tôi đã làm và tại sao trong một dự án ba tháng trở lại?


72

Tôi đang thực hiện một dự án ba tháng trước, và rồi đột nhiên một dự án khẩn cấp khác xuất hiện và tôi được yêu cầu chuyển sự chú ý của mình.

Bắt đầu từ ngày mai, tôi sẽ quay trở lại dự án cũ. Tôi nhận ra rằng tôi không nhớ chính xác những gì tôi đã làm. Tôi không biết bắt đầu từ đâu.

Làm thế nào tôi có thể ghi lại một dự án sao cho bất cứ khi nào tôi nhìn lại, tôi sẽ không mất nhiều hơn một vài phút để đi từ bất cứ nơi nào tôi rời đi. Có thực hành tốt nhất?


98
bình luận và cam kết tin nhắn, có một lý do mọi người bảo bạn rời bỏ chúng
ratchet freak

5
Điều này có thực sự phụ thuộc vào cách bạn theo dõi dự án ở nơi đầu tiên không? Chúng tôi có nên cho rằng bạn đang làm mọi thứ từ bộ nhớ và không có tài liệu nào khác không?
JeffO

4
@ratchetfreak Tôi đã định nói "Điều đó chỉ hữu ích cho các nhà phát triển" cho đến khi tôi nhận ra rằng bạn có thể áp dụng nguyên tắc tương tự cho bất cứ điều gì. Hầu hết các kho tài liệu có một phần ghi chú hoặc mô tả; việc gửi qua email có nội dung thư (thường bị bỏ qua). Tài liệu có thể đã theo dõi các thay đổi và chú thích. Có cả một hệ sinh thái bình luận và thông điệp cam kết trong thế giới PM! </ epiphany>
corsiKa

6
Tôi sử dụng hệ thống kiểm soát phiên bản để nhắc nhở tôi những gì tôi đã làm lần trước và một trình theo dõi lỗi để tìm hiểu những gì vẫn cần phải làm.
Lie Ryan

2
Ồ vâng, một lần sau ba tháng nghỉ việc, tôi được hỏi về một cuộc phỏng vấn xin việc để mô tả dự án cuối cùng của tôi. Tôi đã làm điều đó, nhưng khi họ hỏi chi tiết, tôi không thể nhớ cuộc sống của mình. Họ từ chối tôi vì rõ ràng tôi là kẻ giả dối nếu tôi không thể nhớ điều đó. Điều này đã xảy ra khoảng 15 năm trước, nhưng tôi vẫn nhớ nó.
Andrew Savinykh

Câu trả lời:


35

Tôi chỉ muốn đóng góp một số lời khuyên sẽ không hữu ích trong tình huống hiện tại của bạn, nhưng bạn có thể bắt đầu thực hiện nó ngay bây giờ để giúp đỡ trong tương lai.

Tất nhiên có những ứng cử viên rõ ràng như danh sách việc cần làm và nhật ký phát hành; nhìn vào các vấn đề được thêm gần đây sẽ cho bạn manh mối về những gì bạn đang làm khi bạn bị loại khỏi dự án.

Trong các dự án trước đây tôi đã làm việc, mọi người dự kiến ​​sẽ giữ một nhật ký dự án như là một phần của quy trình quản lý chất lượng. Nội dung không được chỉ định rõ ràng, nhưng ý tưởng là ghi nhật ký hàng ngày những thứ liên quan đến dự án có thể hữu ích cho công việc tiếp tục trong tương lai hoặc cho các hoạt động đánh giá khi hoàn thành; ví dụ:

  • Quan sát về chất lượng của dự án

    mã này có thể sử dụng một số tái cấu trúc

    đã thực hiện nhanh chóng để làm việc này nhưng ABC sẽ tốt hơn.

  • Các mục / vấn đề Todo mà bạn không muốn chính thức ghi lại trong trình theo dõi vấn đề

    "Nên làm cho phương pháp này hoạt động x < 0nhưng hiện tại không nằm trong phạm vi.

  • Quyết định thiết kế - đặc biệt là những người không tầm thường.

    Hàm sắp xếp tiêu chuẩn của chúng tôi thực hiện sắp xếp nhanh, nhưng điều đó không bảo toàn thứ tự các mục bằng với điều kiện sắp xếp, mà chúng tôi cần ở đây.

    Thuật toán rõ ràng sẽ là ABC nhưng thất bại ở đây vì xcó thể âm nên chúng ta cần dạng tổng quát ( liên kết Wikipedia ).

  • Vấn đề gặp phải và cách bạn giải quyết chúng. Theo ý kiến ​​cá nhân của tôi, một điều rất quan trọng: bất cứ khi nào bạn gặp vấn đề đều ghi chú vào nhật ký.

    Đã kiểm tra mã nhưng nó đã báo lỗi XYZ0123, hóa ra lần đầu tiên tôi phải nâng cấp thành phần C lên phiên bản 1.2 trở lên.

Hai điểm sau rất quan trọng. Tôi thường gặp phải một tình huống hoặc vấn đề tương tự - đôi khi trong một dự án hoàn toàn khác - và nghĩ "hmm, tôi nhớ đã dành một ngày cho việc này, nhưng giải pháp lại là gì?"

Sau khi bạn quay lại dự án sau một thời gian, đọc lại nhật ký dự án (dù đó là của riêng bạn hay nhà phát triển mới nhất) sẽ đưa bạn trở lại dòng chảy mà bạn có khi bạn rời đi và cảnh báo bạn về một số bẫy mà bạn gặp phải mặt khác có thể rơi vào một lần nữa


68

Danh sách việc cần làm là ma thuật. Nói chung, bạn cần giữ một danh sách việc cần làm tích cực cho từng dự án và ngay cả khi bạn đang bận lập trình, nếu bạn nghĩ ra việc gì đó phải hoàn thành và bạn không thể thực hiện ngay lập tức, thì nó sẽ nằm trong danh sách. Giữ danh sách này ở một nơi nổi tiếng, trong bảng tính hoặc tệp văn bản trong thư mục dự án điện tử hoặc trong nhật ký giấy của bạn.

Ngoài ra, bất cứ khi nào bạn rời khỏi dự án để qua đêm (hoặc cuối tuần), hãy ghi chú lại và viết điều tiếp theo bạn sẽ làm trên ghi chú và dán nó vào màn hình. Điều đó làm cho nhiều khả năng bạn sẽ quay lại với nó một cách nhanh chóng vào sáng hôm sau.

Chỉnh sửa :

Tôi nên đề cập rằng các danh sách việc cần làm (đặc biệt là các danh sách việc cần làm được phân tách theo địa điểm và dự án) là một phần quan trọng của cuốn sách Get Things Done , mà tôi thấy có ảnh hưởng lớn.


22
Và nếu bạn đang làm việc với một dự án nhanh với các nhiệm vụ nhỏ, thì tồn đọng sẽ là danh sách việc cần làm chính của bạn cho dự án đó.
Bart van Ingen Schenau 22/07/14

1
Gần đây tôi đã bắt đầu làm những gì bạn đề cập trong đoạn cuối và nó đã giúp tôi đi vào buổi sáng.
TMH

5
Thật. Luôn đỗ xe xuống dốc. Đó là vấn đề của thói quen. Tôi không bao giờ để lại một cơ sở mã mà không ghi chú cho mình trong mã hoặc trong danh sách việc cần làm của tôi về những việc cần làm tiếp theo. Tôi cũng đảm bảo rằng tất cả mọi thứ tôi biết tôi vẫn phải làm là trong một việc cần làm trong nguồn (Tôi sử dụng quy ước TODO: trong các nhận xét mà IDE của tôi có thể phát hiện và trình bày dưới dạng danh sách) hoặc trong danh sách việc cần làm riêng của tôi (tôi chỉ có một cho tất cả các dự án, nhưng nó được phân loại và ưu tiên).
Joeri Sebrechts

3
TODO trong mã là tuyệt vời, nhưng bạn phải siêng năng về việc đặt chúng ở đó, ngay cả đối với những điều nhỏ bé tuổi teen. Có một todomục tiêu trong tệp thực hiện của bạn mà loại bỏ chúng cũng rất hữu ích.
Blrfl

4
trello.com là một cứu tinh. Ngay cả đối với các cuộc họp nhóm Thứ Hai, nơi tôi đấu tranh để nhớ những gì tôi đã làm tuần trước và những gì tôi nên làm trong tuần này. Nó cũng miễn phí.
SimonGates

33

Làm gì bây giờ?

Bây giờ, từ ngày mai tôi sẽ quay trở lại dự án cũ của mình và tôi nhận ra rằng tôi không nhớ chính xác mình đang làm gì và bắt đầu từ đâu!

Tôi đoán là bạn chưa thực hiện bất kỳ phần tiếp theo. Vì vậy, tìm kiếm một danh sách việc cần làm sẽ không hoạt động.

  1. Chặn một khoảng thời gian. Đặt điều này trên lịch của bạn và dành thời gian xem xét dự án. Điều này có thể được xem xét tài liệu, mã, yêu cầu, vv
  2. Chấp nhận nó sẽ mất một thời gian để lấy lại tốc độ. Hãy chắc chắn rằng tất cả những người liên quan nhận ra điều này. Hãy chắc chắn rằng bạn nhận ra điều này.
  3. Bắt đầu với một nhiệm vụ nhỏ. Xây dựng lại sự tự tin của bạn một số bằng cách làm một cái gì đó nhỏ. Nếu bạn có một danh sách các mục mới, trước tiên hãy làm việc với các mục nhỏ hơn. Điều này không chỉ xây dựng lại sự tự tin của bạn mà còn giúp bạn làm lại chính mình với dự án.

Làm thế nào để làm điều này tốt hơn cho bản thân trong tương lai?

Tôi muốn biết làm thế nào để ghi lại dự án sao cho bất cứ khi nào tôi nhìn lại, tôi sẽ không mất nhiều hơn một vài phút để đi từ bất cứ nơi nào tôi rời đi!

Đầu tiên, bạn cần phải có một hệ thống để theo dõi các todos của bạn. Bạn có một hệ thống như vậy bây giờ? Làm thế nào để bạn quản lý dự án hiện tại của bạn?

Tôi có thể bị xe buýt đâm vào ngày mai và nhóm của tôi sẽ có ý tưởng tốt về hơn 90% các mục hành động của tôi. Điều này là do tôi có một hệ thống gắn kết để ghi lại tài liệu của mình:

  • Mã thông báo ngay lập tức (các mục <1 tuần)
  • "Rất vui được" todos
  • Các cột mốc và mã thông báo vĩ mô (trong đó chi tiết cụ thể không có ý nghĩa)
  • Yêu cầu / ghi chú cuộc họp

Thêm vào đó, tôi sử dụng một VCS và nhận xét mã của mình khi thích hợp.

Điều này làm việc cho tôi và nhóm của tôi vì tôi là nhà phát triển chính. Bạn có thể sử dụng một số loại hệ thống theo dõi vấn đề cho một nhóm. Hoặc tồn đọng khi làm việc với Agile. Có rất nhiều lựa chọn. Nếu bạn thực sự quan tâm đến điều này, hãy đọc phần Bắt đầu hoàn thành hoặc các phương pháp quản lý tác vụ có liên quan khác, tồn tại gần như chính xác vì những gì bạn mô tả.

Vấn đề ở đây là gì?

Các chi tiết cụ thể của hệ thống ít liên quan hơn là hệ thống gắn kết và bạn sử dụng nó . Và bạn sử dụng nó. Và sử dụng nó. Điều này quan trọng. Quan trọng hơn một hệ thống hoàn hảo tốt đẹp mà bạn không sử dụng. Đừng làm "hầu hết công việc của tôi đều ở đây, nhưng một số trong đầu tôi" hoặc bạn sẽ ghét bản thân mình khi quay lại dự án.

Ngoài ra, hãy chắc chắn rằng ý kiến ​​của bạn giải thích "tại sao" thay vì chỉ "cái gì" cho mã. Thật dễ dàng hơn để đọc "đây là sửa lỗi với IE8" và nhớ lại những gì mã làm hơn là một nhận xét chỉ đơn giản là giải thích các chi tiết kỹ thuật.


@TheInepereeAquarius không có vấn đề gì, rất vui vì nó hữu ích. Tình hình đó có thể áp đảo.
enderland

@TheInepereeAquarius có thể bởi vì các bình luận nói chung được dự định là ít nhiều sau bài đăng của nó. Cách Stack Exchange có những điều thiết lập để nói, "câu trả lời này thật tuyệt" là nâng cao hoặc chấp nhận câu trả lời. Bình luận ở đây không nhất thiết phải kéo dài.
thúc

Một phiên bản hợp lý hơn nhiều của danh sách "việc cần làm" này là sử dụng hệ thống theo dõi vấn đề. Có rất nhiều hệ thống miễn phí có sẵn và nhiều nhà cung cấp Git miễn phí có một hệ thống như vậy được tích hợp trong dịch vụ của họ (xem: GitHub).
BTownTKD

@BTownTKD Tôi nói điều đó trong câu trả lời của mình :)
enderland 23/07/14

Đó là một câu trả lời tốt; thêm để nhấn mạnh.
BTownTKD

14

Theo tôi, có hai phần để "nối lại" một dự án mã:

  1. Xác định nơi bạn rời đi
  2. Nhớ những gì còn lại bạn phải làm

Đây là một trong những điều mà theo tôi, nếu bạn đang thực hiện kiểm soát phiên bản đúng cách thì đó sẽ là "bộ não khác" của bạn.

Bạn đã rời đi đâu? Miễn là bạn đang cam kết mã thường xuyên, hãy nhìn vào thay đổi cuối cùng của bạn. Nó rất có thể sẽ chạy bộ một cái gì đó trong tâm trí của bạn. Nếu không, hãy nhìn vào một vài trong quá khứ, bắt đầu với các cam kết cũ nhất và phát lại.

Đối với những gì bạn phải làm , một hồ sơ tồn đọng sẽ phục vụ mục đích đó (hoặc danh sách việc cần làm hoặc bất cứ điều gì bạn muốn đặt tên cho nó. Về cơ bản các mục cho tương lai).

Tôi không phải là nhà phát triển phần mềm toàn thời gian. Tôi là một lập trình viên đột nhập vào các đêm và cuối tuần. Bởi vì điều này, khi công việc hoặc những thứ không lập trình khác được ưu tiên cao hơn, đôi khi tôi có thể đi hàng ngày và hàng tuần mà không cần lấy mã của mình chỉ trong nháy mắt. Những điều trên đã được chứng minh là khá hiệu quả.


10

Đây không phải là một câu trả lời hoàn chỉnh, đã có một số câu hỏi rất hay đề cập đến những điều quan trọng như cách sử dụng VCS và phần mềm quản lý dự án của bạn, nhưng thay vào đó là một phụ lục mà tôi không thấy ở bất kỳ điểm nào khác. thấy rất hữu ích và tôi hy vọng những người khác cũng có thể thấy hữu ích.

1. Không có nhiệm vụ quá sớm hoặc quá nhỏ để viết ra

Mọi người thường lập danh sách TODO cho những việc họ dự định làm trong tương lai , nhưng vì lập trình đòi hỏi sự tập trung và vì chúng tôi có thể bị gián đoạn bất cứ lúc nào , tôi thấy thật hữu ích khi viết ra ngay cả những gì tôi đang làm ngay bây giờ, hoặc những gì tôi sắp bắt đầu trong vài giây . Bạn có thể cảm thấy bạn đang ở trong vùng và bạn không thể nào quên giải pháp mà chỉ đánh bạn ở chỗ aha khoảnh khắc, nhưng khi đồng nghiệp của bạn giảm bởi cube của bạn hiển thị hình ảnh của ngón chân bị nhiễm của mình , và bạn cuối cùng chỉ có thể thoát khỏi anh ta bằng cách bắt đầu gặm nhấm cánh tay của chính bạn, bạn có thể ước mình đã viết ra một ghi chú nhanh, ngay cả khi chỉ trên một ghi chú Post-It ™.

Tất nhiên một số phương tiện bền bỉ khác có thể tốt hơn (tôi đặc biệt thích OmniF Focus ), nhưng vấn đề là ít nhất phải có nó ở đâu đó , ngay cả khi bạn sẽ hoàn thành sau 20 phút và sau đó ném Post-It ™ đi. Mặc dù bạn có thể phát hiện ra rằng thông tin đó trở nên hữu ích, để đặt bảng chấm công hoặc hóa đơn cho khách hàng hoặc khi sếp / khách hàng hỏi bạn những gì bạn đang làm việc và bạn không thể nhớ. Nếu bạn bỏ tất cả các ghi chú này vào hộp hoặc ngăn kéo hoặc thư mục, thì khi một sự gián đoạn lớn xảy ra với một dự án bị gián đoạn, thì bạn có thể lướt qua chúng và ghi nhớ rất nhiều điều bạn đã làm để đưa mã của mình đến điểm mà bạn tìm thấy nó khi bạn trở lại dự án.

2. Sử dụng bảng trắng tại bàn của bạn để ghi lại những ý tưởng hình ảnh lớn

Tôi có một bảng trắng 3 "x 4" bên cạnh bàn làm việc của mình, vì vậy khi tôi bắt đầu một dự án, tôi có thể động não tìm giải pháp cho tất cả các vấn đề tôi nhận thấy trong một dự án. Nó có thể là sơ đồ kiến ​​trúc, trường hợp sử dụng, danh sách rủi ro và trở ngại hoặc bất cứ điều gì có vẻ phù hợp với bạn.

Một số cách tiếp cận chính thức hơn yêu cầu bạn tạo sơ đồ và các trường hợp sử dụng và tiếp tục là "phân phối" ở một số định dạng giấy hoặc điện tử, nhưng tôi thấy rằng điều đó có thể tạo ra nhiều công việc phụ và chỉ trở thành một loạt các dự án phụ kết thúc đã ly hôn với mục đích thực tế của dự án chính, và chỉ là một phần của quy trình chính thức mà bạn phải làm nhưng điều đó không ai chú ý đến. Bảng trắng là thứ đơn giản nhất thực sự hoạt động, ít nhất là theo kinh nghiệm của tôi. Nó bền bỉ như bạn muốn (với một máy ảnh) và quan trọng nhất là cho phép bạn lấy ý tưởng của mình xuống ngay lập tức.

Tôi nghĩ tốt hơn với một cây bút trong tay, vì vậy, việc vứt bỏ suy nghĩ của tôi lên một bề mặt trắng tự nhiên đến với tôi, nhưng nếu bạn không thấy đó là trường hợp của bạn, đây là một số câu hỏi có thể giúp bạn quyết định điều gì có liên quan :

  • Nếu tôi là nhà phát triển chính, sắp đi tuần trăng mật trong 3 tháng trong khi các nhà phát triển khác hoàn thành dự án, tôi muốn đưa ra hướng đi chung nào cho họ? Những ý tưởng nào tôi muốn đảm bảo rằng họ biết, hoặc cách tiếp cận tôi muốn đảm bảo họ đã thực hiện? Những thư viện hoặc giải pháp hữu ích nào tôi muốn chắc chắn rằng họ đã biết?
  • Nếu dự án này là ý tưởng triệu đô của tôi mà tôi biết sẽ đảm bảo sự độc lập tài chính trong tương lai, nhưng tôi đã lên kế hoạch cho một cuộc phẫu thuật quan trọng sẽ làm mất khả năng của tôi trong 3 tháng, tôi muốn bản thân tương lai của mình sẽ ra sao, để đảm bảo hoàn thành thành công dự án?

(Khi tôi lần đầu tiên viết nguệch ngoạc những ý tưởng, tôi chỉ lo lắng về việc chúng có ý nghĩa với bản thân hiện tại của tôi. Một khi chúng bị suy giảm, tôi có thể nhìn nhận chúng một cách nghiêm túc hơn và thay đổi để đảm bảo chúng có ý nghĩa với bản thân tương lai của tôi hoặc cho người khác. về việc giao tiếp với người khác khi bạn viết chúng xuống ban đầu có thể dẫn đến sự ngăn chặn của các nhà văn, một tâm trí bị tắc nghẽn bởi các mục tiêu cạnh tranh. Hãy giải quyết nó trước, lo lắng về sự rõ ràng sau.)

Tôi khuyên bạn nên chi tiền để mua một bảng trắng đàng hoàng, ít nhất là 3 "x 4" và treo nó lên trong không gian nơi bạn thường làm việc. Có nhiều ưu điểm của bảng trắng vật lý so với bất kỳ hệ thống ảo nào.

  • Nó là lớn. Bằng cách chiếm nhiều không gian, nó làm cho sự hiện diện của nó cảm thấy, và các kế hoạch trên đó có cảm giác như chúng là một phần của không gian làm việc của bạn, giúp chỉ cho bạn đi đúng hướng mọi lúc.
  • Nó vẫn tồn tại một cách bền bỉ: bạn không khởi chạy một ứng dụng hoặc trang web nào đó để truy cập ứng dụng đó và bạn sẽ không có nguy cơ quên cách truy cập hoặc quên rằng nó ở đó.
  • Nó có thể truy cập ngay lập tức khi bạn có một ý tưởng mà bạn muốn nghĩ thông suốt.

Bạn sẽ mất rất nhiều lợi ích nếu bạn chỉ sử dụng bảng trắng trong phòng họp và sau đó chụp ảnh bằng điện thoại. Nếu bạn kiếm tiền bằng cách lập trình, nó cũng xứng đáng với chi phí của một bảng trắng đàng hoàng.

Nếu bạn có một dự án khác làm gián đoạn dự án đã lấp đầy bảng trắng của bạn, bạn có thể cần phải sử dụng ảnh chụp nhanh trên điện thoại của mình, nhưng ít nhất bạn sẽ có điều đó trong 3 tháng khi dự án "khẩn cấp" kết thúc và bạn phải trở về cái khác Nếu bạn muốn tạo lại nó trên bảng trắng của mình thì có lẽ chỉ mất 15 phút và bạn có thể thấy bạn có thể cải thiện nó rất nhiều trong quá trình, điều này khiến cho khoản đầu tư nhỏ về thời gian rất đáng giá.

3. Làm cho các bên liên quan nhận thức được chi phí của việc gián đoạn một dự án

Tôi thấy phép ẩn dụ của một chiếc máy bay hữu ích: bắt đầu và hoàn thành một dự án giống như lái máy bay. Nếu bạn bảo lãnh giữa chuyến bay, máy bay sẽ không chỉ ngồi đó trên không để chờ bạn quay trở lại và bạn cần một số cách để đi từ dự án / chuyến bay hiện tại sang chuyến bay tiếp theo. Trên thực tế nếu bạn đang ở giữa chuyến bay từ Phoenix đến Fargo và bạn được thông báo rằng bạn cần phải gián đoạn chuyến bay đó để đi máy bay khác từ Denver đến Detroit, bạn sẽ cần phải đáp máy bay đầu tiên ở Denver (mà may mắn là không xa đường bay của bạn, không phải lúc nào cũng có trường hợp bị gián đoạn thực sự) và ai đó phải tìm ra phải làm gì với hàng hóa và hành khách. Họ sẽ không chỉ ngồi và đợi mãi.

Điểm quan trọng của việc này đối với các dự án là việc chuyển đổi từ dự án này sang dự án khác phải chịu một khoản chi phí lớn về thời gian và để lại rất nhiều kết thúc thua lỗ phải xử lý.

Trong một dự án rõ ràng và chắc chắn có rất nhiều thứ xuất hiện trong đầu bạn khi bạn làm việc và không phải mọi suy nghĩ đều có thể được nối tiếp thành một phương tiện bằng văn bản, và không phải mọi iota của những suy nghĩ đó được nối tiếp sẽ tồn tại khi bị khử. Mặc dù chúng ta có thể nắm bắt một phần suy nghĩ của mình bằng văn bản, nhưng nó rất là một định dạng mất mát.

Vấn đề (như tôi thấy) là các nhà quản lý dự án và những người kinh doanh khác nghĩ về các dự án như một chuỗi các bước thường có thể được sắp xếp lại theo ý muốn (trừ khi có sự phụ thuộc rõ ràng vào biểu đồ Gantt của họ) và có thể dễ dàng phân phối giữa mọi người hoặc trì hoãn cho đến khi thuận tiện nhất cho việc kinh doanh.

Bất cứ ai đã thực hiện bất kỳ số lượng lập trình nào đều biết rằng các dự án phần mềm không thể được xử lý như các khối Lego được di chuyển xung quanh bất kỳ cách nào bạn muốn. Tôi thấy phép ẩn dụ của du lịch hàng không ít nhất mang lại cho các bên liên quan một cái gì đó cụ thể mà họ có thể nghĩ về điều đó rõ ràng không thể được coi là một loạt các bước khác nhau để được sắp xếp lại theo ý thích. Ít nhất làm cho nó dễ hiểu quan điểm của bạn rằng có một chi phí cho những gián đoạn như vậy. Tất nhiên đó vẫn là quyết định của họ, nhưng bạn muốn làm cho họ biết điều này trước khi họ làm gián đoạn một dự án để cung cấp cho bạn một dự án khác. Đừng hiếu chiến, nhưng hãy cung cấp thông tin hữu ích và quan điểm hữu ích của nhà phát triển, sẵn sàng làm bất cứ điều gì họ cần từ bạn, nhưng chỉ cung cấp thông tin mà họ có thể không biết nếu bạn không nói với họ.


Nói ngắn gọn:

  1. Viết ra tất cả những gì bạn sắp làm, ngay cả khi bạn không nghĩ rằng mình có thể cần nó viết ra. Ngay cả một cây bút chì ngắn cũng đánh bại một ký ức dài.
  2. Động não bức tranh lớn trên một bảng trắng vật lý mà bạn có quyền truy cập liên tục.
  3. Bạn có thể tránh các gián đoạn dự án nếu bạn khiến những người ra quyết định nhận thấy rằng có một chi phí cho những gián đoạn đó và ít nhất bạn sẽ đặt kỳ vọng để họ biết rằng dự án sẽ mất nhiều thời gian hơn khi bạn tiếp tục.

1
Các bên liên quan cho rằng họ đang trả tiền cho một nhà phát triển chuyên nghiệp đang bình luận và viết mã tài liệu để anh ta (sau đó) hoặc người khác (bất cứ lúc nào) có thể tiếp quản dự án. Tất nhiên giả định của họ là sai hầu hết thời gian.
JeffO

Và bạn nên bình luận và tài liệu! Tôi hy vọng bạn không nghĩ rằng tôi đã đề nghị khác. (Và nhân tiện, tôi đồng ý với nhận xét của bạn.)
iconoclast

2

Bạn có thể tra cứu lịch sử của dự án trong phần mềm kiểm soát phiên bản của bạn từ ba tháng trước. Đọc tin nhắn cam kết của bạn và khác biệt gần đây nhất để có ý tưởng về những gì bạn đang làm việc.


Tôi ngạc nhiên câu trả lời này không được nêu lên. Nhật ký kiểm soát phiên bản là một cách tuyệt vời để biết ai đó đã ở đâu vài tháng trước khi dự án tạm thời bị đình chỉ. Xóa thông điệp tường trình giúp rất nhiều. Khác biệt và danh sách các tập tin thay đổi là một cách bổ sung để có được hình ảnh về những gì đang diễn ra với dự án trước khi đình chỉ. Cuối cùng, có nhiều nhà phát triển sử dụng kiểm soát phiên bản so với số lượng nhà phát triển sử dụng hệ thống theo dõi lỗi (hoặc thậm chí là một danh sách việc cần làm đơn giản), điều này làm cho câu trả lời này có giá trị với nhiều người hơn so với câu trả lời được đánh giá cao của Scott Whitlock.
Arseni Mourzenko

2

Sử dụng hệ thống kiểm soát nguồn với các chiến lược hợp nhất và phân nhánh hợp lý, kết hợp với các hệ thống theo dõi vấn đề (như Redmine hoặc GitHub ) giúp bạn ngăn chặn các thay đổi bạn đã thực hiện, đưa ra hướng xử lý và ghi lại 'bối cảnh' bị thiếu của bạn như một phần tự nhiên của quy trình làm việc.

  1. Trước khi bạn bắt đầu thay đổi mã, hãy đảm bảo có "vấn đề" được ghi lại trong hệ thống theo dõi vấn đề của bạn. Điều đó bao gồm phần "tôi đang làm" còn thiếu trong công việc của bạn.
  2. Tạo một nhánh trong hệ thống kiểm soát nguồn của bạn và đảm bảo các thay đổi của bạn trong nhánh đó chỉ liên quan đến vấn đề được đề cập ở trên. Điều này sẽ giúp bạn cô lập các thay đổi và cung cấp cho bạn một lịch sử của sự thay đổi, trả lời câu hỏi "tôi đã rời đi đâu?" một khi bạn trở lại để làm việc với nó sau
  3. Khi bạn đã thực hiện xong thay đổi, hãy hợp nhất nó trở lại vào thân cây của bạn và đóng vấn đề.

1

Có rất nhiều câu trả lời dài. Đây là một đoạn ngắn về những gì giúp tôi nhiều nhất:

  • Mã sạch.
  • Mã sạch.
  • Mã sạch.
  • Kiểm soát phiên bản (khác biệt và cam kết ý kiến).
  • Ghi chú Post-It hoặc Todo-List hoặc Kanban-Board (xem ví dụ Trello và Evernote)

Tuy nhiên, Diffs, Commit comment, Post-It ghi chú, Todo-Lists hoặc Kanban-Board có thể bị hiểu sai theo thời gian vì thiếu ngữ cảnh. Vì vậy, đây là một điều quan trọng nhất:

MÃ SẠCH.


Theo cách chính xác thì mã sạch mã sạch sẽ giúp mã sạch giúp một người " Làm thế nào để tôi nhớ những gì tôi đã làm và tại sao trong một dự án ba tháng trở lại? " Và nhận lại bối cảnh bị bỏ lỡ? Kiến trúc sạch sẽ không kiến ​​trúc sạch kiến ​​trúc sạch sẽ giúp nhiều hơn? Người ta thường không đi sâu vào chi tiết đầu tiên. Đó là về việc có được bức tranh lớn trước khi kiểm tra các chi tiết. Thật không may, chú ở khắp nơi sẽ không giúp bạn điều đó, thật không may. Tuy nhiên, tôi hoàn toàn đồng ý với hai điểm đạn khác.
JensG

@JensG: Mã là kiến ​​trúc. Trong một chương trình được viết tốt, tôi có thể thấy đỉnh của kiến ​​trúc chương trình có chức năng main, đối với một chương trình có kích thước đáng kể sẽ khá trừu tượng. Sau đó tôi có thể lặn sâu hơn và xem kiến ​​trúc về cách chương trình tự dọn sạch, chẳng hạn. Hơn nữa, mã sạch có nghĩa là các hàm / biến / vv. có tên có ý nghĩa và đưa ra tuyên bố về ý nghĩa của chúng. Thay vào đó, nếu tôi viết Spaghetti / Write-Code, tôi sẽ thường thức dậy vào sáng / tháng / năm tiếp theo, nhìn vào mã của tôi và suy nghĩ duy nhất sẽ là wtf-did-i-do-there. Nó giống nhau khi ..
phresnel

... đọc hoặc viết một cuốn sách: Có phải nó vô nghĩa với chỉ số dễ đọc Flesch-Kincaid là 10, với các cụm từ lớn, nhiều cấu trúc từ phức tạp, cho phép người đọc tập trung vào cú pháp thay vì ngữ nghĩa hoặc dễ đọc với chỉ số khoảng 80, và do đó không theo cách của câu chuyện.
phresnel

Mặc dù tôi thấy (và không nghi ngờ theo bất kỳ cách nào) giá trị của mã sạch, tôi rất không đồng ý với mã là kiến ​​trúc. Mã có thể hoàn toàn sạch và có thể đọc được theo tất cả các tiêu chuẩn nhưng vẫn được viết theo cách mà bạn không có được bức tranh lớn. Tiếp theo, câu hỏi là " làm thế nào tôi nên nhớ những gì tôi đã làm " và " tôi không biết bắt đầu từ đâu ". Tôi không thể thấy bất kỳ giao điểm nào giữa trạng thái hiện tại của mã (sạch) và những gì OP đang tìm kiếm: điểm chính xác trong quy trình dẫn từ ý tưởng đến sản phẩm.
JensG

@JensG: Tôi nhận ra quan điểm của bạn. Tôi nghĩ rằng chúng tôi chỉ đang diễn giải "Tôi nhận ra rằng tôi không nhớ chính xác những gì tôi đã làm" khác nhau. Đối với tôi điều này nghe có vẻ giống như "Tôi nhận ra rằng tôi không nhớ những thuật toán và cấu trúc dữ liệu nào tôi đã mã hóa và làm thế nào tôi có thể mở rộng chúng", đối với bạn, nó giống như "Tôi nhận ra rằng tôi không nhớ những gì chính xác là tôi đã cố gắng thực hiện và mục tiêu của nó ". Ngôn ngữ con người mơ hồ. ...
phresnel

1

Làm thế nào tôi có thể ghi lại một dự án sao cho bất cứ khi nào tôi nhìn lại, tôi sẽ không mất nhiều hơn một vài phút để đi từ bất cứ nơi nào tôi rời đi.

Trước hết, điều này ngụ ý có một số mô tả và cấu trúc mã cấp cao trong dự án mà bạn có thể dễ dàng nắm bắt trong vài phút - trái ngược với hàng trăm dòng mã không có cấu trúc rõ ràng và không có nhận xét.

Có thực hành tốt nhất?

Sau đây là những thực tiễn tốt nhất tôi đã áp dụng trong suốt hơn 20 năm sự nghiệp trong các dự án rất nhỏ đến rất lớn và chúng đã phục vụ tôi và các nhóm của tôi rất tốt. Áp dụng theo thứ tự được liệt kê khi dự án của bạn phát triển:

  1. Sử dụng kiểm soát phiên bản, điều này cung cấp cho bạn một bản ghi theo dõi miễn phí về những gì đã xảy ra, khi nào và ai đã áp dụng các thay đổi. Nó cũng giúp bạn dễ dàng quay lại phiên bản cũ hơn bất cứ lúc nào.

  2. Mô đun hóa mã của bạn (tùy thuộc vào ngôn ngữ và môi trường lập trình, sử dụng các lớp, mô-đun, gói, thành phần).

  3. Tài liệu mã của bạn. Điều này bao gồm tài liệu tóm tắt ở đầu mỗi tệp (cái này làm gì? Tại sao? Làm thế nào để sử dụng nó?) Và nhận xét cụ thể ở cấp độ của hàm, thủ tục, lớp và phương thức (nó làm gì? Đối số và trả về giá trị / các loại? tác dụng phụ?).

  4. Thêm TODOFIXMEnhận xét trong khi bạn đang mã hóa. Điều này giúp ghi nhớ các vấn đề và những điều kỳ quặc chắc chắn sẽ nhập vào cơ sở mã của bạn và sau này bạn sẽ hỏi WTF?! . Ví dụ:

    //TODO shall actually compute X and return it
    ... some code that does not compute X yet (maybe returns a fixed value instead)
    
    //FIXME make this constant time instead of n^2 as it is now 
    ... some code that works but is not efficient yet
    
  5. Tạo thói quen vẽ sơ đồ thành cấu trúc tài liệu và hành vi phức tạp, chẳng hạn như chuỗi các cuộc gọi giữa các mô-đun / đối tượng / hệ thống, v.v ... Cá nhân tôi thích UMLet vì nó sử dụng nhanh, tạo đồ họa đẹp và quan trọng nhất là không theo cách của bạn . Nhưng tất nhiên bạn nên sử dụng bất kỳ công cụ vẽ nào mà bạn thấy thực hiện công việc. Hãy nhớ rằng mục đích của bất kỳ bản vẽ nào như vậy là để giao tiếp ngắn gọn, không chỉ định một hệ thống chi tiết trong vài phút (!!).

  6. Thêm bài kiểm tra đơn vị sớm. Kiểm thử đơn vị không chỉ tuyệt vời để kiểm tra hồi quy, mà còn là một dạng tài liệu sử dụng cho các mô-đun của bạn.

  7. Thêm tài liệu mã bên ngoài sớm. Bắt đầu với README mô tả các phụ thuộc cần thiết để chạy và phát triển dự án, cách cài đặt nó, cách chạy nó.

  8. Tạo thói quen tự động hóa các nhiệm vụ lặp đi lặp lại . Ví dụ, các chu trình biên dịch / xây dựng / kiểm tra nên được viết theo kịch bản theo một số dạng (ví dụ: trong sử dụng JavaScript grunt, trong Python fabric, trong Java Maven). Điều này sẽ giúp bạn tăng tốc nhanh chóng khi bạn quay lại.

  9. Khi dự án của bạn phát triển, hãy thêm tài liệu bằng cách tạo tài liệu mã nguồn (sử dụng một số dạng nhận xét kiểu JavaDoc và một công cụ thích hợp để tạo HTML hoặc PDF từ nó).

  10. Nếu dự án của bạn phát triển vượt ra ngoài một thành phần duy nhất và có một số triển khai phức tạp hơn cho nó, hãy chắc chắn để thêm tài liệu thiết kế và kiến ​​trúc . Một lần nữa lưu ý rằng mục đích của việc này là để truyền đạt cấu trúc và các phụ thuộc thay vì chi tiết phút.


0

Ngoài các đề xuất về theo dõi dự án, danh sách ToDo, Trello, v.v. , tuần tới hoặc tháng sau)

Ngồi xuống, làm 'Chạy thử' và chọn nơi bạn rời đi.


1
Điều này có hai nhược điểm. Đầu tiên, nếu bạn sử dụng tích hợp liên tục, có ý thức thực hiện một bài kiểm tra thất bại là điều không cần thiết. Thứ hai, nếu bạn ở trong một nhóm gồm nhiều người, những người khác có thể không đánh giá cao nếu bạn thực hiện bài kiểm tra thất bại.
Arseni Mourzenko

1
@MainMa tôi không nói cam kết. Chỉ địa phương.
Pete

Đề nghị của tôi cho bất kỳ nhà phát triển nào là cam kết khi anh ta không làm việc trên một dự án thậm chí trong vài ngày. Sự việc xảy ra. PC của bạn có thể bị đánh cắp hoặc bạn không thể khởi động nó vào ngày mai vì bộ điều khiển RAID bị lỗi. Bạn có thể rời khỏi dự án và nhà phát triển khác có thể thay thế bạn. Bạn có thể bị xe buýt đâm. Bạn có thể xóa dự án cục bộ vì nó chiếm quá nhiều vị trí hoặc do vi-rút giết chết hệ điều hành của bạn. Vì vậy, không, dựa vào một mã không được cam kết không phải là một lựa chọn.
Arseni Mourzenko

1
@MainMa sau đó cam kết và đẩy đến một chi nhánh có tên next-steps. Tôi không chắc những lo ngại của bạn về các chi tiết cụ thể của phương pháp kiểm soát sửa đổi phải làm gì với tiền đề cơ bản của một bài kiểm tra thất bại là một trợ giúp trong việc khởi động bộ não của bạn khi quay trở lại điều gì đó. Một lần nữa, điều này đã được đề xuất bên cạnh các phương pháp tiêu chuẩn như tồn đọng, danh sách việc cần làm, v.v.
Pete

2
@MainMa: kiểm soát phiên bản có thể có nhiều điểm chung với các bản sao lưu, nhưng đó không phải là mục đích chính của nó. Nếu bạn cần một hệ thống sao lưu và cách bạn sử dụng kiểm soát phiên bản sẽ ngăn không cho nó hoàn thành mục đích đó, thì hãy lấy Time Capsule hoặc một cái gì đó tương tự. Bạn không bao giờ bị buộc phải cam kết sớm chỉ để buộc VCS của bạn phục vụ như một bản sao lưu. Và bạn không bao giờ nên bị ngăn cản làm điều gì đó có lợi vì bạn đang tuân theo chính sách "cam kết mọi thứ ngay lập tức".
iconoclast

0

Ngoài các bình luận / danh sách việc cần làm / cam kết, điều quan trọng là phải thực tế.

Tùy thuộc vào quy mô, mức độ phức tạp và trạng thái bạn rời bỏ công việc của mình, việc bắt đầu lại dự án có thể mất một thời gian. Đối với một cơ sở mã đáng kể của nhiều thành phần tương tác, có thể mất nhiều ngày để đạt được tốc độ tối đa.

Kiên nhẫn cũ sẽ có ích.

Sau khi bị choáng ngợp sau khi trở lại một dự án, tôi thường chọn đơn vị nhiệm vụ đơn giản và nhỏ nhất và thực hiện nó. Nó giữ cho tôi khỏi bị lạc khi cố gắng nhớ rất nhiều thứ cùng một lúc và làm tăng sự tự tin một chút. Thường xuyên hơn không, tôi thấy mình tự động nhận các nhiệm vụ ngày càng lớn hơn trong vài giờ.


0

Tôi giữ một tạp chí hàng ngày về công việc tôi làm. Tôi đã làm gì hôm nay, hôm nay có gì khó khăn, bước tiếp theo là gì, hôm nay tôi có ý tưởng gì cho tương lai. Tôi cũng thêm một chút tường thuật về ngày hôm đó như thế nào: có một cuộc trò chuyện hay cuộc họp thú vị nào không? Đã làm một cái gì đó tức giận hoặc vui thích? Điều này giúp đưa mọi thứ vào quan điểm khi tôi đọc tạp chí của mình sau này.

Khi tôi trở lại một dự án sau một thời gian, tôi đã đọc một vài mục cuối cùng trong tạp chí để bắt kịp với dự án. Tất cả những chi tiết nhỏ hàng ngày này là vô cùng quan trọng để ghi nhớ quá trình phát triển. Chúng thực sự tạo ra nhiều sự khác biệt so với danh sách việc cần làm hoặc tài liệu dự án thông thường, vì chúng nhắc nhở bạn về những gì nó hoạt động trong dự án, và không chỉ là cách sử dụng sản phẩm.


điều này dường như không cung cấp bất cứ điều gì đáng kể qua các điểm được thực hiện và giải thích trong 11 câu trả lời trước
gnat

0

Đối với tôi, tôi thấy phương pháp đơn giản nhất để nối lại các dự án chỉ là giữ một bản ghi chép liên tục về công việc của bạn. Tôi thấy rằng 'OneNote' của Microsoft đặc biệt tốt để giữ và nhóm các trang ghi chú. Đặc biệt, thanh tìm kiếm giúp cực kỳ dễ dàng tìm thấy ghi chú của bạn trên một cái gì đó.

Dưới đây là một số điều tôi làm trong OneNote giúp tôi tiếp tục tiến độ trong các dự án:

  • Nhật ký hàng ngày / hàng tuần - Giữ nhật ký tiến độ hàng ngày hoặc hàng tuần để giúp bạn tìm ra tiến trình mà bạn đã thực hiện với một dự án.

  • Danh sách việc cần làm - Tôi có một danh sách việc cần làm chung, nhưng tôi cũng giữ một danh sách việc cần làm riêng cho các dự án tôi đang làm để tôi nhớ những việc tôi chưa làm cho dự án. Đôi khi tôi cũng để lại // TODO: các mục trong mã của mình.

  • Ghi chú dự án - Những điều tôi lưu ý bao gồm các liên kết đến các mục theo dõi vấn đề / dự án, đoạn mã, các vấn đề gặp phải, quyết định, kế hoạch và mô tả các giải pháp tiềm năng, danh sách thay đổi mã, liên kết đến thư mục kho lưu trữ mã, email cho dự án và liên kết đến tài liệu dự án.

Vì vậy, bất cứ khi nào tôi quay lại một dự án, tôi có thể mở các ghi chú của mình và gần như ngay lập tức tôi có thể thấy được bao nhiêu tiến bộ của dự án, còn lại bao nhiêu công việc phải làm và thậm chí nhìn thấy sự suy nghĩ của tôi.


-2

Đối với các dự án đơn giản, tôi làm điều này:

  1. Một tệp README đơn giản trong thư mục gốc (do đó, cũng sẽ kết thúc trong kiểm soát phiên bản) trong đó tôi lưu ý bất cứ điều gì bật lên trong khi phát triển: những việc cần làm, lỗi, cải tiến / ý tưởng. Đó là tập tin đầu tiên tôi sẽ đọc nếu tôi phải đặt dự án vào ổ ghi phía sau.
  2. Nhận xét TODO / FIXME / XXX
  3. Tôi cũng thường sử dụng ToDoList
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.