Các tiêu chuẩn / kiểu mã hóa có nên được thi hành bởi máy chủ tích hợp liên tục chạy các công cụ phân tích tĩnh (ví dụ: PMD, StyleCop / FxCop) và không xây dựng được nếu các tiêu chuẩn không tuân theo? Những loại quy tắc không nên được sử dụng để thất bại trong việc xây dựng?
Câu trả lời:
Các tiêu chuẩn mã hóa nên có ở đó vì một lý do ... và không kiểm tra sự không tuân thủ.
Tuy nhiên, không phải tất cả các vi phạm nên được coi là lỗi - cũng như không phải tất cả các vi phạm biên dịch. Nơi bạn vẽ đường phải là một công ty và một quyết định công cụ.
Ví dụ: MISRA định nghĩa các quy tắc của nó là Bắt buộc và Tư vấn ... Tôi sẽ đề xuất rằng các Cố vấn sẽ cho phép việc xây dựng được tiến hành.
Nó không hoàn toàn chưa từng nghe thấy và bạn sẽ biết nếu nó sẽ làm việc cho bạn chỉ bằng cách thử nó. Có một số bước mà bạn có thể được thực hiện trước đó.
Đầu tiên nhóm nên quyết định các tiêu chuẩn cùng nhau. Sau đó, các công cụ như ReSharper nên được sử dụng để báo cho các nhà phát triển nếu họ không tuân thủ các tiêu chuẩn. Thực hiện đánh giá ngang hàng trên mọi nhiệm vụ có thể giúp đỡ hơn nữa.
Sau khi thực hiện các bước đó, có thể xem xét đưa mã kiểm tra tiêu chuẩn vào máy chủ CI. Tuy nhiên, vẫn nên cân nhắc nếu khôn ngoan xây dựng vì không tuân thủ các tiêu chuẩn mã hóa. Rủi ro là bạn sẽ có rất nhiều bản dựng bị hỏng có thể làm mất đi ý nghĩa của bản dựng bị hỏng.
Thay vì làm cho bản dựng bị hỏng, bạn có thể chạy các công cụ và yêu cầu chúng tạo báo cáo. Nếu vi phạm tiêu chuẩn mã hóa dường như đang gia tăng, bạn có thể tập hợp nhóm và tìm hiểu lý do tại sao điều đó xảy ra.
Các tiêu chuẩn / kiểu mã hóa có nên được thi hành bởi máy chủ tích hợp liên tục chạy các công cụ phân tích tĩnh (ví dụ: PMD, StyleCop / FxCop) và không xây dựng được nếu các tiêu chuẩn không tuân theo?
Những kiểm tra tích hợp liên tục cần phải rất, rất nhanh. Bất kỳ sự chậm trễ đáng kể nào cũng có nghĩa là các lập trình viên của bạn sẽ cam kết và mất theo dõi quá trình suy nghĩ của họ trong khi chờ đợi kết quả. Làm cho nó dài hơn và họ sẽ cam kết và nhận được một tách cà phê hoặc trò chuyện với bạn bè văn phòng của họ về hiệu suất bị mắc kẹt mới nhất của một số đội thể thao. Những sự chậm trễ là rất phản tác dụng. Một số điều tốt nhất là để xây dựng hàng đêm hoặc xem xét mã.
Những loại quy tắc không nên được sử dụng để thất bại trong việc xây dựng?
Những người chủ quan, để bắt đầu với. Làm thế nào để bạn thực thi quy tắc "Mã sẽ tự ghi lại hoặc nhận xét tốt"? Quy tắc "không có số ma thuật"? Đó là những điều tốt nhất còn lại để xem xét mã.
Một loại khác là vi phạm các quy tắc đã được miễn. Với bất kỳ cơ sở mã khá lớn nào, chắc chắn sẽ có một số đoạn mã trong đó vi phạm tiêu chuẩn chính xác là điều nên làm.
Là một phần của Kế hoạch cải tiến chất lượng phần mềm, gần đây chúng tôi đã mã hóa một loạt các mã đánh hơi để tích hợp vào quy trình xây dựng của chúng tôi.
Chúng tôi xây dựng rất nhiều, là một ứng dụng PHP không có trình biên dịch thực sự nên bản dựng thực sự là một bài kiểm tra đơn vị / phân tích tĩnh / người chạy và chúng tôi có thể đủ khả năng để dành một vài chu kỳ cho việc này.
Chúng tôi đã có một số vấn đề về chất lượng mã và một số mã kế thừa có nhiều vấn đề.
Bắt đầu trên cơ sở rằng nếu nó không thất bại thì cam kết sẽ bị bỏ qua, chúng tôi đã bắt đầu xác nhận các cam kết theo tiêu chuẩn mã hóa 'mong muốn' của chúng tôi và không thực hiện các cam kết với các lỗi không đáp ứng tiêu chuẩn.
Việc bảo trì tạm dừng, ngay cả cách khắc phục đơn giản nhất đối với thành phần kế thừa yêu cầu nhà phát triển phải định dạng lại nguồn lớn, và việc xây dựng bị phá vỡ thường xuyên hơn không. Không cần phải nói rằng chúng tôi đã thay đổi các lỗi thành cảnh báo, và bây giờ chúng bị bỏ qua và 'chủ yếu' là vô nghĩa.
Vì vậy, tôi sẽ nói điều này (học được từ kinh nghiệm khó khăn).
Đảm bảo rằng tiêu chuẩn của cơ sở mã của bạn đủ gần với tiêu chuẩn mà bạn thi hành rằng bạn không yêu cầu nhà phát triển định dạng lại khối lượng mã ngay lập tức. Hoặc .. Bạn đã chuẩn bị và mong đợi sự gia tăng nỗ lực.
Là một nhóm nhỏ với yêu cầu giao hàng rất lớn, chúng tôi không thể đủ khả năng để chuyển nhóm thành một hoạt động tái tạo yếu tố lớn. Các tiêu chuẩn mã hóa của chúng tôi hiện chủ yếu được xử lý bằng cách xem xét thủ công và di sản đang được viết lại như một phần của kế hoạch cải tiến liên tục.
Khi tôi nói rằng các cảnh báo 'hầu hết' là vô nghĩa, giờ đây chúng tôi sử dụng chúng để ghi lại số liệu thống kê cho phép chúng tôi đo lường các kpi sẽ tiếp tục cho thấy sự cải thiện.
Khi chúng tôi thực thi mã đánh hơi một lần nữa, chúng tôi sẽ bắt đầu sáng và giới thiệu một vài lần đánh hơi cho đến khi chúng tôi thực thi tiêu chuẩn.
Nó sẽ phụ thuộc vào mục tiêu và chiến lược cuối cùng của bạn .
Buộc tất cả các tiêu chuẩn được đề cập tốt trong máy chủ CI có vẻ rất sinh lợi. Tuy nhiên, nó có thể không thực tế đối với nhóm phát triển lớn (hơn 6 nhà phát triển), nếu nó được thực hiện trên mỗi cam kết với máy chủ. Chờ máy chủ của bạn phản hồi sau khi cam kết KHÔNG nên trì hoãn lâu. Nó có thể có khả năng gây ra một số thời gian xuống.
Tuy nhiên, việc chặn một cam kết nếu mã (bộ thực sự thay đổi) có vấn đề phụ thuộc hoặc không biên dịch là hoàn toàn hợp pháp. Tuy nhiên, việc thất bại mã do bố trí mã và một số quy ước đặt tên có thể quá nghiêm trọng và không hạn chế quan trọng đối với các quy tắc cam kết của máy chủ CI.
Nhưng nó rất có thể là quy tắc hữu ích nếu được áp dụng trong quá trình xây dựng buổi tối.
Ngoài ra, các công cụ bao thanh toán lại có thể hỗ trợ triển khai và tìm hiểu các tiêu chuẩn - như sử dụng Resharper hoặc JustCode của các nhà phát triển.