코드 오버레이, Java 디버거 API 및 DDJT 완전 통합 구축 - 3일

어제와 지금 나는 두 번째 공관에 있다.
우리는 거의 하나open source project가 있다.기술적으로 말하자면, 우리는 이미 원본 코드와 몇 줄의 코드를 가지고 있지만, 그것은 여전히 완전한 '프로젝트'가 아니다.그것은 쓸모 있는 일을 해야 하는 것이 아니다.그러나 단원 테스트를 컴파일하고 실행하며 80%의 코드 커버율까지 가지고 있다.마지막으로 많이 아팠어.나는 코드의 질을 임의의 표준으로 평가하는 것을 좋아하지 않는다.80퍼센트의 코드 커버율이 좋은 예이다.
예를 들어 이 코드.현재 소스 코드는 다음과 같습니다.

MonitoredSession monitoredSession = connectSession.create(System.getProperty("java.home"), "-Dhello=true", HelloWorld.class.getName(), "*");

그러나 처음에는 다음과 같이 보였다.

MonitoredSession monitoredSession = connectSession.create(null, null, HelloWorld.class.getName(),null);

이 옵션을 변경하면 코드 덮어쓰기율이 현저히 증가합니다. 코드를 작성하는 과정에서 비공식 변수에 대해 특별한 조건이 있기 때문입니다.좋은 테스트 커버율을 얻기 위해서, 나는null 상황을 테스트하고 싶지만, 이것은 테스트 커버율에 영향을 주지 않을 것이다.코드 덮어쓰기 도구의 요구를 충족시키기 위한 것이 아니라는 것은 명백하다.그러나 만약 우리가 이러한 지표를 코드의 질과 신뢰성의 기준으로 의존한다면우리는 마땅히 멈춰야 한다.
이런 방법의 또 다른 문제는 마지막 10-20%의 코드 커버율을 80%의 요구를 통과시키려면 대량의 작업을 해야 한다는 것이다.이거 너무 어려워요.만약 당신이 100% 코드 커버율이 필요한 프로젝트에서 일한다면, 나는 당신에게 애도를 표할 것입니다.나는 임의의 백분율의 코드 커버율이 문제가 있는 지표라고 생각한다.나는 이 성명을 더욱 좋아하지만, 그들은 여전히 비슷한 문제에 직면해 있다.
좋은 점은 코드 커버율 보고서를 좋아한다는 것이다.나는 이것이 나로 하여금 프로젝트의 현황에 대해 좀 이해하게 하고 이 모든 것을 이해하는데 도움이 된다고 생각한다.그런 의미에서 소나운은 매우 좋다.
날카로운 코드 관찰자는 내가 유니버설 코드에 어떤 내용도 추가하지 않았다는 것을 알아차릴 것이다.현재 그것은 상업 논리가 거의 없고, 사실 나는 곧 다가올 홍보에서 이 코드를 삭제했다.

작문 시험

나는 테스트와 시뮬레이션을 작성하는 데 많은 시간을 들였는데, 이것은 시뮬레이션 단원 테스트를 만드는 도구를 구축하기 위해 좋은 준비를 했다.따라서 두 번째 목표는 코드 커버율 보고서를 바탕으로 테스트를 생성하는 것이라고 생각합니다.그 어느 때보다 재미있다.나는 통계 데이터를 쉽게 조정할 수 있는지 없는지를 보기 위해 코드를 수정하고 싶었다.
테스트에서 나는 매우 고통스러운 일이 오류 로그 파일이라는 것을 발견했다.개인적으로, 나는 왜 Maven tests target이 기본적으로 테스트 중인 줄을 가리키는 창고 추적을 표시하는지 모르겠다. 완전한 창고 추적이 아니라.IntelliJ/IDEA는 이 분야에서 개선되었으나 여전히 이상적이지 않다.특히 CI 로그를 정리할 때
현재, 나의 모든 테스트는 단원 테스트이다. 왜냐하면 나는 아직 완전히 집적되지 않았기 때문이다.하지만 이런 상황은 곧 바뀔 것이다.응용 프로그램의 초기 버전에 웹 전단이 없기 때문에 통합 테스트를 어떤 형식으로 할지 아직 확실하지 않습니다.CLI를 아직 테스트하지 않았습니다.
내가 이 코드를 쓰기 시작했을 때, 나는 약간 모순되었다.앞서 언급한 바와 같이 자바 디버그 API를 Spring Boot 백엔드에 통합하는 것은 나에게 매우 큰 방향 전환이다.그러나 이것은 일리가 있어 많은 문제를 해결했다.나의 주요 논쟁점은 다른 언어/플랫폼을 지원하는 것이다.그러나 나는 그것들을 추가할 때 각자의 플랫폼 본체 디버깅 API와 통합할 수 있기를 바란다.이렇게 하면 다른 플랫폼의 디버깅 프로세스가 Java 디버깅 세션과 유사하게 진행됩니다.다른 플랫폼에 지원을 주입하기 위해 모듈화된 방식으로 코드를 작성해 보겠습니다.
python, node 등의 프로그램이 Javase와 유사한 JDI 기능을 허용할 것이라고 확신합니다.따라서 코드가 모듈화되면 지원되는 모든 플랫폼과 일치하는 패키지를 추가할 수 있습니다.적어도 이것은 현재의 계획이다.만약 이것이 작동하지 않는다면, 우리는 이 플랫폼을 재구성하거나, 단지 이 플랫폼에 프록시 옵션을 추가할 수 있다.우리의 요구는 상대적으로 간단합니다. 표현식 값을 구할 필요가 없습니다. 현재 창고 프레임 데이터와 간단한 단계별 결과만 필요합니다.
디버거 세션을 사용할 생각을 했을 때, 나는 모든 방법에 단점을 설정할 생각을 했다.이것은 분명히 문제가 있다. 왜냐하면 우리가 설정할 수 있는 단점의 수량에 제한이 있기 때문이다.반대로, 나는 프로그램 추적을 위해 방법 항목을 리셋했다.모든 방법에서 나는 '스텝' 을 사용하여 그 중의 요소를 볼 것이다.아직 실현되지 않은 것은 단원 테스트를 통과하기 어려웠기 때문이다.
디버거 세션을 일시 중지하고 CLI로 이동하는 이유입니다.나는 실제 제품으로 이 기능을 시험해 보고 싶다.

웹 서비스를 통한 CLI 통합

나는 CLI 프로젝트를 만들고 의존 항목을 정의했지만, 아직까지 CLI 코드를 제대로 작성하지 못했다.CLI는 REST를 통해 백엔드 코드와 통신할 예정입니다.처음에는 아주 좋은 스웨거(오픈 API)를 사용하고 싶었다.만약 그것에 익숙하지 않다면, 기본적으로 당신이 필요로 하는 모든 네트워크에 문서나 응용 프로그램 코드를 생성할 것입니다.당신의 API만 검사하면 됩니다!
그것은 때때로 지루하고 직관성이 부족한 대량의 샘플 파일을 생성했다.그것 또한 일부 코드의 재사용을 막았다.만약 내가 광범위한 프로젝트나 대중을 위한 API를 가지고 있다면, 나는 그것을 사용할 수 있다.그러나 내부에서 사용하는 물건에 대해서는 과도한 사용인 것 같다.그래서 나는 결국 과거에 사용했던 Gson과 새로운Java 11 HttpClient API를 사용했다.이 API는 아주 쓰기 좋다.

지나치게 갈망하는 피콜리

나는 정말 PicoCLI를 좋아한다. 만약 너look at this source file라면 왜 그런지 쉽게 알 수 있을 거라고 생각한다.이것은 명령행 작성 프로그램을 보잘것없게 만들었다.하이라이트 디스플레이, 완료, 스마트 그룹 구성 등을 포함한 멋진 CLI API를 얻을 수 있습니다.그것은GraalVM으로 쉽게 컴파일할 수 있도록 하는 예비 프로세서까지 있다.
불행하게도, 나는 Pico CLI가 너무 똑똑할 수도 있는 용례를 만났다.
원래 설계는 다음과 같은 명령을 제공합니다.

java -jar ddtj.jar -run [-javahome:<path-to-java-home] [-whitelist:regex-whitelist classes] [-arg=<app argument>...] mainClass

-arg는 기본적으로 대상 JVM에 전달하려는 모든 매개 변수를 가져올 수 있도록 합니다.예를 들어, 환경 변수를 JVM에 전달하려면 다음과 같이 하십시오.

-arg "-Denv=x"

문제는 PicoCLI가 -D를 다른 매개변수로 인식하고 확인을 시도하는 것입니다.나는 이 점을 해내려고 많은 시간을 들였다.나는 피콜리가 불가능하다고 생각했지만, 나는 뭔가를 놓쳤을 수도 있다.문제는 PicoCLI 파라미터로 모든 JVM 파라미터를 복제하고 싶지 않다는 것이다. 예를 들어 클래스 경로 파라미터 등이다. 불행하게도 이것은 내가 지금 볼 수 있는 유일한 옵션이다.
MVP가 시작되면 이 방법을 다시 고려해야 하지만 이제 CLI 사양을 다음과 같이 변경합니다.

java -jar ddtj.jar -run mainClass [-javahome:<path-to-java-home] [-whitelist:regex-whitelist classes] [-classpath...] [-jar...] 

실제로 다음은 PicoCLI에 전달되는 help 명령이 코드를 생성하는 내용입니다.

공공 구역을 완전히 재분할하였다

내가 이 공공 프로젝트를 실현할 때, 나는 추측에 근거하여 실현한 것이다.이것은 완전히 잘못된 것이다.모든 원본 파일을 최초의 실행에서 백엔드 프로젝트로 옮겨야 합니다.그리고 나서 나는 유니버설 코드의 종류를 다시 실현해야만 했다.
인터넷 인터페이스가 원인이다.이것은 내가 클라이언트 컴퓨터로 이동해야 하는 데이터가 아니라 데이터 모델을 같은 곳에 두었다는 것을 깨달았다. (후자는 훨씬 작다.)
웹 인터페이스를 실현하는 것은 매우 간단하다.나는 단지 문서에 열거된 명령을 훑어보았을 뿐, 명령마다 웹 서비스 방법을 추가했다.그런 다음 각 객체에 DTO(데이터 전송 객체)를 추가합니다.DTO는 모두 공공 프로젝트에 있습니다. 이것이 바로 DTO가 어떤 모습이어야 하는지입니다.
처음에, 나는 웹 서비스rest 클래스에서 모든 논리를 작성하기만 하면 된다고 생각했지만, 결국 나는 논리를 일반적인 서비스 클래스로 분리했다.나는 service class 에서 통용 논리를 사용할 수 있도록 장래에 웹 UI를 추가하고 싶다.

처리 상태

이런 유형의 응용에 대해 주 정부는 어려운 선택이다.나는 데이터베이스를 원하지 않는다. 모든 것이 메모리에 있다.그래도 세션 관리를 사용합니까?
만약 우리가 백엔드에서 여러 개의 응용 프로그램을 실행한다면?
그래서 지금 MVP에서 이 문제를 해결했습니다.만약 여러 프로그램을 실행한다면, 그것은 실패할 것이다.나는 단지 세션 대상의 로컬 필드에 데이터를 저장할 뿐이다.스프링은 기본적으로 세션 bean의 단일 예이고 집단과 관련이 없기 때문에 정적 변수를 필요로 하지 않습니다.
MVP 이후에는 여러 애플리케이션의 실행을 고려해야 합니다.이 경우 사용 중인 애플리케이션을 확인하기 위해 CLI를 변경해야 할 수 있습니다.나는 우리가 여전히 필드에서 상태를 보존할 것이라고 생각하지만, RAM의 사용을 줄이기 위해 상태를 갱신할 방법이 있어야 한다.

Snyk 통합

어제 스니크랑 문제가 좀 있었어요.만약 당신이 그것에 익숙하지 않다면, 그것은 코드의 빈틈을 스캔하고 빈틈을 복구하는 데 도움을 줄 수 있는 도구이다.멋있어.집적은 매우 쉬워서 나는 이것에 대해 매우 만족한다.그리고 나는 이 항목에 휘장을 달아 보았다...
분명히 Snyk 배지와 모노 환매 협의는 일치하지 않는다.그들은pom 파일이 프로젝트의 맨 위에 있기를 희망한다.그래서 나는 휘장을 포기했다.스캔에 성공했기 때문에 나는 휘장이 실패할 것이라고 매우 이상하게 생각한다.
나는 이 문제를 감시하고 해결 방안이 있는지 없는지를 보려고 한다.나는 그들의 지지 아래 이 문제를 토론했는데, 그들의 반응은 상당히 적극적이었지만, 그럴듯한 답이 하나도 없는 것 같다.
정말 유감스럽게도 나는 휘장으로 프로젝트의 안전 상태를 검증하는 것을 좋아한다.

내일/내일

바쁜 하루였지만 결국 비효율적으로 느껴졌다. CLI에 모든 시간을 낭비하고 스니크 배지 같은 것이 역할을 발휘하도록 노력했기 때문이다.이것은 사람을 지겹게 하는 일이다.MVP를 할 때는 반드시 지름길을 찾아야 한다. 만약 네가 할 수 없다면 지금 삭제해라.나중에 얘기하자.
내일 나는 현재 PR이 기능 덮어쓰기 표준에 도달하고 명령행 API에서 연결을 시작하여 실제 환경에서 디버깅 프로그램을 디버깅하기 시작하기를 희망한다.주석된 코드 세션과 냄새를 개선해야 할 부분도 있다.