Có phải là một ý tưởng tốt để sắp xếp thời gian thường xuyên để làm sạch mã? [đóng cửa]

Tôi đang quản lý một nhóm nhỏ các nhà phát triển. Mỗi khi chúng tôi quyết định chúng tôi sẽ dành một hoặc hai ngày để dọn sạch mã của mình.

Sẽ là một ý tưởng tốt để sắp xếp thời gian thường xuyên, giả sử 1 tuần cứ sau 2 tháng, chỉ để dọn sạch cơ sở mã của chúng tôi?

Không.

Khắc phục sự cố trong khi bạn đang làm việc với nó:

• Nếu bạn chờ đợi để cấu trúc lại bit bạn đang làm việc, bạn sẽ quên rất nhiều về nó và phải dành thời gian để làm quen với nó một lần nữa.
• Bạn sẽ không kết thúc mã "mạ vàng" mà cuối cùng không bao giờ được sử dụng vì các yêu cầu đã thay đổi

Ý kiến ​​cá nhân của tôi: Nó hoàn toàn cần thiết cho 90% dự án.

Riêng đối với các dự án bị chi phối nhiều bởi doanh số, thường sẽ có một sự thúc đẩy lớn bao gồm các tính năng mới trong mỗi bản phát hành, và chắc chắn bạn sẽ phải thỏa hiệp bản năng tốt hơn của mình và giới thiệu một vài bản hack / hack ở đây và đó.

Cuối cùng, bạn đã tích lũy đủ 'nợ kỹ thuật' thông qua những thỏa hiệp nhỏ này mà cuối cùng bạn đã dành một lượng thời gian hợp lý để xử lý các lỗ hổng trong cơ sở mã và không thể sử dụng hết tiềm năng của nó.

Thông thường có hai loại vấn đề được tạo theo cách này:

• Những cái nhỏ có thể dễ dàng sửa nhưng có thể mang tính hệ thống, ví dụ như các tham số được đặt tên không đúng, xử lý lỗi không đầy đủ, v.v. Chúng thường sẽ có ít tác động bên ngoài khối mã nơi chúng xuất hiện. Cách tốt nhất để giải quyết những vấn đề này là đánh giá mã và kiểm tra mã khi nó được viết / sửa đổi. Như những người khác đã tuyên bố, không cần thiết phải dành một chu kỳ tái cấu trúc đặc biệt để sửa các lỗi này.
• Những cái lớn có thể phát sinh từ các thông số kỹ thuật chưa hoàn chỉnh hoặc các quyết định thiết kế kém từ sớm hoặc hai nhà phát triển / nhóm tạo ra hai giải pháp khác nhau cho cùng một vấn đề. Chúng thường khó sửa hơn và đòi hỏi nỗ lực phối hợp để khắc phục. Kết quả là chúng thường được hoãn lại, cho đến khi trở thành một mối phiền toái vĩnh viễn. Những loại vấn đề đòi hỏi một khoảng thời gian dành riêng để khắc phục.

Tôi thường cố gắng dành thời gian cho một chu kỳ tái cấu trúc / sửa lỗi thuần túy cứ sau 3 đến 4 chu kỳ. Tôi luôn yêu cầu các nhà phát triển của tôi nói với tôi khi họ cảm thấy thất vọng với cơ sở mã. Không phải mọi nhà phát triển đều phải nỗ lực dọn dẹp - bạn thường có thể (nhưng không phải luôn luôn) làm choáng các nhóm một chút, vì vậy chỉ có một nhóm làm việc dọn dẹp tại bất kỳ thời điểm nào.

Tôi có các nhà phát triển của mình dọn dẹp mã của họ trước khi đăng ký (Subversion) hoặc hợp nhất với nhánh phát triển chính (Git).

Tôi có họ làm như sau:

• Xóa các bình luận không liên quan
• Đảm bảo rằng các phương thức, đối số và biến của chúng được đặt tên thích hợp
• Hãy chắc chắn rằng có cấu trúc cho các lớp và các mục của chúng được gói gọn như chúng cần
• Tái cấu trúc để cải thiện khả năng đọc và giảm bất kỳ mùi mã nào

Đối với các dự án lớn hơn, mã được xem xét chính thức trước khi sáp nhập từ nhánh phát triển sang nhánh chính.

Tôi nghĩ rằng "dành thời gian" sẽ có nghĩa là nó có thể bị trì hoãn hoặc bị hoãn lại do số lượng công việc liên quan. Bằng cách yêu cầu các nhà phát triển thực hiện trên mỗi lần đăng ký (tương đương với yêu cầu / vấn đề thay đổi trong JIRA), việc quản lý sẽ dễ dàng hơn nhiều.

Không theo ý kiến ​​của tôi. Nếu bạn để quá nhiều thời gian giữa khi bạn gặp phải nợ công nghệ và khi bạn sửa nó, bạn sẽ mất bối cảnh của vấn đề là gì. Phải mất nhiều thời gian để sửa chữa, và nó có xu hướng được sửa chữa tồi tệ hơn. Quan trọng nhất, mọi người rời khỏi các cửa sổ bị hỏng vì đó không phải là "tuần dọn dẹp".

Cá nhân, tôi thương lượng để xóa nợ kỹ thuật mỗi lần chạy nước rút nếu tôi biết chúng tôi đã tạo ra một số trong lần chạy nước rút trước đó. Nó giữ cho món nợ luôn mới mẻ trong tâm trí mọi người. Nó giới hạn số lượng mã sử dụng mã vấn đề để việc tái cấu trúc dễ dàng hơn. Nó ngăn ngừa nợ kỹ thuật chồng chất. Và nó giúp thúc đẩy các nhà phát triển từ việc tát một cái gì đó lại với nhau, bởi vì tôi sẽ khiến họ làm điều đó ngay lần chạy nước rút tiếp theo (vì vậy cũng có thể làm điều đó ngay từ đầu).

Tôi chắc chắn sẽ nói có, với một điều kiện: nó nên được thực hiện thường xuyên, tốt nhất là trên cơ sở hàng tuần. Tôi tin rằng một đánh giá mã thường xuyên theo lịch trình cùng với việc thực sự hành động đối với các mặt hàng ra khỏi đánh giá mã sẽ được thanh toán rất nhanh. Xem câu trả lời của pswg

1 tuần cứ sau 2 tháng chắc chắn là không đủ. Điều này nói lên hầu hết các câu trả lời khác, những người trả lời 'Không' cho câu hỏi của bạn. Điểm chính của hầu hết các câu trả lời này là nếu bạn chờ quá lâu, bạn sẽ không còn liên lạc được với mã và thường mất nhiều thời gian hơn để sửa / dọn / tái cấu trúc.

Nó không rõ ràng nếu thỉnh thoảng bạn có nghĩa là một bài tập mã sạch bổ sung. Theo nghĩa đó, có. Những gì chúng ta thực hiện theo, một số suy thoái luôn xảy ra.

Bạn không nên sử dụng lý do đó để không làm điều đúng đắn [Áp dụng các nguyên tắc RẮN, kiểm tra đơn vị liên quan, kiểm tra, v.v.] ngay từ đầu.

Tôi nghĩ rằng hai câu trả lời "Không" "Có" phổ biến hiện nay là hai khía cạnh của cùng một sự thật. Hãy nhớ rằng OP đang nói về một nhóm mà anh ấy đang quản lý, không chỉ là cá nhân. Chúng tôi không thể cho rằng tất cả các nhà phát triển trong nhóm đều đủ kỷ luật để viết mã sạch, dễ đọc; và có vấn đề về áp lực bên ngoài và phương pháp luận nhanh nhẹn. Ngoài ra, ngay cả với những nỗ lực tốt nhất của mọi người, sự khác biệt trong phong cách của họ sẽ có nghĩa là họ có thể viết mã được coi là sạch khi tách rời, nhưng ô uế khi được xem xét cùng với những người khác (không đề cập đến các giao diện khó hiểu).

Mặt khác, "sửa nó trong khi làm việc với nó" theo ý kiến ​​của tôi là một lý tưởng để khao khát. Bạn có thể làm cho mã của mình trở nên "cố định" hơn nữa bằng cách

• cẩn thận ngang hàng
• viết bài kiểm tra đơn vị cùng với chính mã
• áp dụng hướng dẫn mã hóa
• sử dụng công cụ định dạng và linters tự động (nhưng YMMV)
• Vân vân.

Bây giờ, nếu nhóm của OP chấp nhận những điều trên và nếu anh ta khuyến khích cấp dưới của mình - ví dụ như trong quá trình đánh giá mã và trong các phiên làm sạch mã định kỳ - để cố gắng lường trước những cạm bẫy và tránh sự xấu xí trước, anh ta sẽ hy vọng ít hơn thời gian dọn dẹp (Và sau đó họ có thể dành thời gian đó cho tài liệu, tái cấu trúc sâu hơn và chia sẻ kiến ​​thức về những gì họ đã viết và hợp nhất.)

Tôi nghĩ lập lịch trình thời gian thường xuyên là rất tốt cho dù đó là một nhiệm vụ trong một dự án phong cách thác nước thông thường, hoặc những câu chuyện trong một nhanh nhẹn. Có một thời gian định sẵn có thể không có giá trị như chỉ làm việc theo lịch trình của bạn. Điều này cho phép bạn hoàn thành nó như một phần của lịch trình so với việc hủy ngày dọn dẹp vì bạn bị chậm trễ trong dự án.

Sau khi quản lý một dự án có số nợ mã rất lớn, việc thực hiện chúng một cách thường xuyên là chìa khóa để mọi thứ hoạt động trơn tru. Một số thứ của chúng tôi rất lớn, một số thì nhỏ.

Sau một vài tháng làm việc như vậy, trưởng nhóm điều hành của chúng tôi đã nói với tôi rằng mọi thứ đều trôi chảy như thế nào.

Mỗi mặt hàng có vẻ không nhiều, nhưng cũng giống như tất cả các khoản nợ, nó quảng cáo lên.

Câu trả lời lý tưởng là Không, bởi vì bạn thực hiện các bước cần thiết để tránh làm điều này trở nên cần thiết (dọn dẹp khi bạn đi cùng vì một số lý do đã nêu).

Đây có thể là mục tiêu cuối cùng, nhưng bạn có thể có một đội còn lâu mới đưa điều này vào thực tế.

Người quản lý phải chịu một số trách nhiệm Không phải lúc nào cũng là lỗi của nhà phát triển. Các nhà quản lý có thể nói một điều, nhưng họ bắt đầu thúc đẩy các dự án hoàn thành và đưa ra các đề xuất thúc đẩy các thực tiễn xấu. Họ có thể nói theo nghĩa đen, "chúng ta sẽ dọn sạch nó sau" hoặc nếu nó hoạt động, điều đó đủ tốt.

Bạn có thể phải bắt đầu với việc dành một thời gian cụ thể để cho thấy điều này rất quan trọng. Một khi bạn biết nhóm của bạn có khả năng làm sạch mã của họ (không phải là nhất định), thì bạn có thể cố gắng kết hợp nó thường xuyên hơn.

Cuối cùng, bạn không cần phải thiết lập thời gian.

Cá nhân, tôi đấu tranh với việc giải quyết một vấn đề mới và khiến nó hoạt động trong khi cố gắng giữ mọi thứ gọn gàng. Tôi đang trở nên tốt hơn về nó, nhưng thường nghỉ ngơi có chủ ý và dọn dẹp mọi thứ. Đó là một suy nghĩ khác biệt đối với tôi. Cuối cùng, các thực hành vững chắc trở thành thói quen.

Không, bạn nên làm điều này trong khi bạn đang viết mã. Điều này được gọi là tái cấu trúc nếu bạn đang sử dụng TDD. Vấn đề khi bạn đợi một hoặc hai tháng để sửa và làm sạch mã của bạn là bạn có thể thay đổi hành vi mã vì bạn không nhớ mọi đoạn mã của mình.

Tôi đề nghị tái cấu trúc dựa trên mã hóa trước tiên là mã cần thiết để làm cho một cái gì đó hoạt động và ngay khi nó hoạt động thiết kế lại nó, tối ưu hóa nó và làm cho nó đẹp hơn.