Trình quản lý đọc kiểm soát phiên bản cam kết

Người quản lý của chúng tôi đang theo dõi các cam kết Git trên tất cả các dự án của chúng tôi; thông thường, đây không phải là vấn đề và tôi thích thực tế là kiểm soát phiên bản cung cấp nhật ký của tất cả các công việc đang diễn ra, đặc biệt là cho việc kiểm tra và phân tích sau này (trong trường hợp có sự cố xảy ra).

Tuy nhiên, người quản lý đã đưa ra một vài nhận xét hỏi mọi người đang làm gì khi anh ta thấy một cam kết đọc "sửa lỗi kiểu" hoặc bất kỳ thông báo cam kết nào không tham chiếu số vé trong hệ thống quản lý tác vụ của chúng tôi.

Có một giải pháp xã hội hoặc kỹ thuật cho việc này?

Thông tin thêm: đây là một dự án bảo trì, do đó, có một loạt các nhiệm vụ "phải làm A rồi đến B rồi đến D và cuối cùng là phải thực hiện các nhiệm vụ X".

Thông tin thêm: thông báo cam kết cụ thể đã giơ cờ với người quản lý gần với "bao gồm một cách tốt hơn cho X, Y và Z", đó là một thông điệp tái cấu trúc hơn là một cách khắc phục đơn giản.

version-control management

— Peter Mortensen
nguồn

có thể trùng lặp Có phải tham chiếu đến lỗi / vấn đề trong thông báo cam kết được coi là thông lệ tốt không?

— gnat

Tôi đồng ý với người quản lý của bạn. Nhìn vào một bản ghi cam kết hai năm tuổi để tìm ra khi một cái gì đó thay đổi và thấy các cam kết như "sửa lỗi phong cách" là rất khó chịu. Nếu người quản lý của bạn không cho phép bạn thêm các tác vụ tái cấu trúc vào hệ thống quản lý tác vụ thì đó là một vấn đề hoàn toàn khác.

— Gort Robot

Tái cấu trúc thực sự thậm chí còn quan trọng hơn để nắm bắt hơn so với thay đổi phong cách. Ít nhất, thông điệp cam kết sẽ nói những gì đang được tái cấu trúc, nhưng thực sự tôi muốn nó được theo dõi để mọi người biết những gì đang được tái cấu trúc, QA biết những gì cần kiểm tra cẩn thận hơn, v.v.

— Gort the Robot

^ ^ những gì @StevenBurnap nói - đây là cách thực hành rất tốt. Chỉ có thể giới thiệu id vé thay vì gây ô nhiễm thông điệp cam kết với những lời giải thích dài dòng về những cải tiến / tái cấu trúc kiểu nào ở đó và tại sao những điều này được mong muốn làm cho nó đáng giá. Và còn nữa đó, nỗ lực, thông tin liên lạc với quản lý / QA vv vv theo dõi và không làm cho tôi bắt đầu của nó như thế nào là thuận tiện khi tích hợp theo dõi lỗi với công cụ rà soát VCS / code

— một loại muôi

Nó hoàn toàn phụ thuộc vào tình hình. Là người quản lý phản ứng với một thành viên của nhóm đang dành 50% thời gian của mình cho việc tái cấu trúc hoặc cho một cam kết duy nhất mà không cần tham khảo vé?

— nháy mắt

Câu trả lời:

Có một giải pháp xã hội hoặc kỹ thuật cho việc này?

Tôi cho rằng, nhưng đây không phải là một vấn đề .

Quản lý của bạn nên biết những gì các bạn đang làm. Họ nên đảm bảo rằng bạn không làm một loạt các công việc không mang lại giá trị hoặc tại sao công việc không bán vé được ưu tiên. Không có hại trong việc này. Trong một thế giới lý tưởng, nó sẽ mang lại lợi ích, bởi vì người quản lý của bạn có thể đặt kỳ vọng với doanh nghiệp để bạn có thể hoàn thành tất cả công việc đó mà không bị áp lực hay gián đoạn.

Nó chỉ trở thành một vấn đề nếu người quản lý của bạn nghĩ rằng chỉ nên thực hiện công việc bán vé và ngăn cản công việc dọn dẹp kỹ thuật là vé. Luôn có nợ kỹ thuật để dọn dẹp. Luôn luôn điều chỉnh vì bạn nên, mặc dù chúng không mang lại lợi ích kinh doanh rõ ràng, ngay lập tức.

— Telastyn
nguồn

Nếu sửa lỗi theo phong cách là một phần của vé bạn đang làm việc và nó có liên quan thì không có gì sai khi kiểm tra riêng với cùng một số vé bạn đang làm việc để nhận dạng tốt hơn.

Nếu bạn chỉ đang phát hiện ra những thay đổi cần phải thực hiện và chúng không liên quan đến vé mà bạn hiện đang làm thì tôi sẽ đề nghị tạo vé liên quan đến nợ công nghệ và đưa chúng vào hồ sơ tồn đọng của bạn để xử lý lại sau.

Trong quá trình lập kế hoạch của bạn, sau đó bạn có thể đi qua các vé liên quan đến nợ công nghệ và gắn chúng với các vé bảo trì thực tế mà bạn đang dự định làm việc theo cách này làm cho nó trở nên dễ hiểu hơn.

Điều này sẽ giúp bạn loại bỏ các bản sửa lỗi "không có chỗ đứng" này và giữ mọi thứ được gói gọn trong danh mục các vấn đề / vé cụ thể mà bạn đang làm việc.

— AvetisG
nguồn

Được rồi nhưng nếu đó là một sửa chữa tầm thường thì điều này là hoàn toàn ngu ngốc.

— Cuộc đua nhẹ nhàng với Monica

Nợ công nghệ 99,99% thời gian không phải là thay đổi nhỏ. Đó là lý do tại sao tôi nói hãy tạo một vé thay vì lao vào một thứ khác là một công tắc bối cảnh lớn. Nếu đó là một cái gì đó tầm thường và không liên quan đến những gì bạn đang làm thì bạn vẫn có thể kiểm tra nó dưới tên vé bạn đang làm việc với một nhận xét riêng. Hoặc tốt hơn là nghĩ về một ký hiệu như QFIX để nhận dạng dễ dàng sau này, vì vậy bạn không có những thay đổi tầm thường ngẫu nhiên trôi nổi xung quanh mà không có tổ chức.

— AvetisG

Điều gì xảy ra nếu người quản lý cũng đang xem JIRA để lấy vé mới và sau đó đặt câu hỏi cho những người đó? anh ta không đặt câu hỏi khi vé được chuyển từ nước rút trong tương lai sang hiện tại nhưng ngay khi ai đó tạo ra một vé mới liên quan đến nợ kỹ thuật, nó đã bị nghi ngờ.

— Rudolf Olah

Ký hiệu QFIX là một thứ mà bạn sẽ cần nói với tư cách là một nhóm trước khi thực hiện. Đó là tất cả về giao tiếp, bạn không chỉ cần nhảy vào và viết các quy tắc của riêng bạn. Vì vậy, trước tiên hãy nói về nhóm với tư cách là một nhóm, và sau đó nếu họ không đồng ý thì hãy đi với giải pháp khác là kiểm tra nó cùng với vé chính của bạn mà bạn đang làm việc với một nhận xét riêng. Mặc dù vậy, xin lưu ý rằng, một lần nữa, chỉ khi thay đổi có ý nghĩa tầm thường thì nó không chứa bất kỳ thay đổi logic hoặc cấu trúc lại lớn nào. Vô hại, vô hại, thay đổi tầm thường.

— AvetisG

@omouse Cũng có thể là người quản lý của bạn đang quản lý vi mô hoặc anh ta không xử lý đúng nợ kỹ thuật. Tuy nhiên, người quản lý cuối cùng chịu trách nhiệm về toàn bộ dự án và chịu trách nhiệm về chính mã đó, và lý tưởng nhất là ở một mức độ nào đó nhận thức được mọi công việc đang diễn ra và tại sao.

— Gort Robot

Điều này cũng làm tôi khó chịu (không có ý định chơi chữ :).

Hầu hết các đăng ký hữu ích đều chứa các nhận xét là duy nhất và cụ thể đối với không chỉ những gì đã thay đổi, mà tại sao. Tôi đôi khi kết thúc việc đưa ý kiến đoạn văn.

Thỉnh thoảng tôi gặp phải tình huống yêu cầu UI bị trả lại qua lại sau khi quá trình phát triển bắt đầu, đòi hỏi tôi phải trả lại mã về cơ bản (vâng, đôi khi thế giới thực bị hút). Trong những trường hợp này, tôi thấy điều quan trọng hơn nữa là các bình luận của tôi cung cấp sự rõ ràng về lý do tại sao độ nảy và quan trọng hơn là tại sao mã kết thúc ở nơi nó làm. Sau đó, khi quản lý quay lại sau khi nói chuyện với khách hàng và muốn biết lý do tại sao, tôi có thể chỉ cho họ mà không cần phải nhớ toàn bộ trải nghiệm lần lượt.

— Táo quân
nguồn