Quy trình làm việc, chỉnh sửa những thứ không có trong nhiệm vụ hiện tại của bạn


12

Thông thường khi tôi lập trình, tôi có một nhiệm vụ rõ ràng trước mắt, nhưng tìm thấy những điều phiền toái mà tôi muốn dọn dẹp khi tôi tiếp tục.

Ở đây tôi thấy ba tùy chọn:

  • Thực hiện sau (có thể quên / phải dành thời gian thêm vé)
  • Thực hiện ngay bây giờ và cam kết cùng với công việc hiện tại của tôi (không rõ ràng)
  • Thực hiện ngay bây giờ và cam kết riêng (phải tìm ra nó, có thể mắc lỗi và vô tình chọn tùy chọn # 2)

Điều này có lẽ khá cơ bản, nhưng một số cách để phá vỡ điều này bằng cách sử dụng svn / git / khác là gì?



Tôi thường đi với tùy chọn thứ 2. Nhưng nếu tôi đã thực hiện nhiều lần tái cấu trúc, tôi sẽ thực hiện hai cam kết riêng biệt. 1 cho nhiệm vụ cụ thể của tôi và một nhiệm vụ khác chỉ được gắn nhãn là "Tái cấu trúc" mà tôi rebasethay vì merge.
Alternatex

Câu trả lời:


7

Cá nhân, tôi nghĩ rằng nó phụ thuộc :-).

  • Đối với các sửa chữa nhỏ , tùy chọn ba (bây giờ, trong một cam kết riêng biệt) là tốt nhất, bởi vì chi phí thực hiện sau này không đáng. Trong trường hợp đó, bạn chỉ cần tạo một cam kết riêng. Làm thế nào để làm điều đó phụ thuộc vào VCS bạn sử dụng và là một câu hỏi riêng biệt :-).

  • Nếu đó là một sửa chữa lớn hơn , bạn tạo một vé. Mặt khác, bạn có nguy cơ liên tục bị trật bánh khỏi nhiệm vụ chính của mình ("Ồ, nhìn này, một cơ hội khác để tái cấu trúc, ồ, có cái khác, và ở đó, và ở đó ...").


Đối với viên đạn đầu tiên của bạn, các bản sửa lỗi nhỏ, cam kết chỉnh sửa ngay lập tức có vẻ là tùy chọn tốt nhất. Tôi không biết tại sao tôi không nghĩ về điều đó, những thói quen xấu tôi đoán. Tôi có xu hướng tìm hiểu một chút về phần mã hóa của lập trình, trái ngược với phần quản lý mã :)
Nattfrosten

@Nattfrosten: Vâng, điều đó là tự nhiên, và không tệ - sau tất cả, trọng tâm thường là về mã hóa. Quản lý mã ist chỉ để làm cho mã hóa dễ dàng hơn.
sleske

5

Xem xét điều này. Khi bạn "tìm những thứ gây phiền nhiễu (...) để dọn dẹp" và bạn đưa ra quyết định điều hành, bạn sẽ loại bỏ phần còn lại của nhóm ra khỏi cuộc thảo luận và quyết định ưu tiên. Bạn đang để chương trình nghị sự của mình thổi phồng mọi người khác vì mối quan hệ đặc quyền của bạn với mã. Tôi không nghĩ đó là tốt đẹp. Từ kinh nghiệm, nó cũng dẫn đến sự phẫn nộ của nhóm / cổ đông.

Thay vào đó, hãy tạo một vấn đề / nhiệm vụ để dọn dẹp / tái cấu trúc. Trong khi bạn còn mới mẻ, hãy liệt kê những lý do quan trọng: ước tính tăng tính ổn định, dễ bảo trì, đại loại như vậy. Có thể bao gồm ước tính nỗ lực tùy thuộc vào cách nhóm của bạn làm việc. Sau đó, trong cuộc họp lựa chọn / phân công / ưu tiên tiếp theo của bạn, hãy trình bày nhiệm vụ tái cấu trúc của bạn và đặt nó vào các nhiệm vụ khác. Là một nhóm, quyết định khi nào cần hoàn thành.

Xin đừng nghĩ rằng tôi đang nói với bạn về ý nghĩa tốt trong tên của các nguyên tắc. Sử dụng đầu của bạn. Nếu có cái gì đó xấu trong chức năng bạn đang chỉnh sửa, thì đó không phải là một nhiệm vụ tái cấu trúc mới. Khắc phục sự cố và kiểm tra mọi thứ. Nếu đổi tên tài sản bạn đang làm việc thành thứ gì đó hợp lý hơn sẽ ảnh hưởng đến một vài tệp nguồn bổ sung, đó không phải là một nhiệm vụ tái cấu trúc mới. Khắc phục và kiểm tra mọi thứ. Mặt khác, nếu bạn không thích cách một nhà phát triển khác (Mitch, tôi ghét anh chàng đó) đã làm gì đó trong một chức năng mà bạn không chỉnh sửa cho biết chức năng có vẻ hoạt động tốt, để nó một mình bây giờ Tạo một nhiệm vụ tái cấu trúc và trình bày trường hợp của bạn cho nhóm của bạn.

Nếu việc tái cấu trúc luôn bị nhóm của bạn bỏ phiếu ủng hộ các tính năng mới, hãy bắt đầu tìm kiếm một công việc khác. Tìm việc làm dễ dàng hơn khi bạn đã có một công việc.


1
Cảm ơn rất nhiều vì câu trả lời này, cho đến nay tôi hầu như đã tham gia vào các dự án solo, vì vậy đó là nơi mà sự thuyết phục của tôi đến từ đó. Tôi sẽ phải thay đổi rất nhiều thói quen để phù hợp hơn với đội sau này, và loại điều này chính là thứ tôi cần.
Nattfrosten

Cùng một kết luận, nhưng thường các ông chủ quyết định tìm kiếm các tính năng mới và không tái cấu trúc: - |
Đánh dấu Hurd
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.