Làm thế nào để tôi thuyết phục các đồng đội của mình rằng chúng ta không nên bỏ qua các cảnh báo của trình biên dịch?

Tôi làm việc trong một dự án lớn (giống như một sự kết hợp lộn xộn của hàng tá dự án nhỏ không thể tách rời do quản lý phụ thuộc kém, nhưng đó là một cuộc thảo luận khác) trong Java bằng cách sử dụng nhật thực. Chúng tôi đã tắt một số cảnh báo từ cài đặt trình biên dịch và dự án vẫn có hơn 10.000 cảnh báo.

Tôi là một người ủng hộ lớn để cố gắng giải quyết tất cả các cảnh báo, khắc phục tất cả chúng nếu có thể, và đối với những người được xem xét và coi là an toàn, hãy đàn áp chúng. (Tương tự với nỗi ám ảnh tôn giáo của tôi với việc đánh dấu tất cả phương thức được thực hiện / ghi đè là @Override). Lập luận lớn nhất của tôi là các cảnh báo thường giúp bạn tìm ra các lỗi tiềm ẩn trong thời gian biên dịch. Có thể trong 99 trên 100 lần, các cảnh báo là không đáng kể, nhưng tôi nghĩ rằng việc gãi đầu rằng nó sẽ tiết kiệm được một lần rằng nó ngăn chặn một lỗi lớn, tất cả đều đáng giá. (Lý do khác của tôi là OCD rõ ràng của tôi với độ sạch mã).

Tuy nhiên, rất nhiều đồng đội của tôi dường như không quan tâm. Thỉnh thoảng tôi sửa các cảnh báo khi tôi tình cờ gặp chúng (nhưng bạn biết điều đó thật khó khăn khi bạn chạm vào mã được viết bởi đồng nghiệp). Bây giờ với nhiều cảnh báo theo nghĩa đen hơn các lớp học, lợi thế của các cảnh báo được giảm thiểu rất nhiều, bởi vì khi các cảnh báo là rất phổ biến, không ai sẽ bận tâm tìm hiểu tất cả chúng.

Làm thế nào tôi có thể thuyết phục đồng đội của mình (hoặc quyền hạn) rằng các cảnh báo cần phải được giải quyết (hoặc bị đàn áp khi điều tra đầy đủ)? Hay tôi nên thuyết phục bản thân rằng tôi điên?

Cảm ơn

(PS Tôi đã quên đề cập đến điều cuối cùng đã khiến tôi đăng câu hỏi này là tôi buồn bã nhận thấy rằng tôi đang sửa các cảnh báo chậm hơn so với chúng được tạo ra)

Bạn có thể làm hai điều.

1. Chỉ ra rằng các cảnh báo là có lý do. Các nhà văn biên dịch không đặt chúng vào vì chúng có ý nghĩa. Mọi người trong ngành của chúng tôi thường rất hữu ích. Nhiều cảnh báo là hữu ích.

2. Thu thập một lịch sử của những thất bại ngoạn mục phát sinh từ các cảnh báo bỏ qua. Một tìm kiếm trên web cho "Chú ý đến các cảnh báo của trình biên dịch" trả về một số giai thoại.

Nỗi ám ảnh của bạn @Overridekhông phải là một "nỗi ám ảnh". Đó là một điều tốt. Bao giờ sai chính tả một tên phương thức?

Đọc có liên quan ở đây . C ++, nhưng vẫn có liên quan. Tôi đặc biệt thích ví dụ này (nhận xét mã là của tôi):

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

Rất nhiều lần, một cảnh báo sẽ có nghĩa là sự khác biệt giữa ứng dụng bị lỗi với lỗi thực sự sẽ giúp bạn theo dõi một lỗi thiết kế và sửa nó (chẳng hạn như đánh máy an toàn ) hoặc giả định ứng dụng và sau đó thực sự hành xử không đúng hoặc sai cách (đó sẽ là trường hợp với kiểu chữ không an toàn ). Tương tự, họ cũng chỉ ra mã cruft hoặc mã chết có thể được loại bỏ (khối mã không thể truy cập, các biến không sử dụng), có thể được coi là tối ưu hóa mã hoặc các trường hợp không xác định sẽ xuất hiện trong thử nghiệm, như ví dụ trên cho C ++. Lưu ý rằng ví dụ này dẫn đến lỗi thời gian biên dịch trong Java.

Vì vậy, sửa lỗi cảnh báo có (ít nhất) một số lợi thế cho quản lý:

1. Ít có khả năng mã hành xử không đúng với dữ liệu do người dùng nhập vào, đối với những người cao hơn quan tâm đến hình ảnh của công ty và cách xử lý dữ liệu của khách hàng, nên là một Thỏa thuận lớn (tm). Sự cố để ngăn người dùng làm điều gì đó ngớ ngẩn tốt hơn là không bị rơi và để họ làm điều đó.
2. Nếu họ muốn cải tổ nhân sự, mọi người có thể tham gia vào một cơ sở mã hóa không có cảnh báo (và không sợ hãi hay phàn nàn nhiều như vậy ..). Có lẽ điều này sẽ làm giảm số lượng càu nhàu đang diễn ra hoặc ý kiến ​​về khả năng duy trì hoặc chất lượng đóng góp của Đội X cho Dự án Y.
3. Tối ưu hóa mã bằng cách loại bỏ các cảnh báo của trình biên dịch, trong khi không đưa ra bất kỳ cải tiến đáng kể nào về thời gian chạy, sẽ cải thiện nhiều điểm khi thử nghiệm:
   • Bất kỳ điểm số bảo hiểm mã sẽ có khả năng tăng.
   • Kiểm tra ranh giới và các trường hợp kiểm tra không hợp lệ có thể sẽ thành công thường xuyên hơn (do kiểu chữ an toàn đã nêu ở trên , trong số những thứ khác).
   • Khi một trường hợp thử nghiệm thất bại, bạn không phải suy nghĩ liệu đó có phải là do một trong những cảnh báo của trình biên dịch trong tệp nguồn đó hay không.
   • Người ta dễ dàng tranh luận rằng các cảnh báo về trình biên dịch bằng 0 tốt hơn hàng ngàn. Không có cảnh báo hoặc lỗi nào nói về chất lượng mã, vì vậy bạn có thể lập luận rằng chất lượng mã cải thiện các cảnh báo ít hơn.
4. Nếu bạn không có cảnh báo về trình biên dịch và một hoặc nhiều lời giới thiệu, việc biết ai đã gây ra những điều đó xuất hiện trong cơ sở mã sẽ dễ dàng hơn rất nhiều. Nếu bạn có chính sách "không cảnh báo", điều đó sẽ giúp họ xác định những người không thực hiện đúng công việc của họ, có lẽ? Viết mã không chỉ là làm cho một cái gì đó hoạt động, mà là làm cho nó hoạt động tốt .

Lưu ý rằng tôi vẫn chỉ là một nhà phát triển cơ sở ít biết về quản lý dự án, vì vậy nếu tôi nói điều gì đó sai, xin hãy sửa suy nghĩ của tôi và cho tôi cơ hội chỉnh sửa trước khi bạn hạ gục tôi khỏi sự tồn tại :)

Tôi đã từng làm việc trong một dự án có đặc điểm tương tự trong quá khứ. Điều này đặc biệt ban đầu được viết bằng Java 1.4. Khi Java 5 với các tổng quát xuất hiện, người ta có thể tưởng tượng số lượng cảnh báo được trình biên dịch đưa ra cho mỗi lần sử dụng API Bộ sưu tập.

Sẽ mất khá nhiều thời gian để loại bỏ tất cả các cảnh báo, bằng cách bắt đầu sử dụng thuốc generic. Đó là một yếu tố phải được tính đến, nhưng khi bạn phải thuyết phục ai đó (đặc biệt là người quản lý của bạn) rằng nó cần sửa chữa, bạn sẽ cần dữ liệu cứng, như

thời gian dành cho các lỗi về mã kế thừa hoặc không tuân thủ tiêu chuẩn (tiêu chuẩn là tiêu chuẩn mã hóa của dự án của bạn) có thể tránh được.

Bạn có thể tiếp tục xuất trình một hóa đơn thể hiện cách bạn mất thời gian và tiền bạc bằng cách bỏ qua các cảnh báo "nhất định" và ai đó sẽ có ý tưởng. Phần quan trọng là không phải tất cả các cảnh báo đều đáng xem, ít nhất là không ngay lập tức; nói một cách đơn giản hơn, bạn sẽ cần thiết lập mức độ ưu tiên của các cảnh báo cần giải quyết ngay lập tức. Để bắt đầu, hãy xem xét những lỗi thích hợp với các lỗi mà bạn đang thấy trong dự án của mình.

Bạn cũng có thể ghi chú trong trình theo dõi lỗi, khi bạn sửa lỗi, có thể tránh được lỗi đã nói bằng cách không bỏ qua cảnh báo (hoặc có thể bằng cách chạy PMD hoặc FindBugs nếu bạn có CI hoặc hệ thống xây dựng). Miễn là có đủ số lượng lỗi có thể được sửa bằng cách chú ý đến các cảnh báo của trình biên dịch, quan điểm của bạn về việc xem xét các cảnh báo của trình biên dịch sẽ là hợp lệ. Mặt khác, đó là một quyết định kinh doanh, và thường thì nó không đáng để dành thời gian để chiến đấu trong trận chiến này.

Nếu bạn thành công và nhóm của bạn quyết định quan sát các cảnh báo, bạn nên thực hiện một cách tiếp cận từng bước. Không ai có thể và sẽ 10000 cảnh báo trong một lần. Vì vậy, bạn có thể chọn những lỗi quan trọng nhất (những lỗi có xác suất cao) và vô hiệu hóa những lỗi ít quan trọng hơn. Nếu chúng được cố định, tăng mức cảnh báo một lần nữa. Ngoài ra, bạn có thể bắt đầu với FindBugs, cảnh báo về mã gần như luôn luôn là một lỗi.

Tôi hoàn toàn đồng ý với bạn, đó là cách tốt nhất để dọn dẹp các cảnh báo biên dịch càng nhiều càng tốt. Bạn đã đề cập nhóm của bạn đang sử dụng Eclipse làm công cụ phát triển. Eclipse là một công cụ rất tốt để giúp bạn dọn sạch mã và tạo sự thống nhất về kiểu mã.

1. định nghĩa 'Lưu hành động' cho từng dự án Java của bạn, chẳng hạn như mã định dạng, các biến cục bộ không được sử dụng, tổ chức nhập (tôi nghĩ không ai phản đối về cách làm sạch như vậy).
2. xác định các tùy chọn biên dịch cụ thể của dự án cho từng dự án. Ví dụ: mức biên dịch (nếu mã của bạn cần tương thích với 1.4 để xóa các cảnh báo liên quan đến chung), việc gán không có hiệu lực (ví dụ: 'x = x'), v.v. Bạn và đồng đội của bạn có thể đưa ra một thỏa thuận cho các mục đó và Eclipse sẽ báo cáo chúng là 'Lỗi' trong giai đoạn phát triển của bạn sau khi bạn có thỏa thuận về lỗi biên dịch.

Eclipse sẽ tạo một số tệp thuộc tính cho các tùy chọn đó trong thư mục .sinstall, bạn có thể sao chép chúng sang các dự án Java khác và kiểm tra chúng vào SCM như một phần của mã nguồn.

Bạn có thể kiểm tra mã của Eclipse để xem các nhà phát triển Eclipse làm điều đó như thế nào.

Bạn có hai cách để loại bỏ tất cả các cảnh báo (và tôi đồng ý rằng nó có thể ẩn một lỗi tinh vi):

1. Thuyết phục toàn đội rằng đây là điều tốt nhất để làm, và nhờ họ sửa nó.
2. Thuyết phục sếp của bạn rằng đây là điều tốt nhất để làm, và làm cho nó bắt buộc. Sau đó, họ cần phải sửa nó.

Tôi tin rằng 1 là không khả thi trong trường hợp của bạn nữa. Ngoài ra, điều này có thể sẽ mất nhiều thời gian do số lượng cảnh báo mà điều này sẽ hiển thị trong sản lượng năng suất vì vậy quản lý sẽ cần phải biết cách nào.

Vì vậy, đề nghị của tôi là: Đưa nó lên với ông chủ, thuyết phục anh ta rằng đây là một quả bom nổ và đưa ra chính sách chính thức.

Tôi chỉ muốn nói với họ rằng hầu hết trong số này là những cảnh báo không đáng kể và điều cần thiết là chúng tôi phải loại bỏ chúng khỏi danh sách. Vì vậy, chúng tôi sẽ không bỏ lỡ cảnh báo quan trọng thực sự trong đám đông, như nó xảy ra!

Bạn sẽ cần rất nhiều kiên nhẫn trong việc cố gắng thuyết phục họ, loại bỏ các cảnh báo khi thực hiện lập trình cặp sẽ giúp người khác từ bỏ thói quen này. Đề nghị họ đọc Java hiệu quả 'Mục 24: Loại bỏ các cảnh báo không được kiểm soát' (đối với bộ sưu tập chung). Và có thể bỏ qua nhiều trường hợp khi mọi người không làm theo lời khuyên của bạn;)

Một cách tiếp cận hiệu quả ở đây sẽ là thiết lập một máy chủ Tích hợp liên tục tự động xây dựng dự án và chạy thử nghiệm bất cứ khi nào có ai kiểm tra mã. Nếu bạn chưa sử dụng cái này, bạn nên làm và không khó để thuyết phục người khác về lợi ích của việc đó.

1. Thuyết phục quản lý / nhóm lãnh đạo về lợi ích của việc này (ngăn chặn các bản dựng xấu được triển khai, phát hiện sớm các lỗi, đặc biệt là các lỗi vô tình ảnh hưởng đến các phần khác của phần mềm, duy trì kiểm tra hồi quy, kiểm tra sớm và thường xuyên, v.v.)

2. Cài đặt máy chủ CI với tất cả các bài kiểm tra vượt qua (nếu bạn không có bài kiểm tra, hãy viết một bài kiểm tra nhanh, để mọi người thấy rằng nó có màu xanh lá cây).

3. Thiết lập email hoặc thông báo khác về trạng thái của mỗi bản dựng. Điều quan trọng ở đây là bao gồm ai đã kiểm tra mã, thay đổi là gì (hoặc liên kết đến cam kết) và trạng thái + đầu ra của bản dựng. Đây là một bước quan trọng, vì nó gây ra tầm nhìn toàn đội cho cả thành công và thất bại.

4. Cập nhật máy chủ CI để thực hiện kiểm tra thất bại nếu có bất kỳ cảnh báo nào. Điều này sẽ được quản lý và lãnh đạo nhóm nhìn thấy khi tăng tính kỷ luật của đội một cách có hệ thống, và không ai muốn chịu trách nhiệm cho tất cả các email thất bại.

5. (tùy chọn) trở nên đẹp và táo bạo với điều này, bằng cách thêm một số bảng điều khiển có thể nhìn thấy, đèn dung nham, đèn nhấp nháy, v.v. để cho biết trạng thái của bản dựng và ai đã phá vỡ nó / sửa nó.