Thực hành tốt nhất khi chuyển đổi giữa các dự án / quay lại dự án thường xuyên là gì?

Bản chất công việc của tôi là tôi phải chuyển đổi qua lại giữa các dự án cứ sau vài tuần. Tôi thấy rằng một trong những trở ngại lớn nhất đối với năng suất của tôi là thời gian tăng tốc để lấy lại tất cả các đoạn mã có liên quan "trở lại trong đầu tôi" sau khi không thấy nó trong một khoảng thời gian. Điều này xảy ra ở một mức độ nhỏ hơn và lớn hơn đối với các lần nghỉ nhanh hơn / nghỉ dài hơn.

Rõ ràng, thiết kế tốt, tài liệu, nhận xét và cấu trúc vật lý đều giúp ích cho việc này (không đề cập đến việc chuyển đổi giữa các dự án không thường xuyên nhất có thể). Nhưng tôi tự hỏi nếu có những thực hành / công cụ mà tôi có thể bỏ lỡ. Thực hành cụ thể của bạn để cải thiện điều này là gì?

Tôi thường xuyên chuyển đổi giữa các dự án khác nhau (cả kỹ thuật và phi kỹ thuật). Tổ chức hoặc "dễ dàng lấy" đã là chìa khóa cho tôi. Trước khi rời khỏi một dự án, tôi đảm bảo rằng tôi sắp xếp mọi thứ để tôi dễ dàng lấy lại bối cảnh trong đầu. Đối với tôi, điều này có nghĩa là đặt tất cả những thứ có liên quan (dấu trang, tệp, tài liệu, email, v.v.) hoặc liên kết đến chúng trong một thư mục để tôi không phải tìm kiếm nguồn thông tin.

Một điều mà tôi đã bắt đầu làm gần đây là sử dụng một máy ảo cho mỗi dự án lớn. Khi tôi cần chuyển sang dự án khác, tôi giữ tất cả các ứng dụng có liên quan mở và sau đó tạm dừng máy ảo. Vì vậy, khi tôi cần chuyển trở lại dự án, tôi có thể khởi động VM và nó sẽ hiển thị cho tôi tất cả thông tin đã có trên màn hình.

Một vài điều có ích:

• Tối ưu hóa tối đa mã của bạn để dễ đọc và rõ ràng.
• Để lại gợi ý và gợi ý cho bạn trong mã, dưới dạng bình luận.
• Thực hiện theo KISS và DRY.
• Hãy nhất quán, trong từng dự án và trên các dự án.
• Hãy tôn giáo về tái cấu trúc.
• Tài liệu mọi thứ; coi bản thân tương lai của bạn là một người khác mà không có cách nào hỏi bản thân hiện tại của bạn bất kỳ câu hỏi nào.
• Tránh mã "thông minh" phá vỡ IDE / trình soạn thảo của bạn.
• Sử dụng kiểm soát nguồn, với các thông báo cam kết cho bạn biết chính xác nơi bạn để lại mọi thứ; các phiên bản thẻ mà bạn cho là có thể chuyển được và nhắm đến các khoảng thời gian ngắn giữa các phiên bản có thể chuyển được.
• Nếu bạn có thể chọn ngôn ngữ lập trình, hãy chọn ngôn ngữ có thể giúp bạn thực hiện đúng.
• Đây là một vấn đề của sở thích cá nhân, nhưng nó hoạt động tốt với tôi, vì vậy tôi sẽ khuyên bạn nên làm điều đó: Giữ một tài liệu văn bản đơn giản, ngắn gọn có chứa các nhiệm vụ sắp tới và cập nhật mỗi khi bạn hoàn thành một nhiệm vụ. Đồng thời sử dụng tài liệu này cho các ghi chú cấp thiết kế không phù hợp với nhận xét mã. Về cơ bản, tài liệu văn bản này phải chứa toàn bộ thiết kế của bạn, chỉ ở dạng cô đọng (đủ thông tin để bạn hiểu, nhưng đủ ngắn để đưa bạn trở lại yên trong vòng 10 phút). Trình theo dõi lỗi cũng hoạt động, nhưng tài liệu văn bản có một số ưu điểm: nó buộc bạn phải cắt lông tơ và tập trung vào các nội dung có liên quan, và nó có thể được cam kết kiểm soát nguồn cùng với mã thực, có nghĩa là nó được gắn tự nhiên vào Phiên bản SCM.

Tôi làm một cái gì đó tương tự như những gì RonE làm.

Có một dự án dễ đọc, với một thiết kế tốt sẽ giúp ích, nhưng trước khi rời khỏi một dự án, hãy đảm bảo tất cả bối cảnh và thông tin bạn có trong đầu nó được viết hoặc lưu trữ ở đâu đó. Chẳng hạn, ghi chú về các chức năng thư viện của bên thứ ba mà bạn đang sử dụng nếu đó là một chức năng mới mà bạn chưa từng sử dụng trước đây. Tôi luôn viết ghi chú về những điều tôi học hoặc nghĩ, bằng lời nói của riêng tôi.

Ngoài ra, điều tôi thấy quan trọng nhất để viết trong một tệp là nếu bạn viết bình luận TODO trong mã của mình, sao chép cái cuối cùng bạn đang làm việc và dán nó vào một tệp văn bản mới và gọi nó là TODO. Viết trong đó thông tin ngữ cảnh về nơi thẻ TODO thuộc về và viết những gì bạn có trong đầu hoặc những gì bạn nghĩ rằng bạn muốn biết về nhiệm vụ đó.

Hai điều quan trọng đối với tôi: tính nhất quán và đặc điểm kỹ thuật.

Tính nhất quán là chìa khóa cho mã. Tôi không cần phải nhớ mọi thứ ở đâu và mọi thứ tương tác như thế nào nếu tôi có thể ngoại suy những gì tôi đã làm. Nếu đó là một dự án với những người khác trở nên rắc rối hơn, nhưng các tiêu chuẩn mã giúp đỡ khá nhiều. Biết những gì là một cái gì đó bằng cách nhìn vào nó và đưa ra một vài giả định an toàn làm giảm thời gian lên máy bay một chút.

Đặc điểm kỹ thuật là hữu ích hơn cho thiết kế. Ít nhất là đối với tôi, tôi thấy rằng tôi có xu hướng quên đi một số sắc thái của thiết kế sản phẩm sau khi nghỉ ngơi. Hoặc khi tôi trở lại, chính vì ý tưởng tuyệt vời này đã kịp thời đưa creep vào dự án. Nếu dự án của bạn không có yêu cầu tốt (trong thông số thác nước hoặc tồn đọng sản phẩm), về cơ bản bạn phải phát minh lại những điều này mỗi khi bạn quay lại dự án. Hầu như tất cả các thực tiễn tốt nhất để phát triển phần mềm vẫn là các thực tiễn tốt nhất khi nó là một dự án cá nhân; đừng bỏ qua chúng.

IMO chính là một API thông minh cho mọi dự án của bạn. Đồng thời tải mã lên kho lưu trữ như GIT hoặc các mã khác cho phép bạn "du hành thời gian" thông qua các cam kết về mã.

Vì tôi hỗ trợ phát triển và sản xuất cho nhiều khách hàng, tôi chuyển đổi dự án nhiều lần mỗi ngày. Hai điều giúp tôi nhiều nhất là không bao giờ rời khỏi một dự án cho đến khi tôi đã lưu tất cả mọi thứ (Và cam kết với một chi nhánh địa phương nếu nó không ở trạng thái tôi muốn đưa nó trở lại nhánh chính của kiểm soát nguồn của mình) và tôi đặt một điểm dừng tại nơi tôi rời đi. Chỉ cần có thể nhanh chóng tìm ra dòng chính xác nơi tôi rời đi, giúp tôi quay trở lại trong một dự án nhanh hơn nhiều. Tôi cũng có xu hướng tạo một danh sách việc cần làm cho từng dự án lớn và kiểm tra mọi thứ khi chúng được thực hiện, vì vậy một đánh giá nhanh về điều đó cho tôi biết tôi đang ở đâu và nhắc nhở tôi về quá trình suy nghĩ của tôi về dự án. Nói chung, tôi cũng viết một ghi chú nhanh cho bản thân về những điều mà tôi đã suy nghĩ nhưng chưa thực hiện nếu tôi cần (những thứ như: