Tất cả sự phát triển, bao gồm cả tái cấu trúc công việc, có nên đi kèm với một vấn đề theo dõi không?

Cuộc tranh luận: Tất cả sự phát triển, bao gồm cả tái cấu trúc công việc, có nên đi kèm với một vấn đề theo dõi không? (trong trường hợp của chúng tôi, Jira)

Điểm chung: Mục tiêu chính của chúng tôi là chất lượng. Một sản phẩm làm việc, mỗi bản phát hành, quan trọng hơn bất cứ thứ gì khác. Codebase của chúng tôi đã cũ và các bài kiểm tra tự động còn thiếu; chúng tôi đang làm việc này nhưng đó là một dự án dài hạn, chúng tôi cần các quy trình tạm thời.

Vị trí 1: Công việc tái cấu trúc phải được theo dõi trong Jira. Nếu nó rõ ràng không liên quan đến thay đổi bạn đang thực hiện thì bạn phải nêu ra một vấn đề khác. Nếu bạn không thì công việc bỏ qua việc xem xét và thử nghiệm và có rủi ro cho mục tiêu chính của chúng tôi. Lập luận đã được đưa ra rằng việc tuân thủ PCI (mục tiêu trong tương lai gần của doanh nghiệp) đòi hỏi mức độ theo dõi này; Tôi không ở vị trí để nói điều đó đúng hay sai với bất kỳ mức độ chắc chắn nào.

Vị trí 2: Chất lượng mã là rất quan trọng. Càng tốt hơn (đến một điểm; một điểm chúng ta không ở gần), chúng ta càng có nhiều khả năng tiếp tục phát hành một sản phẩm hoạt động. Bất cứ điều gì đặt ra một rào cản, dù nhỏ đến đâu, trong cách tái cấu trúc đều là rủi ro cho mục tiêu chính của chúng tôi. Thông thường, IDE thực hiện công việc cho bạn, vì vậy dù sao nó cũng không bị lỗi.

Các trường hợp sau đây đã được thực hiện:

Nó có đáp ứng cả hai vị trí nếu nhà phát triển viết "Refactor" và các số sửa đổi có liên quan trên thẻ không? Thành thật mà nói, điều này cảm thấy như nó sẽ làm cho tất cả mọi người đều không vui. Nó vẫn đặt một mức độ kháng cự khi thực hiện tái cấu trúc, nhưng không cung cấp đủ theo dõi.

Điều gì về việc có các vấn đề Jira bao gồm tất cả bao gồm công việc tái cấu trúc cho một lần lặp? Vâng, điều này loại bỏ lớp kháng cự của nhà phát triển, nhưng tôi sợ nó cũng loại bỏ các lợi ích theo dõi khi gặp sự cố Jira. Làm thế nào để QA có được một ý tưởng rõ ràng những gì để kiểm tra? Đây dường như là một giải pháp chính trị, giữ cho mọi người bình tĩnh bằng cách thêm vào một quá trình nhẹ nhàng nhưng cuối cùng là vô nghĩa.

Dường như với tôi rằng, cho rằng cả hai bên của cuộc tranh luận cuối cùng đều muốn cùng một điều, nên có một giải pháp khiến tất cả mọi người thực sự hạnh phúc. Chúng ta không thể là người đầu tiên đặt câu hỏi này, vậy những người khác có kinh nghiệm gì trong những tình huống tương tự?

Có lẽ tôi đang thiếu một cái gì đó ở đây, nhưng làm thế nào để tạo một vé cho công việc bạn đang làm mà không nằm trong phạm vi của các vé khác của bạn một "lớp kháng chiến"?

Gần đây bạn đã thực hiện bằng cách sử dụng một hệ thống theo dõi vé? Nếu vậy, hãy ngồi xuống và đưa ra các quy tắc của bạn để sử dụng nó và cho nhóm biết rằng họ sẽ tuân theo các quy tắc này. Nếu điều này bao gồm việc tạo vé tái cấu trúc cho công việc này, thì hãy là nó. Bạn không thể đưa ra ngoại lệ sớm hoặc nó có thể làm hỏng toàn bộ quá trình mà nhóm của bạn đang cố gắng thiết lập.

Nếu bạn đã sử dụng một hệ thống theo dõi vé trong một thời gian, thì tôi thực sự không hiểu tại sao đây sẽ là một 'lớp kháng chiến'. Nhóm của bạn đã được sử dụng để mở Jira và xem vé của họ và nên thoải mái đặt vé.

Nếu bạn muốn giữ tất cả các nỗ lực tái cấu trúc ở một nơi, hãy tạo một vé chính cho việc này và để nhóm của bạn thực hiện các nhiệm vụ theo nó cho công việc họ đang làm. Sau đó, phải mất 5 giây để một nhà phát triển thực hiện một nhiệm vụ mới cho việc này và họ có thể đăng nhập thời gian của họ vào nhiệm vụ đó.

Người quản lý dự án, trưởng nhóm và nhà phát triển cần biết bao nhiêu thời gian dành cho nỗ lực tái cấu trúc. Bạn không muốn nó trở thành một lỗ đen thời gian. Có vé giúp các nhà phát triển có trách nhiệm với công việc của họ trong khi cung cấp cho các nhà quản lý và dẫn đến một nơi để theo dõi xem họ sẽ nỗ lực bao nhiêu giờ.

Lý tưởng là có.

Bất kỳ thay đổi nào bạn thực hiện đối với cơ sở mã phải có lý do đằng sau nó. Đây có thể là một yêu cầu của khách hàng - phổ biến nhất / có khả năng hoặc một mục được nêu ra trong nội bộ - chẳng hạn như trong ví dụ tái cấu trúc của bạn.

Điều này có nghĩa là cũng như theo dõi khi thay đổi được thực hiện, bạn có thể liên kết các thay đổi trở lại với điều gì đó giải thích tại sao thay đổi được thực hiện. Tại sao điều này không thể chỉ là những bình luận thay đổi? Có một số lý do tại sao điều này có thể không phù hợp.

• Không phải lúc nào cũng có ánh xạ 1: 1 giữa các mục công việc và bộ thay đổi - bạn có thể cần một vài bộ chỉnh sửa để hoàn thành một mục.
• Các bình luận thay đổi thường không hiển thị cho những người không phải là nhà phát triển hoặc bạn có thể cần phải đính kèm tài liệu khác vào mục công việc.

Tái cấu trúc mã, trong khi rất mong muốn cải thiện chất lượng, cũng là một rủi ro cố hữu. Điều này đặc biệt đúng khi xử lý mã "nền tảng" trong đó một lỗi sẽ làm cho toàn bộ hệ thống sụp đổ và giải quyết một "vấn đề" duy nhất sẽ có tác dụng phụ (có thể không lường trước được) trong toàn bộ ứng dụng.

Bất kể loại mã nào có liên quan, khi tái cấu trúc không giới hạn mã cho một vấn đề cụ thể (vé), QA nên tham gia và nhận thức được các phần của cơ sở mã của bạn bị ảnh hưởng. Họ sẽ phải làm một bài kiểm tra hồi quy đầy đủ trên các bộ phận đó để đảm bảo rằng không có gì bị trượt. Và họ sẽ phải làm như vậy thậm chí, có lẽ đặc biệt, nếu bạn có một bộ đầy đủ các bài kiểm tra đơn vị tại chỗ khiến bạn cảm thấy tự tin về việc thực hiện tái cấu trúc. Bài kiểm tra đơn vị kiểm tra rất nhiều, nhưng họ cũng bỏ lỡ rất nhiều.

Vì vậy, nếu chất lượng mã là quan trọng, vâng, nên có càng ít rào cản càng tốt để cải thiện mã. Nhưng tôi không thấy cách tạo ra một vé cho điều này là một rào cản. Nó chỉ đơn giản là đảm bảo rằng QA có cơ hội (im) chứng minh chất lượng của mã và phải là một cái gì đó mong muốn, không phải là thứ được xem là vật cản.

Tôi nghĩ rằng nếu bạn không thể mô tả việc tái cấu trúc cụ thể hơn là "tái cấu trúc", thì bạn đã làm sai. Tái cấu trúc nên có một mục đích và phạm vi xác định. Theo dõi các nhiệm vụ tái cấu trúc một cách riêng biệt trong JIRA không chỉ giúp việc kiểm tra, đánh giá và kiểm tra dễ dàng hơn mà còn buộc các nhà tái cấu trúc tập trung tâm trí của họ vào các mục tiêu cụ thể (ví dụ: "loại bỏ sự phụ thuộc vòng tròn giữa các mô-đun X và Y") tái cấu trúc tốt hơn.

Mặt khác, nếu việc tái cấu trúc thực sự đơn giản, cục bộ và chỉ là sản phẩm phụ của việc thực hiện một nhiệm vụ khác nhau, tôi sẽ không bận tâm theo dõi nó dưới một vé riêng và chỉ ghi lại trong vé taks ban đầu, nếu có thể có tác động đến công việc của người khác.

Có, lý tưởng là mọi thay đổi bạn thực hiện trong mã phải được liên kết với một mục JIRA và do đó có thể theo dõi. Như những người khác đã lưu ý, bạn sẽ có thể xác định lý do tại sao một thay đổi nhất định được thực hiện và những thay đổi khác có liên quan.

Sẽ ổn khi có tái cấu trúc dài hạn Epics trong một dự án cũ, chúng tôi cũng có chúng trong chúng tôi. Tuy nhiên, bạn nên cố gắng tập trung những điều này vào một số khu vực cụ thể của mã, với một mục đích cụ thể, nếu không thì thực sự khó kiểm soát nó. Ví dụ: "các mô đun tái cấu trúc Foo và Bar để loại bỏ các phụ thuộc theo chu kỳ", "phân cấp lớp tái cấu trúc A để loại bỏ các bản sao và làm sạch hệ thống phân cấp thừa kế".

Khi làm việc với mã kế thừa, có nguồn lực hạn chế, người ta phải ưu tiên các cách có thể để giảm nợ kỹ thuật, để đạt được lợi tức đầu tư tốt nhất có thể. Vì vậy, phân tích tái cấu trúc có thể, tầm quan trọng, rủi ro, chi phí và lợi ích của họ nên được thực hiện trước khi bắt đầu công việc. Ngoài ra, theo dõi tiến trình tái cấu trúc quy mô lớn hơn và biết khi nào nó kết thúc là rất quan trọng. So với các nhiệm vụ cần thiết này, IMHO nỗ lực thực tế trong việc quản lý một mục JIRA là tối thiểu.

Lập luận đã được đưa ra rằng việc tuân thủ PCI (mục tiêu trong tương lai gần của doanh nghiệp) đòi hỏi mức độ theo dõi này

Nếu bạn muốn nói điều này , tôi có thể hiểu tại sao quản lý lo ngại về những thay đổi không được kiểm soát trong cơ sở mã, tuy nhiên theo dõi thay đổi chỉ là một phần rất nhỏ của giải pháp. Bạn cần kiểm tra hệ thống kỹ lưỡng và có thể đánh giá mã để đảm bảo rằng không có số thẻ tín dụng nào bị rò rỉ từ hệ thống thông qua các tệp nhật ký, v.v. Tái cấu trúc không phải thay đổi hành vi của mã hiện tại và bạn phải có các thử nghiệm đơn vị để chứng minh điều này dù sao đi nữa (đừng cố dựa vào niềm tin rằng các công cụ tái cấu trúc tự động không thể phá mã - bạn PHẢI có các bài kiểm tra đơn vị để tránh những bất ngờ khó chịu).

Trong một thế giới lý tưởng, câu trả lời của Chris là đúng. Bất cứ khi nào bạn thực hiện thay đổi mã hoặc bất kỳ tạo phẩm nào được liên kết với một dự án phần mềm, cần có một bản ghi của điều này. Nó nên được đệ trình, phê duyệt, giao cho đúng bên, ước tính nỗ lực, công việc được thực hiện, tổng thời gian ghi lại, và một mô tả ngắn về sự thay đổi được ghi lại.

Tuy nhiên, điều này không phải lúc nào cũng khả thi. Ví dụ: IDE của tôi được cấu hình để định dạng lại tệp mã dựa trên nguyên tắc mã của tổ chức. Nếu tôi mở một tệp và thấy rằng nó không khớp, thì đó là chuyện nhỏ để sửa - CTRL + SHIFT + F trên tất cả các định dạng tệp. Có thể là CTRL + SHIFT + O để sửa lỗi nhập. Tôi làm điều này ngay trước hoặc ngay sau khi sửa lỗi mà tôi được chỉ định.

Trong trường hợp đó, bạn luôn muốn ghi lại sự thật rằng bạn đã làm điều đó và mất bao lâu, nhưng không thực hiện thay đổi bây giờ có thể tồi tệ hơn là trải qua quá trình chính thức chuyển nhượng và thực hiện thay đổi. Trong một số trường hợp, việc cầu xin tha thứ sẽ dễ dàng hơn là xin phép. Tùy thuộc vào bạn, với tư cách là một kỹ sư, để biện minh chính xác nơi đường đó cần được vẽ.

Nhìn chung, việc tái cấu trúc sẽ diễn ra như một phần bình thường trong quy trình làm việc của bạn. Để sửa chữa lỗi Một , bạn cần phải kiểm tra rằng chút của phương pháp này, và do đó bạn phải giải nén nó như phương pháp B . Trong khi bạn đang làm điều đó, bạn nhận thấy trường C được đặt tên rất tệ và vì vậy bạn đổi tên nó.

Để cách suy nghĩ của tôi, những bình thường tái cấu trúc được "buộc tội chống lại" lỗi ban đầu Một . Họ được gửi cùng với bản sửa lỗi, được xem xét với bản sửa lỗi, được bán vé với bản sửa lỗi. Họ là một phần của sửa chữa.

Nhưng có những tái cấu trúc lớn hơn, ít tập trung hơn cũng xảy ra. Một quan sát chung rằng lớp D là quá lớn. Nó sẽ dễ dàng hơn để làm việc trên nếu bạn loại bỏ sự trùng lặp trong E . Và những phép tái cấu trúc đó là một trong những cách mạo hiểm nhất mà bạn sẽ thực hiện (đặc biệt là trong một cơ sở mã mà không cần kiểm tra). Bằng mọi cách, tạo vé cho những người đó; đặt chúng thông qua ít nhất là quá trình xem xét bình thường của bạn.