Cảnh báo về các phương pháp của bên thứ 3 bị cấm

9

Lưu ý: Câu hỏi này đề cập đến mã được viết bằng Java hoặc C #.

Tôi đang quản lý một vài dự án lớn nơi chúng tôi đã phát hiện ra các vấn đề (không nhất thiết là lỗi) với một số phương thức của bên thứ 3 / SDK và đã viết các tiện ích mở rộng của riêng chúng tôi nên được sử dụng thay thế. Chúng tôi muốn các nhà phát triển nhớ rằng việc sử dụng các phương pháp đó không được khuyến nghị cho dự án này.

Nếu chúng tôi đã sử dụng các thư viện của riêng mình, chúng tôi có thể dễ dàng xóa phương thức đó hoặc đánh dấu nó đã lỗi thời / không dùng nữa nhưng chúng tôi không thể làm như vậy đối với các thư viện mà chúng tôi không viết.

Ví dụ, chúng tôi sử dụng một thư viện cung cấp cho chúng tôi hai tình trạng quá tải:

acme.calculate(int quantity_, double priceInUsDollars_);
acme.calculate(int quantity_, string currencyCode_, double priceInCurrency_);

Chúng tôi muốn các nhà phát triển luôn sử dụng cái đầu tiên và nhận được giá bằng Đô la Mỹ từ các hệ thống tỷ giá FX tiêu chuẩn của riêng chúng tôi. Và thật tuyệt khi IDE (Eclipse / Visual Studio) cảnh báo các nhà phát triển khi họ sử dụng cái đầu tiên. Một cảnh báo trình biên dịch cũng sẽ đủ.

Ngay bây giờ, khi nó đứng, chúng ta phải dựa vào các nhà đánh giá mã để phát hiện ra các lỗi như vậy và như bạn có thể thấy đó không phải là một cách tiếp cận đáng tin cậy.

Một cách có thể tôi chuẩn bị đi là viết kiểm tra kiểu kiểm tra của riêng tôi ( http://checkstyle.sourceforge.net/wrchecks.html ). Nhưng tôi đã tự hỏi nếu có một cái gì đó đơn giản mà tôi có thể sử dụng. Có ai biết cách để đạt được một cảnh báo IDE / trình biên dịch thuộc loại tôi đã mô tả không?

Các giải pháp không phải IDE / trình biên dịch được chào đón nhất.

java c# coding-style ide

— Apoorv Khurasia
nguồn

1

Tại sao bạn không thể thay đổi nguồn thành thư viện của bên thứ ba? Bạn có nó, tôi giả sử? (Nếu không, đó là vấn đề thực sự bạn cần tập trung vào. Đừng bao giờ làm thế.)

— Mason Wheeler

3

@MasonWheeler Đáng buồn thay, chúng tôi thực sự không thể. Nó là một nhị phân được biên dịch (dll, .jar) mà chúng ta sử dụng. Thêm vào đó, có những cạm bẫy đối với cách tiếp cận đó khi chúng tôi có thể tắt mới nhất, bỏ lỡ hỗ trợ (điều rất quan trọng đối với chúng tôi), v.v.

— Apoorv Khurasia

4

@MasonWheeler: quyền truy cập vào mã nguồn của lib bên thứ ba là thứ bạn thường không có quyền tự do lựa chọn. Có rất nhiều libs nguồn đóng tại thị trường nơi không có sự thay thế nguồn mở hữu ích nào tồn tại.

— Doc Brown

Bạn có thể kế thừa các lớp trong thư viện của họ và thêm ghi đè vào các phương thức mà bạn không muốn chúng gọi là bị đánh dấu là lỗi thời không?

— CaffGeek

@DocBrown: Tôi không nói nguồn mở. Tôi nói nguồn có sẵn. Có rất nhiều thư viện độc quyền sẽ cung cấp cho bạn nguồn (theo giấy phép độc quyền) khi bạn mua nó. Chúng tôi có chính sách tại nơi làm việc để không bao giờ sử dụng bất kỳ thư viện bên thứ 3 nào mà không có nguồn và chúng tôi chưa bao giờ tìm thấy tình huống mà chúng tôi phải làm.

— Mason Wheeler

7

Sử dụng một công cụ như NDepend / JavaDepend , bạn có thể viết các truy vấn CQL tùy chỉnh để tạo cảnh báo cho các trường hợp rất cụ thể này.

Bạn đã nói trong câu hỏi mà bạn muốn IDE / Trình biên dịch cảnh báo cho các nhà phát triển. Tôi nghĩ bởi vì NDepend / JDepend tích hợp chặt chẽ với IDE, điều này có thể giải quyết vấn đề của bạn.

— MattDavey
nguồn

3

Đó là một cuộc gọi tốt. Và, bạn có thể dễ dàng thực hiện một lược đồ với NDepend (không bao giờ sử dụng JavaDepend) trong đó các cảnh báo / cảnh báo được đưa ra khi vi phạm các đăng ký hoặc ngay cả khi các đăng ký bị từ chối, tùy thuộc vào công cụ khác có liên quan (kiểm soát nguồn, xây dựng).

— Erik Dietrich

Điều này nghe có vẻ hứa hẹn. Tôi sẽ thử điều này vào ngày mai và cho bạn biết. Cảm ơn Matt.

— Apoorv Khurasia

Có vẻ như họ đã thay đổi tên sản phẩm của họ từ JavaDepend thành JArchitect, nhưng chương trình vẫn trông khá thú vị.

— Dalin Seivewright

4

"Cách tiếp cận danh sách trắng": viết thư viện trình bao bọc cho thư viện với các chữ ký giao diện về cơ bản giống như lib, nhưng bỏ qua các hàm bị cấm. Trình bao bọc nên ủy nhiệm mỗi lệnh gọi phương thức cho lệnh gọi thư viện tương ứng. Sau đó, hãy để các nhà phát triển của bạn chỉ sử dụng / liên kết đến trình bao bọc đó thay vì lib ban đầu. Trình bao bọc cũng có thể là một nơi tốt cho các phần mở rộng thư viện của bạn.

Ngược lại, điều đó có thể trở nên không thực tế nếu lib có API rất lớn với hàng trăm chức năng. Sau đó, bạn muốn thực hiện một "cách tiếp cận danh sách đen" như giải pháp "kiểm tra kiểu" mà bạn đề xuất.

— Bác sĩ Brown
nguồn

Vâng. Đó là một thư viện khổng lồ. Nhưng thậm chí tệ hơn, chúng tôi có rất nhiều thư viện như vậy (trên các dự án C #, Java). Tôi cũng đang nghĩ về một bài kiểm tra kiến tổng hợp bài.

— Apoorv Khurasia

2

Đây cũng là suy nghĩ đầu tiên của tôi, nhưng đọc câu hỏi của OP lần thứ hai, dường như anh ta đang tìm kiếm "cảnh báo" hơn là một kiến trúc hạn chế hơn. Tôi nghĩ rằng đây là một vấn đề của phân tích tĩnh nhiều hơn là viết nhiều mã hơn ...

— MattDavey

@MattDavey Đó là sự thật.

— Apoorv Khurasia

Có những chương trình wrapper-máy phát điện ( ví dụ , sourceforge.net/projects/wrappergen ) mà làm phần tẻ nhạt cho bạn. Sau đó, nó chỉ là một số phương pháp xóa hoặc -annotation để làm bằng tay.

— Ross Patterson

Các trình bao bọc @RossPatterson không chỉ là một khoản đầu tư vốn một lần. Họ có thể trở thành một cơn ác mộng duy trì trong một số trường hợp.

— Apoorv Khurasia

2

Một trong những sức mạnh với Reflection của Java là bạn có thể thay đổi các thuộc tính phương thức khi chạy. Một trong những cách sử dụng là làm cho một phương thức riêng tư thành công khai, để có thể sử dụng nó bằng mọi cách. Nó có thể hoạt động rất tốt theo cách khác, với việc bạn đặt các phương thức không mong muốn ở chế độ chạy. Mặc dù nó sẽ không được nhìn thấy trong quá trình biên dịch, nó sẽ được nhìn thấy ngay khi dự án được thử nghiệm.

Bài viết này cho thấy làm thế nào để sửa đổi các thuộc tính phương thức trong thời gian chạy. Đây là phần thú vị:

Class theClass = MyClass.class;
Class[] paramTypes = { Integer.TYPE, String.class };
Method method = theClass.getDeclaredMethod("myMethodName", paramTypes);
method.setAccessible(false); // this makes the metod private
System.out.println("Making method  myMethodName(int,String) private");

— XGouchet
nguồn

1

Cảm ơn. Tôi sẽ thử giải pháp MattDavey trước vì nó cho phép tôi thực hiện phân tích tĩnh. Điều đó nói rằng, nếu tất cả các phương pháp tĩnh đều thất bại, tôi sẽ thử giải pháp của bạn.

— Apoorv Khurasia

1

Điều đó sẽ không hoạt động tôi nghĩ. Đối với mã được biên dịch, lần cuối cùng các quy tắc hiển thị được kiểm tra là tại thời điểm tải, khi mã byte được xác minh. Những thay đổi sau đó khi sử dụng API phản chiếu sẽ chỉ ảnh hưởng đến các cuộc gọi phản chiếu khác.

— Stephen C

0

Chúng tôi muốn các nhà phát triển nhớ rằng việc sử dụng các phương pháp đó không được khuyến nghị cho dự án này.

Vì bạn đã phải tạo phương pháp thay thế trong một số trường hợp. Tôi sẽ tạo một lớp bao bọc cho toàn bộ thư viện và chỉ sử dụng lớp bao bọc của bạn.

Nếu thư viện được cập nhật, bạn sẽ phải cập nhật mã của mình. Lớp bao bọc đủ dễ dàng để cập nhật.

Mặc dù vậy, nó tránh cho các nhà phát triển sử dụng sai phương thức .... Tôi dám nói rằng một nhà phát triển sẽ có thể nhớ những phương thức mà anh ta không cho là sử dụng.

— Ramhound
nguồn

3

không, thật không hợp lý khi mong đợi một nhà phát triển nhớ rằng anh ta chỉ "không nên sử dụng" các phương pháp logic hoàn hảo trong thư viện mà anh ta đang sử dụng. Một hoặc hai, có lẽ, nhưng như một quy luật chung, con người đơn giản là không thể nhớ loại đó một cách đáng tin cậy. Heck, phi công được đào tạo chuyên sâu và có động lực tuyệt đối không thể tin tưởng để nhớ tất cả các chi tiết về việc đưa máy bay lên mặt đất an toàn - đó là lý do tại sao có danh sách kiểm tra buồng lái!

— Michael Kohne

Đó chính xác là những gì tôi muốn. Sử dụng chức năng đó và IDE tạo cảnh báo.

— Apoorv Khurasia

@MichaelKohne - Khi tôi gặp vấn đề tương tự như tác giả, tôi không gặp vấn đề gì khi nhớ những phương pháp nào tôi nên sử dụng. Thư viện trong câu hỏi dễ dàng 100 phương pháp khác nhau.

— Ramhound