Заборонити виклики до довільних функцій / класів у зовнішньому коді

У мене були випадки, коли було б корисно обмежити доступ до API зовнішніх бібліотек та фреймворків, щоб запобігти негативним наслідкам у системі.

Наприклад, у програмі SharePoint може здатися закликом spList.Items.GetItemByIdотримати елемент списку, навіть можливо, в циклі, не розуміючи, що це може призвести до величезних проблем з продуктивністю.

Можливо також, що нам потрібно заборонити використання SmtpClient, щоб змусити всіх використовувати наш власний клас для надсилання електронної пошти, щоб переконатися, що ми можемо належним чином проксі та знущатися над усіма повідомленнями електронної пошти під час тестування.

Чи є якісь надійні та досить прості способи досягнення цих обмежень щодо зовнішнього коду, за винятком певних конкретних місць у нашому власному коді? Не потрібно абсолютно за будь-яких обставин перешкоджати доступу до цих методів / класів, наприклад, за допомогою роздумів або просто вимкнення, це повинно бути строгим попередженням про те, що вони не повинні використовуватися. Переважно змушуючи програміста активно вживати заходів для усунення цих обмежень, якщо це можливо / необхідно.

Чи є якісь надійні та досить прості способи досягнення цих обмежень щодо зовнішнього коду, за винятком певних конкретних місць у нашому власному коді?

Оскільки питання стосується конкретно C #, існує рішення, засноване на компіляторі, яке можна використовувати тут для забезпечення таких правил: Roslyn Analyzers . Ви можете написати власний аналізатор, який повідомляє про доступ до певних API як помилку компіляції або попередження.

Прикладним набором аналізаторів, які надають безліч прикладних кодів для написання власного запису, є аналізатори StyleCop , які є заміною старої функції StyleCop для C #.

Сказавши це, такі автоматизовані перевірки завжди можуть обійти люди, налаштовані на "порушення правил". Тому такий підхід не є заміною для оглядів коду, про які йшлося у відповіді Карла Білефельдта. Він може допомогти в таких оглядах, але не повинен їх замінювати.

Ви можете зайняти багато часу, такі як написання обгортки навколо зовнішнього API, що не залишає ваших небажаних операцій, але нічого не перевершує навчання та огляд коду, адже які б стандарти або технічні заходи ви не застосовували, люди знайдуть творчі способи їх обійти. .

Наприклад, у нас є кілька сервісів, написаних у Scala, і одна з речей, яку ми запитуємо під час перегляду коду, - це незмінність, але ми часто повідомляємо про це як про позбавлення від vars. Хтось днями використав val x: ListBuffer [Boolean], щоб утримувати одну змінну змінну як єдиний елемент у списку. Ви не можете призначити інше ListBufferна x, але ви можете замінити елементи списку на місце скільки завгодно. Так само погано, як і використання var, але примхливіше.

Іншими словами, ви повинні перевірити, чи люди обходять ваші технічні рішення. Якщо ці технічні рішення дорогі і додають складності, ви можете просто перевірити, чи правильно вони кодують.

Відповідь Карла на 100% правильна. Немає способу гарантувати відповідність. Однак, крім навчання та огляду коду, врахуйте використання інструментів статичного аналізу для забезпечення відповідності. (Примітка. Я сказав "на додаток до", оскільки можна також обійти їх точно так само, як заявив Карл).

Перевага в застосуванні інструментів статичного аналізу полягає в тому, щоб вилучити виснажливий аналіз коду людини, шукаючи випадки "багаторазового використання IEnumerable" або будь-якого питання ефективності тижня, на який ви дивитесь (або, принаймні, що я завжди відчуваю, що я дивлячись на). Це дозволить переглядати коди та навчатись зосереджуватися на більш "цікавих" питаннях.

Для C #, зокрема, я включив кілька пропозицій нижче. Підключіть їх до свого будівельного середовища, і ви готові йти. Але, як правило, незалежно від того, якою мовою ви користуєтесь, десь є інструмент статичного аналізу.

Скопіюйте / вставте прямо зі сторінки Вікіпедії, використовуйте сторінку wiki для найсвіжішої інформації та посилань: https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET

• Платформа компілятора .NET (кодове ім'я Рослін) - структура компілятора з відкритим кодом для C # і Visual Basic .NET, розроблена Microsoft .NET. Надає API для аналізу та маніпулювання синтаксисом.
• CodeIt.Right - поєднує статичний аналіз коду та автоматичний рефакторинг з найкращими методами, що дозволяє автоматично виправляти помилки та порушення коду; підтримує C # і VB.NET.
• CodeRush - плагін для Visual Studio, який попереджає користувачів про порушення кращих практик.
• FxCop - безкоштовний статичний аналіз для програм Microsoft .NET, який компілюється в CIL. Автономна та інтегрована в деякі видання Microsoft Visual Studio; від Microsoft.
• NDepend - спрощує управління складною базою коду .NET шляхом аналізу та візуалізації кодових залежностей, шляхом визначення правил проектування, аналізу впливу та порівняння різних версій коду. Інтегрується у Visual Studio.
• Parasoft dotTEST - статичний аналіз, модульне тестування та плагін для перегляду коду для Visual Studio; працює з мовами для Microsoft .NET Framework та .NET Compact Framework, включаючи C #, VB.NET, ASP.NET та керований C ++.
• Sonargraph - Підтримує C #, Java та C / C ++ з акцентом на аналізі залежностей, автоматизованій перевірці архітектури, метриках та можливості додавати спеціальні метрики та перевірки коду.
• StyleCop - аналізує вихідний код C # для забезпечення набору правил стилю та послідовності. Його можна запустити зсередини Microsoft Visual Studio або інтегрувати в проект MSBuild.

Щоб детальніше ознайомитись із пропозицією "навчання та перегляд коду", викладеною в іншій відповіді: оскільки код, який ви хочете заборонити, є юридичним кодом, ви не можете розраховувати на те, що компілятор запобігає цьому, і вам доведеться розраховувати на більш пізній процес, огляд.

Це може (і повинно) включати як ручний, так і автоматичний етапи огляду:

• Підготуйте контрольний список відомих проблем та перегляньте їх у ручному огляді коду, по одному. Проведіть повторювані зустрічі, щоб переглянути та оновити контрольний список. Щоразу, коли буде виявлена ​​та проаналізована неприємна помилка, додайте її до контрольного списку.

• Додайте правила реєстрації, щоб шукати відомі зразки. Це може бути складно написати, але для великого проекту з часом може бути корисним. TFS дозволяє писати правила в C #, а інші системи побудови мають власні гачки. Подумайте про використання вбудованих систем для відхилення реєстрацій, які відповідають шаблону. Так, це уповільнює розвиток, але після певного розміру та складності проекту, уповільнення динаміків може стати хорошою справою.

Можливо, компілятор може допомогти вам зловити небажані дзвінки.

Перейменуйте класи / методи коду у власній lib, які не повинні використовувати зовнішні клієнти lib. Альтернативно зробіть класи / методи внутрішніми і додайте внутрішні видимі до тих класів, яким дозволено їх використовувати.

Зовнішні користувачі lib отримають метод / клас помилки компіляції, який не знайдено.

Заборонені класи / методи з публічних бібліотек: створіть у вашій власній області те саме простір імен / клас / метод

Зовнішні користувачі lib отримають помилку компіляції через знайдений дублікат класу

[оновлення]

Не потрібно абсолютно за будь-яких обставин перешкоджати доступу до цих методів / класів, наприклад, шляхом рефлексії або просто якихось відключень,….

змушуючи програміста (... клієнта ліб ...) активно вживати заходів для усунення цих обмежень, якщо це можливо / необхідно.