javascript_basic 지식 디버깅에 대한 간략한 토론

최근에 우리 모두가 알고 있듯이 웹 프론트엔드가 몇 년 전에 비해 매우 무거워졌고, 다양한 js 프레임워크도 있고, 프로젝트가 너무 많아지면 public도 많아졌습니다. 모듈이 추출됩니다.

이러한 모듈의 UI 표시는 동일하며 차이점은 배경 로직입니다. 예를 들어 기업 여행을 할 때 일반적으로 고객이 항공권을 예약할 때 작성하는 비용 센터에 대한 js 공개 모듈이 있습니다. 이 코스트 센터는 온라인, 오프라인, 앱 예약 단말기에 분산되어 있어 향후 고객사와 월별 정산도 용이하게 됩니다.

프로젝트가 커지고 복잡해지며 SOA가 되면서 많은 문제가 발생한다는 것도 알고 있습니다. 웹의 이론처럼 프론트엔드의 모든 데이터는 신뢰할 수 없기 때문에 다른 팀의 데이터는 신뢰할 수 없습니다. 예전에는 프로젝트 규모가 작았을 때는 그다지 자신감이 없었고, 로직 오류가 있을 때만 로그를 기록했는데, 결국에는 정보 로그가 보기에도 좋지 않았습니다. 또한 서버 대역폭을 소비하면 웹 성능도 저하됩니다.

그런데 프로젝트가 점점 커지다 어느 날 프로젝트에서 이상한 버그를 발견하면 불완전한 로그에 의존하여 마침내 육안으로 인터페이스를 한 줄씩 추적하게 됩니다. 매개변수 데이터를 정확하게 복원할 수 없지만 인터페이스 반환 문제임에 틀림없다고 확신하지만 현재로서는 인터페이스 공급자를 찾을 수 없습니다. , 당신은 무력했습니다. 매번 생각하는 것이 좋습니다.

교훈을 얻은 후 프로세스 로그를 유지하는 경향이 점점 더 대중화되었고 결국 웹 백엔드에 대해 많은 이야기가 나왔습니다. 그렇다면 현재 프런트 엔드는 동일해야 합니다. 로그를 유지하시겠습니까? 우리는 공개 js 모듈이기 때문에 이 모듈이 일부 메서드를 캡슐화했음이 틀림없다는 것을 알고 있습니다. 다음과 같은 타사 프로그램이 자체 텍스트 노드를 작동하는 것은 확실히 허용되지 않습니다.