Melarang panggilan ke fungsi / kelas yang berubah-ubah dalam kode eksternal

Saya pernah mengalami kasus di mana akan sangat berharga untuk membatasi akses ke API perpustakaan eksternal dan kerangka kerja untuk mencegah konsekuensi negatif dalam sistem.

Misalnya, dalam aplikasi SharePoint, mungkin terasa wajar untuk menelepon spList.Items.GetItemById untuk mendapatkan item daftar, bahkan mungkin dalam satu lingkaran, tanpa menyadari bahwa ini dapat menyebabkan masalah kinerja yang sangat besar.

Bisa juga kita perlu melarang penggunaan SmtpClient untuk memaksa semua orang menggunakan kelas kita sendiri untuk mengirim email, untuk memastikan bahwa kita dapat dengan benar mem-proxy dan mengejek semua email saat berada di lingkungan pengujian.

Adakah cara yang andal dan cukup mudah untuk mencapai kendala-kendala ini pada kode eksternal, kecuali dari tempat tertentu tertentu dalam kode kita sendiri? Tidak perlu benar-benar dalam setiap keadaan mencegah akses ke metode / kelas ini, misalnya dengan refleksi atau hanya semacam penonaktifan, itu harus menjadi peringatan keras bahwa mereka tidak boleh digunakan. Lebih disukai memaksa programmer untuk secara aktif mengambil tindakan untuk mengatasi kendala ini jika memungkinkan / diperlukan.

Adakah cara yang andal dan cukup mudah untuk mencapai kendala-kendala ini pada kode eksternal, kecuali dari tempat tertentu tertentu dalam kode kita sendiri?

Karena pertanyaannya secara khusus tentang C #, ada solusi berbasis kompiler yang dapat digunakan di sini untuk menegakkan aturan seperti itu: Roslyn Analyzers . Anda bisa menulis analisis Anda sendiri yang melaporkan mengakses API tertentu sebagai kesalahan kompilasi atau peringatan.

Satu set contoh alat analisis, yang menyediakan banyak kode contoh untuk menulis milik Anda sendiri, adalah StyleCop Analyzers , yang merupakan pengganti fitur StyleCop lama untuk C #.

Karena itu, pemeriksaan otomatis semacam itu selalu dapat diselesaikan oleh orang-orang yang bertekad untuk "melanggar aturan". Oleh karena itu pendekatan ini bukan pengganti untuk tinjauan kode seperti yang dibahas dalam jawaban Karl Bielefeldt. Itu dapat membantu dengan ulasan semacam itu, tetapi sebaiknya tidak menggantinya.

Anda dapat melakukan hal-hal yang menghabiskan waktu seperti menulis bungkus di sekitar API eksternal yang meninggalkan operasi yang tidak diinginkan, tetapi tidak ada yang mengalahkan pelatihan dan ulasan kode, karena apa pun standar atau tindakan teknis yang Anda lakukan, orang akan menemukan cara kreatif untuk mengatasinya .

Sebagai contoh, kami memiliki beberapa layanan yang ditulis dalam Scala, dan salah satu hal yang kami tanyakan pada saat tinjauan kode adalah untuk ketidakberdayaan, tetapi kami sering mengomunikasikannya sebagai menyingkirkan vars. Beberapa hari yang lalu menggunakan val x: ListBuffer [Boolean] untuk memegang variabel tunggal yang dapat berubah sebagai satu-satunya item dalam daftar. Anda tidak dapat menugaskan orang lain ListBufferuntuk x, tetapi Anda dapat mengganti item daftar di tempat sebanyak yang Anda inginkan. Seburuk menggunakanvar , tetapi sneakier.

Dengan kata lain, Anda harus memeriksa apakah orang mencari solusi teknis Anda. Jika solusi teknis itu mahal dan menambah kerumitan, Anda sebaiknya mengeceknya dengan benar.

Jawaban Karl adalah 100% benar. Tidak ada cara untuk menjamin kesesuaian. Namun, selain pelatihan dan ulasan kode, pertimbangkan penggunaan alat analisis statis untuk memastikan kepatuhan. (Catatan: Saya mengatakan "selain", karena orang dapat mem-bypass mereka juga dengan cara yang persis sama seperti yang dinyatakan Karl).

Keuntungan menggunakan alat analisis statis adalah menghilangkan analisis kode manusia yang membosankan, mencari contoh "beberapa penggunaan IEnumerable" atau masalah kinerja apa pun dalam minggu yang Anda lihat (atau, setidaknya, yang selalu saya rasakan. melihat ke). Ini akan memungkinkan ulasan kode dan pelatihan untuk fokus pada masalah yang lebih "menarik".

Untuk C #, khususnya, saya telah memasukkan beberapa saran di bawah ini. Tancapkan ini ke lingkungan build Anda dan Anda siap melakukannya. Tetapi, secara umum, tidak peduli bahasa apa yang Anda gunakan, ada alat analisis statis di luar sana.

Salin / tempel langsung dari halaman Wikipedia, gunakan halaman wiki untuk informasi dan tautan terbaru: https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET

• .NET Compiler Platform (Codename Roslyn) - Kerangka kerja sumber terbuka untuk C # dan Visual Basic .NET yang dikembangkan oleh Microsoft .NET. Menyediakan API untuk menganalisis dan memanipulasi sintaks.
• CodeIt.Right - Menggabungkan analisis kode statis dan refactoring otomatis ke praktik terbaik yang memungkinkan koreksi otomatis kesalahan dan pelanggaran kode; mendukung C # dan VB.NET.
• CodeRush - Plugin untuk Visual Studio yang memperingatkan pengguna untuk pelanggaran praktik terbaik.
• FxCop - Analisis statis gratis untuk program Microsoft .NET yang mengkompilasi ke CIL. Standalone dan terintegrasi dalam beberapa edisi Microsoft Visual Studio; oleh Microsoft.
• NDepend - Menyederhanakan pengelolaan basis kode .NET yang kompleks dengan menganalisis dan memvisualisasikan dependensi kode, dengan menetapkan aturan desain, dengan melakukan analisis dampak, dan dengan membandingkan berbagai versi kode. Terintegrasi ke dalam Visual Studio.
• Parasoft dotTEST - Analisis statis, pengujian unit, dan plugin peninjauan kode untuk Visual Studio; bekerja dengan bahasa untuk Microsoft .NET Framework dan .NET Compact Framework, termasuk C #, VB.NET, ASP.NET dan Managed C ++.
• Sonargraph - Mendukung C #, Java dan C / C ++ dengan fokus pada analisis ketergantungan, pemeriksaan arsitektur otomatis, metrik dan kemampuan untuk menambahkan metrik khusus dan pemeriksa kode.
• StyleCop - Menganalisa kode sumber C # untuk menegakkan serangkaian aturan gaya dan konsistensi. Itu dapat dijalankan dari dalam Microsoft Visual Studio atau diintegrasikan ke dalam proyek MSBuild.

Untuk menguraikan saran "pelatihan dan tinjauan kode" yang diajukan dalam jawaban lain: karena kode yang ingin Anda larang adalah kode hukum, Anda tidak dapat mengandalkan kompilator yang mencegahnya, dan Anda harus mengandalkan proses selanjutnya, ulasan.

Ini dapat (dan harus) mencakup langkah-langkah tinjauan manual dan otomatis:

• Persiapkan daftar periksa masalah yang diketahui dan ulas ulasan kode manual Anda, satu per satu. Adakan pertemuan berulang untuk meninjau dan memperbarui daftar periksa. Setiap kali bug jahat ditangkap dan dianalisis, tambahkan ke daftar periksa.

• Tambahkan aturan check-in untuk mencari pola yang diketahui. Ini bisa rumit untuk ditulis, tetapi untuk proyek besar, dari waktu ke waktu, mungkin bermanfaat. TFS memungkinkan Anda untuk menulis aturan dalam C #, dan sistem build lain memiliki kaitannya sendiri. Pertimbangkan untuk menggunakan bangunan berpagar untuk menolak check-in yang sesuai dengan pola. Ya, ini memperlambat pengembangan, tetapi setelah ukuran dan kompleksitas proyek tertentu, memperlambat dev dapat menjadi hal yang baik.

Mungkin kompiler dapat membantu Anda menangkap panggilan yang tidak diinginkan.

Ganti nama kelas / metode kode di lib Anda sendiri yang tidak boleh digunakan oleh klien lib eksternal. Secara alternatif, buatlah kelas / metode internal dan tambahkan internal yang terlihat oleh kelas-kelas yang diizinkan menggunakannya.

Pengguna Lib eksternal akan mendapatkan metode / kelas kesalahan kompilasi tidak ditemukan.

Kelas / metode terlarang dari perpustakaan umum: buat namespace / kelas / metode yang sama di lib Anda

Pengguna lib eksternal akan mendapatkan kesalahan kompilasi karena ditemukan kelas duplikat

[memperbarui]

Tidak perlu benar-benar dalam setiap keadaan mencegah akses ke metode / kelas ini, misalnya dengan refleksi atau hanya semacam penonaktifan, ....

memaksa pemrogram (... klien lib ...) untuk secara aktif mengambil tindakan untuk mengatasi kendala ini jika memungkinkan / diperlukan.