Лучший способ использовать данные между сервером и угловым клиентом?

Question

Мы разрабатываем веб-приложение с использованием C# и Angular.

Клиент и сервер связывают JSON с отправкой данных.

Моя проблема в качестве стороннего разработчика: когда они меняют имя переменной модели, клиент больше не работает.

Пример: если модель:

public class Person 
{ 
    public string name; 
} 

В угловом приложении я использую exaclty ту же самую структуру, когда я получить JSON:

<h1>{{myJson.name}}</h1> 

, а иногда и фоновым разработчики изменить имя переменной, мне нужно вернуться, чтобы обновить клиентскую сторону, и я теряю большое время в отладке с этим.

Любое учебное пособие или блог или что-то знать, что является лучшим способом использования данных между сервером и клиентом?

Большое спасибо!

Answer 1

Если внешняя форма/поведение кода изменяется, то любой код, который его использует, также должен изменяться. Это определение «разрыва».

Я подозреваю, что идеальным способом избежать этой проблемы является набор автоматических тестов, которые проверяют код. Если кто-то совершит перерыв, тесты потерпят неудачу. В этот момент сборка считается «сломанной».

Если возможно, возможно, стоит реализовать какую-то систему «регистрации отказа», в которой исходный элемент управления не позволяет регистрировать сборку, которая не может скомпилировать или не выполнить тесты. Это встроенная функциональность в TFS, но она не может быть приемлемой для многих систем.

Несоблюдение этого технического барьера в этот момент является в значительной степени препятствием для команды. Кто-то ломает сборку, они несут ответственность за ее исправление. Конечно, иногда этот человек ушел на день или, возможно, есть еще одна причина, по которой вам или другому члену команды нужно «очистить после них», но из истории управления версиями должно быть ясно, что они сломали сборку.

Если вы тратите много времени на то, как другие разработчики сломались, это проблема технической проблемы и проблемы с командной динамикой. Автоматические тесты придают видимость этой проблеме. Разработчики не должны иметь возможность проверять код с провальными тестами, будь то технический барьер или социальный.