Ai đó có thể giải thích ưu điểm của việc xóa (hoặc giữ) mã không sử dụng không?

Tôi đã nghe nói nhiều lần rằng mã không sử dụng phải bị xóa khỏi dự án. Tuy nhiên tôi không rõ "tại sao?".

Điểm của tôi để không xóa đó là:

• Mã đã được viết và những nỗ lực đã được bỏ ra
• Mã có thể được kiểm tra trên môi trường thực và ngữ đoạn
• Nếu được tổ chức tốt (nhóm, gói riêng biệt, kết hợp lỏng lẻo, v.v.), nó không làm phiền bạn về phân tích mã tổng thể hoặc tái cấu trúc
• Mã có thể được sử dụng trong tương lai
• Khi bị xóa, tác giả có thể cảm thấy khó chịu

Ai đó có thể giải thích ưu điểm của việc xóa (hoặc giữ) mã không sử dụng không?

Dưới đây là một số lý do tại sao nên xóa mã không sử dụng:

• Đối với bất kỳ ai mới làm việc trong một dự án, họ không chỉ phải hiểu mã làm việc mà còn phải hiểu các vật liệu chưa sử dụng. Điều này gây lãng phí thời gian và tạo ra sự nhầm lẫn.

• Có một nguy cơ là đôi khi ai đó sẽ thực hiện một thay đổi, điều này vô tình liên quan đến mã 'không hoạt động' và có thể tạo ra lỗi. Tôi biết nó đã xảy ra trong các dự án mà tôi đã làm việc.

• Việc duy trì bất kỳ mã nào là một gánh nặng hành chính. Bằng cách duy trì mã dự phòng cũ, gánh nặng sẽ tăng lên. Ví dụ: việc hợp nhất các thay đổi trong nhánh chính trở nên khó khăn hơn vì có nhiều mã phải làm việc hơn và nhiều khả năng mắc lỗi hơn.

• Điều xảy ra theo thời gian là ngày càng nhiều mã cũ không sử dụng được thêm vào cơ sở mã. Điều này làm tăng sự nhầm lẫn, hiểu lầm tiềm ẩn và chi phí quản lý.

• Rất khó xảy ra khả năng mã không sử dụng được sử dụng lại. Theo thời gian, khả năng sử dụng lại giảm dần. Nếu mã cần được loại bỏ và được coi là đủ quan trọng thì mã có thể được phân nhánh và ghi lại.

• Bất kỳ cảm xúc cá nhân nào mà một lập trình viên có thể có về mã mà họ có thể đã làm việc chăm chỉ là điều dễ hiểu. Nhưng một phần của việc trở nên chuyên nghiệp đòi hỏi những suy nghĩ đó phải được đặt sang một bên vì những điều tốt đẹp hơn. Thời gian là viết tắt của không ai cả và không có chỗ cho việc lưu giữ mã lịch sử trong một cơ sở mã đang hoạt động.

@suspectus đã hoàn thành xuất sắc việc trình bày lý do xóa mã; Tôi muốn giải quyết các gạch đầu dòng cá nhân của bạn để giữ mã.

• Mã đã được viết và những nỗ lực đã được bỏ ra

Nhưng nếu mã đã viết sẵn không được sử dụng, thì đây chỉ là giá mà không có giá trị (trong tương lai). Đó là nỗ lực được đầu tư vô ích, và việc bảo quản sản phẩm không sử dụng của những nỗ lực đó không xác thực những nỗ lực đó. Chúng tôi giữ mã vì nó hữu ích, bây giờ, không phải như một số loại kỷ niệm cho những nỗ lực của các tác giả.

• Mã có thể được kiểm tra trên môi trường thực và ngữ đoạn

Tôi xin lỗi, tôi không biết ý của bạn là gì.

• Nếu được tổ chức tốt (nhóm, gói riêng biệt, kết hợp lỏng lẻo, v.v.), nó không làm phiền bạn về phân tích mã tổng thể hoặc tái cấu trúc

Nếu nó tồn tại trong cơ sở mã, cho dù được tổ chức tốt như thế nào, nó cũng góp phần vào gánh nặng duy trì và hiểu. Đúng, nó có thể được sắp xếp để giảm bớt gánh nặng, nhưng nếu nó biến mất, nó không có gánh nặng nào cả.

• Mã có thể được sử dụng trong tương lai

Trong trường phái Agile, chúng tôi nói YAGNI : You Ain’t Gonna Need It. Có, bạn có thể sử dụng nó trong tương lai, nhưng chúng ta không thể biết đủ ngày hôm nay về nhu cầu của ngày mai để có thể dự đoán điều đó với bất kỳ mức độ tin cậy nào. Suy nghĩ khác là sự kiêu ngạo có xu hướng trở nên kiêu ngạo. Những gì chúng ta có thể biết về ngày mai là: chúng tôi muốn cơ sở mã của chúng tôi dễ sửa đổi và mã không sử dụng làm giảm đặc tính đó.

• Khi bị xóa, tác giả có thể cảm thấy khó chịu

Tác giả phải vượt qua nó. Tất cả chúng tôi đã viết những thứ hóa ra không hữu ích - tốt hơn nhiều để có thể trỏ đến phần nội dung mã đang được sử dụng (vì phần nhỏ không sử dụng đã bị xóa) hơn là phần nội dung mã mà bạn có thể nói về một vài phương pháp "và phương pháp đó thực sự đang được sử dụng!"

Không đủ khó để chọn một số mã và tìm ra mục đích, nhưng bây giờ bạn phải tìm ra những phần nào không được sử dụng?

Mã đã được viết và những nỗ lực đã được bỏ ra

Nó cũng không cần thiết. Nếu bạn không sử dụng nó cho bất cứ việc gì, nó (theo định nghĩa) sẽ vô dụng, bất kể nó làm gì hoặc đã bỏ ra bao nhiêu công sức cho nó.

Mã có thể được kiểm tra trên môi trường thực và ngữ đoạn

Nếu nó vô dụng, nó vẫn vô dụng cho dù bạn có kiểm tra nó. Nếu mã vô dụng, các bài kiểm tra đối với nó cũng sẽ vô dụng (vì vậy việc giữ mã nhận xét ở đó sẽ tạo ra sự mơ hồ - bạn có giữ các bài kiểm tra không? Nếu bạn có mã khách hàng của mã nhận xét, bạn có nhận xét mã khách hàng không? )

Nếu được tổ chức tốt (nhóm, gói riêng biệt, kết hợp lỏng lẻo, v.v.), nó không làm phiền bạn về phân tích mã tổng thể hoặc tái cấu trúc

Không phải vậy. Tất cả các công cụ của bạn (kiểm soát nguồn, phân tích tĩnh, trình trích xuất tài liệu, trình biên dịch, v.v.) sẽ chạy chậm hơn, vì chúng phải xử lý nhiều dữ liệu hơn (và một phần lớn hơn hoặc nhỏ hơn của dữ liệu đó là nhiễu).

Mặt khác, nếu mã không được tổ chức tốt, nó sẽ làm xáo trộn phân tích tĩnh, tái cấu trúc và bất kỳ hoạt động nào khác.

Bạn đang giới thiệu tiếng ồn cho đầu vào công cụ của bạn và hy vọng họ xử lý đúng với nó.

Điều gì sẽ xảy ra nếu công cụ phân tích tĩnh của bạn tính toán tỷ lệ nhận xét / mã? Bạn chỉ làm nó rối tung lên, với một cái gì đó có liên quan đến ngày hôm qua (hoặc bất cứ khi nào mã được nhận xét).

Có liên quan nhất, các khối mã được nhận xét gây ra sự chậm trễ trong việc hiểu mã để bảo trì và phát triển thêm và những sự chậm trễ như vậy hầu như luôn phải trả giá đắt. Hãy tự hỏi bản thân điều này: Nếu bạn cần hiểu việc triển khai một hàm, bạn muốn xem xét điều gì? hai dòng mã rõ ràng, hay hai dòng mã và hai mươi sáu nhận xét khác không còn thực tế?

Mã có thể được sử dụng trong tương lai

Nếu có, bạn sẽ tìm thấy nó trong SCM của nhóm bạn lựa chọn.

Nếu bạn sử dụng một SCM có thẩm quyền và dựa vào nó để giữ mã chết (thay vì làm lộn xộn nguồn), bạn sẽ không chỉ biết ai đã xóa mã đó (tác giả cam kết), mà còn vì lý do gì (thông báo cam kết) và những gì khác các thay đổi đã được thực hiện cùng với nó (phần còn lại của các khác biệt cho cam kết đó).

Khi bị xóa, tác giả có thể cảm thấy khó chịu

Vì thế?

Bạn (tôi giả sử) là cả một nhóm các nhà phát triển được trả tiền để tạo ra phần mềm tốt nhất mà bạn biết, không phải là "phần mềm tốt nhất mà bạn biết cách làm mà không làm tổn thương cảm xúc của X".

Đó là một phần của lập trình, phần lớn mã được viết cuối cùng sẽ bị loại bỏ; chẳng hạn, Joel Spolsky đã nói vào một thời điểm nào đó rằng đối với công ty của anh ấy, khoảng 2% mã được viết cho thấy sản xuất.

Nếu bạn ưu tiên cái tôi của nhà phát triển hơn chất lượng của cơ sở mã, bạn sẽ hy sinh chất lượng sản phẩm của mình, vì ... chính xác là gì? Bảo tồn sự non nớt của các nhà phát triển đồng nghiệp của bạn? Bảo vệ những kỳ vọng không thực tế của đồng nghiệp của bạn?

Chỉnh sửa: Tôi đã thấy một lý do hợp lệ để để lại mã đã nhận xét trong nguồn và đó là một trường hợp rất cụ thể: khi mã được viết ở dạng kỳ lạ / không trực quan và cách viết lại sạch sẽ thì không. làm việc vì một lý do thực sự tinh tế. Điều này cũng chỉ nên được áp dụng sau khi đã thực hiện nhiều lần để khắc phục sự cố và mỗi lần thử lại xuất hiện cùng một lỗi. Trong trường hợp như vậy, bạn nên thêm mã trực quan được nhận xét dưới dạng nhận xét và giải thích lý do tại sao nó không hoạt động (vì vậy các nhà phát triển trong tương lai sẽ không thử thay đổi tương tự lần nữa):

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

Mã chết đang làm ô nhiễm mã của bạn

Mã chết làm giảm khả năng hiểu và dễ đọc.

Mã tốt nhất luôn được sử dụng lại và nếu bạn có mã chết, nó sẽ giảm khả năng sử dụng lại

Chúng tôi được thúc đẩy bởi cách tiếp cận mã hóa theo mô-đun, nơi chúng tôi thiết kế các mã để tương tác với các lập trình viên đồng nghiệp của chúng tôi, không phải cho một máy. Chúng ta nên dành nhiều năng lượng nhất để giúp họ dễ dàng hiểu mã của chúng ta. Máy sẽ ổn.

Mã chết hoặc được nhận xét giống như các dấu hiệu sai lệch chỉ khiến mọi người bối rối, vì vậy hãy tránh nó bằng mọi giá.

• Sợ hãi . Điều này khiến đội lo lắng nhiều hơn và sản xuất ít hơn. Mức độ sợ hãi tăng lên theo cấp số nhân khi nhiều mã chết được đưa vào. "Chúng tôi không biết liệu bit đó có được sử dụng hay không, vì vậy chúng tôi không dám tháo nó ra hoặc chạm vào nó."

• Đang quét các thay đổi . Nếu thứ gì đó cần thay đổi ở mọi nơi trong hệ thống cũng tồn tại trong mã chết, bạn có thay đổi nó không? Rất khó để biết nếu nó chắc chắn không được sử dụng ở đâu đó, vì vậy nó luôn là rủi ro. Và ngay cả khi nó không phá vỡ bất cứ điều gì, mã chết có hoạt động được không nếu nó được lấy lại để sử dụng sau thay đổi này?

  Khi xử lý một thay đổi sâu rộng, các nhà phát triển cũng sẽ phải kiểm tra mọi nơi chứa mã và trong trường hợp mã chết, điều này là thừa. Và việc kiểm tra chúng mất nhiều thời gian hơn khi mã đã chết vì rất khó để xác minh rằng nó không được sử dụng ở bất kỳ đâu.

• Tải trọng tinh thần . Mỗi khi bạn cần suy nghĩ về việc liệu thứ gì đó đã được sử dụng hay bạn có nên làm điều gì đó với mã chết hay không, nó sẽ cần một phần sức mạnh não bộ của bạn.
• Những cuộc rượt đuổi ngỗng trời . "Tôi cần một ví dụ về cách sử dụng Foobar. Ồ, nó nằm ở những nơi này trong cơ sở mã. Tôi sẽ kiểm tra lần truy cập đầu tiên và tìm ra vị trí này trong giao diện người dùng. Hmm ... Không thể tìm thấy nó ở đâu."
• Báo cáo lạm phát (ví dụ: có bao nhiêu dòng mã, lớp, quy trình, thay đổi). Làm sai lệch khả năng hiển thị của dự án và quyết định về những phần nào của cơ sở mã sẽ được thực hiện và ước tính về các dự án trong tương lai.
• Niềm tin suy yếu trên cơ sở mã . Điều này có thể dẫn đến việc dành nhiều thời gian hơn cho các tác vụ dư thừa và nó phá vỡ quy trình sử dụng cơ sở mã. Các nhà phát triển có thể phải kiểm tra cực kỳ cẩn thận để đảm bảo rằng mọi thứ họ sử dụng sẽ hoạt động theo cách họ nghĩ.

Sẽ rất có giá trị nếu bạn biết rằng một phần của codebase không được sử dụng bởi vì sau đó bạn có thể loại bỏ nó. Nếu bạn để nó ở lại thì trong tương lai rất khó hoặc gần như không thể chắc chắn rằng nó thực sự không được sử dụng. Ví dụ, một số thứ sử dụng mã theo những cách đáng ngạc nhiên: phản chiếu, gọi động các quy trình được nối từ chuỗi, eval, phép khung .

Tuy nhiên, nếu có khả năng cao mã đó sẽ được sử dụng trong tương lai, sẽ dễ dàng thêm nếu mã đó nằm ngay tại đó cùng với mã khác thay vì trong hệ thống kiểm soát phiên bản. Bạn có thể không nhớ bất kỳ từ nào mà mã có sau một thời gian, vì vậy có thể rất khó để tìm mã từ ruột của VCS. Nhưng tôi chỉ để cho mã chết tồn tại hiếm khi và thậm chí sau đó tôi sẽ nhận xét mã ra.

• Mã không sử dụng là không gian tìm kiếm lớn hơn cho cả bạn để đọc qua và bất kỳ thứ gì khác thường quét mã của bạn. Ví dụ: một trình biên dịch, IDE, tìm trong tệp, gỡ lỗi, phân tích tĩnh, hơn thế nữa để xem xét, bao gồm tệp, kiểm tra từ VCS, v.v. Điều này làm chậm các quá trình đó và thêm tiếng ồn đáng kể.
• Mã không sử dụng không phải lúc nào cũng là mã chết. Nó có thể thực thi trong một số trường hợp nhất định. Điều này không chỉ có thể cung cấp véc tơ cho các lỗi và các vấn đề về hiệu suất mà còn có thể là một mối lo ngại về bảo mật. Về hiệu suất, điều này có thể tự thể hiện theo những cách không mong đợi chẳng hạn như lượt tải xuống lớn hơn.
• Mã không sử dụng nghĩa là mã không sử dụng. Nếu bạn xóa một lệnh gọi hàm và sau đó tìm kiếm các cách sử dụng của hàm đó để xem liệu nó có còn cần thiết hay không, bạn có thể thấy khớp với mã không sử dụng trước đó và giả sử bạn có thể giữ nó. Bạn càng có nhiều mã không sử dụng, bạn càng có nhiều bước nhảy để xác định xem mã đó có chưa được sử dụng hay không.
• Mã không được sử dụng vẫn thường phải được duy trì. Giả sử A và B phụ thuộc vào C. Trong số đó, B không được sử dụng. Bạn thay đổi C và sau đó B sẽ không biên dịch vì bạn đã xóa một thành viên khỏi cấu trúc trong C mà B yêu cầu, bây giờ bạn phải sửa B hoặc chủ động xóa nó khỏi biên dịch. Bạn nên loại bỏ nó một cách đơn giản.

Danh sách này có vẻ đơn giản nhưng mỗi người trong số này biểu hiện theo hàng trăm cách khác nhau, thêm lực cản để hiệp lực trong toàn bộ quá trình phát triển. Sự kém hiệu quả thường có thể được chứng minh hoặc chứng minh một cách thẳng thắn và toán học.

Để đáp lại điểm của bạn ...

• Mã đã được viết và những nỗ lực đã được bỏ ra

Nhưng nó thường xuyên phải được duy trì. Nó cũng sẽ hiển thị trong những thứ như tìm thấy trong tệp.

• Mã có thể được kiểm tra trên môi trường thực và ngữ đoạn

Tôi không chắc ý của bạn về cái này. Tôi nghĩ nó giống với cái cuối cùng. Ý bạn là mã đã được kiểm tra và việc làm sạch nó có thể có nghĩa là nó cần kiểm tra lại. Đó là một chi phí thường xứng đáng bởi vì nó sẽ trả hết 90% thời gian và để tránh nó phải được làm sạch trước khi đưa vào sản xuất. Gần như tất cả các mã đều có hai lần lặp lại, hãy làm cho nó hoạt động, làm cho nó sạch sẽ. Sở dĩ phải thử hai lần là do ai đó đã bỏ qua bước cuối cùng. Nếu mã của bạn quá đắt để có bằng chứng thì hãy đọc sự khác biệt, hãy kiểm tra (điều này có thể xảy ra nếu nó lộn xộn với nhiều mã không sử dụng), v.v. thì đó là toàn bộ vấn đề khác.

• Nếu được tổ chức tốt (nhóm, gói riêng biệt, kết hợp lỏng lẻo, v.v.), nó không làm phiền bạn về phân tích mã tổng thể hoặc tái cấu trúc

Mã của bạn dù sao cũng phải như thế này nhưng điều đó chỉ giảm nhẹ vấn đề ở mức độ vừa phải. Đó là lập luận kỳ lạ nhất khi nghe rằng một cái gì đó nên được tổ chức nhưng không sạch sẽ. Việc cố gắng giữ mã theo mô-đun và giảm bớt sự phụ thuộc là điều bình thường nhưng bạn cũng muốn mã có thể sử dụng lại và nếu tất cả các mô-đun của bạn là một hòn đảo thì rất có thể bạn đã không bị KHÔ. Bạn cũng có thể thấy mình đang thực hiện việc tách quá nhiều mà không làm gì khác ngoài việc giảm thiểu vấn đề mã lộn xộn không sử dụng.

• Mã có thể được sử dụng trong tương lai

Rất nhiều người coi trọng mã viết. Nếu bây giờ nó không được sử dụng, nó sẽ chết và trong thực tế, khi bạn đi xuống con đường này, thường chỉ một phần mã không sử dụng trở thành mã đã qua sử dụng. Trong tất cả các xác suất, mã không sử dụng có thể không sử dụng được hoặc mã đã sử dụng. Mã có nhiều khả năng được sử dụng lại là mã đã được sử dụng đang làm việc gì đó.

Điều tồi tệ hơn là mã không sử dụng không có mục đích. Khi ai đó đi cùng và phải thay đổi thứ gì đó ảnh hưởng đến mã không sử dụng, họ sẽ bối rối khi ngồi đó cố gắng tìm ra mã không sử dụng này mà không có mục đích cần làm.

Thật dễ dàng để mọi người cảm thấy như thế này khi bắt đầu vì code tốn rất nhiều công sức. Tuy nhiên, khi đã thông thạo và đã quen với nó, mã sẽ giống như đi xe đạp. Bạn sẽ thấy khi chi phí viết một đoạn mã như vậy giảm mạnh chi phí duy trì nó tăng lên.

• Khi bị xóa, tác giả có thể cảm thấy khó chịu

Đây là vấn đề của tác giả. Một mặt, thật ích kỷ khi để lại vô số mã không sử dụng cho những người khác phải xử lý. Mặt khác, nếu một tác giả đặt cảm xúc của họ lên trên chất lượng mã thì có lẽ họ không nên viết mã. Bạn xuống đường với điều này, bạn không thể sửa mã của họ khi nó bị hỏng bởi vì nó sẽ làm tổn thương cảm xúc của họ. Sẽ không phải là một dấu hiệu tốt nếu ai đó gắn bó với mã chỉ vì nó là của họ hơn là vì nó tốt. Một tác giả nên cảm thấy hạnh phúc khi mã của họ được làm sạch. Điều này giống như ai đó lấy thùng rác của bạn ra cho bạn và ném nó vào thùng.

Tôi sẽ ở trên mặt trăng nếu ai đó làm điều đó cho tôi. Điều có thể giúp bạn vượt qua những cảm giác đó dễ dàng hơn là thay vì đợi người khác làm điều đó, hãy thử tự mình làm. Tiếp tục viết lại lặp đi lặp lại một đoạn mã bạn đã làm, làm cho nó hoạt động tốt hơn, di chuyển ngắn gọn, ít dư thừa và linh hoạt hơn với ít mã hơn mỗi lần. Cố gắng không cảm thấy hài lòng về số lượng mã nhưng bạn có thể đạt được bao nhiêu với dù mã ít. Điều này đang được mài giũa để tăng cấp và một khi bạn làm như vậy, tất cả mã của bạn sẽ xuất hiện ở mức tốt sau đó vì vậy nó sẽ không cần phải được tăng cấp thường xuyên.

Trước hết, bạn nên luôn sử dụng công cụ kiểm soát nguồn để quản lý các dự án của mình và do đó xóa mã không sử dụng là một phương pháp hay vì bạn luôn có thể quay lại sử dụng kiểm soát nguồn để lấy mã đã xóa. Đối với tôi, lý do để xóa mã không sử dụng là chỉ người biết mã chưa được sử dụng mới biết về nó, một người khác trong nhóm sẽ tìm thấy mã đó và cố gắng tìm ra nó có tác dụng gì và nó phù hợp như thế nào trong toàn bộ ứng dụng và sẽ cảm thấy thất vọng sau rất nhiều nỗ lực mà mã không được sử dụng ở tất cả :)

Cuộc thảo luận này đã được vài năm, nhưng tôi chỉ mới bắt gặp nó ...

Một điều mà tôi không thấy đề cập đến là công việc phải được phát sinh để loại bỏ mã không sử dụng. Trong nhiều trường hợp, về bản chất, thời gian và nỗ lực để xóa mã không sử dụng là không đáng kể, cộng với chi phí thường bổ sung để kiểm tra và ghi lại hệ thống đã cấu trúc lại. Chỉ là một điều khác để xem xét trong quá trình quyết định.

Tôi nghĩ rằng bạn có thể gặp hai trường hợp: - mã ứng dụng: nếu nó không được sử dụng có thể nó chưa được kiểm tra và không bị thay đổi theo thời gian, có thể bạn có thể chuyển sang "kho lưu trữ mã nội bộ" - Mã API: nếu bạn đang viết thư viện thì IMHO đó là một lựa chọn tốt hơn để duy trì nó nhưng bên trong quá trình phát triển tích cực của bạn

Bạn có chắc là mã này chưa được sử dụng không?

Nó không đủ để kiểm tra mã vẫn còn biên dịch. Trong C ++, nếu bạn loại bỏ một phương thức được định nghĩa ngầm "không được sử dụng" giống như operator=bạn sẽ không gặp lỗi trình biên dịch, lớp sẽ chỉ bắt đầu sử dụng một triển khai mặc định (có thể không chính xác) một cách im lặng. Trong Java hoặc C #, mã có thể được sử dụng thông qua phản xạ. Trong các ngôn ngữ hướng đối tượng, kế thừa có thể đóng một vai trò nào đó (lớp cơ sở bây giờ có thể được gọi). Trong hầu hết mọi ngôn ngữ, một hàm quá tải khác có thể đã tiếp quản.

Kiểm tra tuổi của mã trong kiểm soát phiên bản, không chỉ là nó chưa được sử dụng. Tôi đã thấy mã trông không được sử dụng nhưng mới được cam kết và thực sự là bước đầu tiên trong dự án của một nhà phát triển khác.

Tích cực xóa mã không sử dụng

Bạn trả tiền để duy trì mã:

• Sửa chữa các bản dựng bị hỏng (thời gian kỹ thuật). Gần đây, chúng tôi đã có một chuỗi #includethay đổi phức tạp , gây ra tình trạng quá tải mới cho mã không sử dụng, dẫn đến vấn đề đau đầu về quy mô hợp lý cho mọi kỹ sư trong nhóm hàng chục nhà phát triển.
• Trong tài nguyên máy trên các bài kiểm tra (giả sử bạn có các bản dựng liên tục tự kiểm tra). Nhóm của tôi gần đây đã xem xét tất cả các bài kiểm tra chậm nhất của chúng tôi và nhiều bài kiểm tra trong số đó đã hết mã không sử dụng. Các kỹ sư đang chạy thử nghiệm cục bộ hoặc là một phần của tích hợp liên tục đang đợi các thử nghiệm trên mã không sử dụng.
• Về khả năng đọc (thời gian kỹ thuật lại). Các tệp tiêu đề của bạn đại diện cho một API. Nếu chúng bao gồm các hàm mà không ai muốn sử dụng nhưng mọi người phải đọc, thì đường học tập mã của bạn khó hơn nhiều.
• Trong tìm kiếm mã (thời gian kỹ thuật một lần nữa). Bạn sẽ dọn dẹp nhà cửa, ổ cứng hay Google Drive của mình? Bạn càng tìm kiếm một miền, điều quan trọng là miền đó phải có nội dung liên quan để tránh xác thực sai (hoặc bạn sử dụng tìm kiếm phức tạp hơn như công cụ tìm kiếm trên web).

Tôi muốn nói rằng về cơ bản, tất cả các mã mà nhà phát triển trung bình viết đều trở nên không được sử dụng sau 5 năm để hoạt động này không bao giờ dừng lại. Đừng để đây là bạn; chỉ viết mã chất lượng cao và thực sự cần thiết.