build.gradle의 dependencies에 다음 코드를 추가해주고 reload 시켜주면
//JUnit4 추가
testImplementation("org.junit.vintage:junit-vintage-engine") {
exclude group: "org.hamcrest", module: "hamcrest-core"
}
import org.junit.runner.RunWith;import문이 잘 먹힌다. 해결!
참고로 junit5는 @RunWith(SpringRunner.class)이 아닌 @ExtendWith(SpringExtension.class)를 사용한다고 한다.
참고한 블로그
: https://velog.io/@hyeon030/Junit5-RunWithSpringRunner.class
팀장이나 스크럼마스터가 프로젝트 환경 설정 후 github에 올리면 나는 로컬에 가져와야 한다.
어떻게? git clone으로.
git bash 열어서 폴더 만들 위치에서
git clone <레포지토리 http 주소>
그리고 브랜치도 clone해오자
## 방법 1
checkout이 하나의 명령어 안에 여러 기능을 가지고 있어서 이제는 checkout을 사용하지 않는다고 한다.
이 방법은 지양하자.
git checkout -t origin/브랜치명
## 방법2
### switch로 브랜치 변경
git switch -c 브랜치명
-c 는 그 브랜치가 없으면 생성해달라는 명령어
### 원격 브랜치 pull 해오기
git pull origin 브랜치명
그 안에 파일들이 안보이면 reload해보면 뜬다.
아주 오랜만이다. 드디어 내가 수강하는 부트캠프에서도 final 프로젝트에 접어들었다.
[1주차 - 팀 빌딩 & 아이디어 회의 & 개발 환경 논의]
3주전 쯤 팀 구성을 하고 프로젝트 주제를 위한 아이디어 회의를 통해 1. 헬스 케어 2. 새로운 지역에서의 맛집 추천과 음식점 예약&웨이팅 3. 채용 사이트 등등 다양한 의견이 나왔고 팀원들과의 열띤 토론 끝에 기존 채용 사이트에서 불편한 점들을 개선한 웹사이트를 구현해보기로 했다. 개발 환경 및 스택은 intellij, gradle, Thymeleaf, bootstrap, mysql, spring Cloud, Docker, kubernates, AWS.. 로 정했다. 프론트에 큰 힘을 쏟고 싶지 않아서 react보다는 타임리프를 선택했고 DB는 가장 편한 mysql이나 maria를 사용하고 싶었다.
[2주차 - 화면 및 기능 설계]
아직 수업이 한 달 정도 남아있기 때문에 수업이 끝나고부터 센터가 닫는 9시반까지 매일 팀원들과 회의를 한 것 같다.
우리가 Client가 되어 어떤 화면이 필요하고 이 버튼을 클릭했을 때는 어떻게 넘어가고 어떤 데이터들이 불러와져야 한다. 지원자 입장에서는 지원한 공고마다 제출한 자소서나 이력서들을 확인 할 수 있으면 좋겠다. 면접 질문에 대해서도 관리할 수 있는 페이지가 있으면 좋겠다. 등등 서로 의견을 제시하면서 이건 아닌 것 같아요. 이게 더 낫지 않을까요. 그 의견 좋은거 같아요. 가감 없이 의견을 나누면서 필요한 기능과 페이지들을 설계했다. 회의를 하면서 간단간단하게 글로 적혀있어 구현할 때 화면이 있으면 좋겠다는 의견이 있었고 다들 동의해서 어떤 페이지에 어떤 데이터들이 어느 위치에 들어가야 한다 정도로만 잡아두자는 취지에서 figma를 이용해 화면 설계 및 디자인을 완료했다. 중간에 다들 과열되는 양상이 있었지만 곧 바로 다들 정신차리고 여기에 너무 힘을 쏟지 말자라고 의견이 정리되어 다행히 많은 시간을 소비하지 않았다.
[3주차 - ERD 설계 & MSA 프로젝트]
ERD 설계를 위해 서비스 별로 나누자는 의견이 나왔고 처음에는 서비스를 어떤 기준으로 나눠야 할 지도 애매하고 팀원들끼리도 이게 맞는 것 같다. 저게 맞는 것 같다. 얘기를 나누다 ERD 작성 전에 화면 설계한 것을 보면서 데이터들을 뽑아내서 엑셀에 정리하면서 이건 따로 테이블로 빼는 게 맞는 거 같다. 이건 너무 공통적으로 들어가는 데 이런건 하나의 테이블로 두는 게 나을 것 같다. 등등 의견이 나오면서 자연스레 데이터 타입, 속성까지 정리하게 되고 DB와 맵핑할 엔티티들도 함께 정리하게 되었고 그걸 바탕으로 팀원 중 한분이 맡아서 ERD 설계를 완성해주셨다. 참고로 ERD 설계 툴은 erdCloud를 사용했다. 팀원 중 한 분이 복사본을 지운다는 걸 최신 버전을 지워버려서 아찔할 뻔 했던 순간도 있었지만 다행히 우리 팀에는 인간 데이터베이스라고 불리우는 다른 한 분이 스냅샷을 찍어 두신 게 있어서 그걸 토대로 다같이 빠르게 복구시켰다. 그 뒤로는 권한에 대한 경각심이 생겨서 ERD, Github 다 권한을 제한하도록 했다. 이런 헤프닝이 프로젝트 초창기에 일어나서 너무 다행이였다. 오히려 가벼운 일을 통해 경각심을 갖게 되어 더 큰 사고를 방지할 수 있던 것 같다. 그리고 팀원들이 화면 디자인을 할 동안 ERD를 완성해주신 팀원분께서 엔티티와 sql문까지도 완성해주셨다.
> issue
간과한 것이 있었다. 지금까지 진행해온 프로젝트들은 다 모놀리스 방식이였다. MSA 방식으로 구현할 지 모놀리스 방식으로 구현할 지 논의가 되지 않았던 것이다. 아차차... 프로젝트의 근간을 흔들 수 있는 걸 이제야 깨닫게 된 것이다. 하지만 이 때까지만 해도 MSA에 대한 이해도 부족했고 도커도 얼마 배우지 않아 내부적으로는 이때라도 깨달은 게 다행이고 오히려 일찍 깨달은 것일 수도 있다고 판단했다. 아무튼 팀원들과 얘기를 해 본 결과 final 프로젝트이기도 하고 부트캠프 과정이 '대용량 서비스를 위한 MSA 엔지니어 양성 과정' 이니 만큼 MSA 방식으로 프로젝트를 진행하자는 쪽으로 의견이 좁혀졌고 ERD를 대폭 수정하게 되었다. FK로 얼기설기 꼬여있던 테이블들을 서비스를 기준으로 별로 분류하여 회원서비스, 주소 서비스, 관리자 서비스, 공고 서비스, 마이페이지 서비스, 지원서 서비스, 문의 서비스 이렇게 Micro service가 7개가 탄생하였다.
[4주차 - 멘토링&애자일도입]
해당 주차에는 API 명세를 작성하기로 하였고 API 명세서를 작성하는 방법에 대해 논의를 하고 있던 찰나 멘토님이 지정되었고 그 날 바로 연락이 와서 바로 미팅이 괜찮냐고 하셔서 멘토링을 다른 팀들보다 빠르게 시작하게 되었다.
+) 멘토님이 각자 자기소개 해달라고 하셔서 json 형태로 자기소개했다ㅋㅋ
첫 번째 멘토링에서 애자일에 대해 가르쳐주셨다. 그 전에 팀 회의에서도 애자일로 프로젝트를 진행하는 게 좋을 것 같다는 얘기가 나왔었지만 애자일에 대해 완벽히 이해하고 있던 팀원들은 없었다. waterfall과 애자일 방법론을 알려주셨고 설명을 듣고 나니 우리 프로젝트처럼 규모가 큰 프로젝트는 더욱이 필요하다고 생각했다. 메인 기능 개발을 위주로 sprint를 돌려가며 개발하고 우선순위가 후 순위인 기능들은 후반부 sprint에서 develop하면서 프로젝트를 진행하기로 하였다.
멘토링이 끝난 후 우리의 프로젝트에서 핵심 메인 기능은 유저가 공고를 지원하는 것이라고 정했고 첫 번째 sprint는 유저가 공고를 지원하기 위해 필요한 요소들로 잡았다. 그렇다면 자연스레 회원가입, 로그인, [기업] 공고 올리기, [유저]공고 목록보기, [유저] 공고 상세보기가 메인 기능으로 잡혀졌고 해당하는 뷰를 담당을 정해서 백로그를 작성 후 sprint planning meeting 을 진행하였다. 백로그 작성은 깃허브 project의 번트차트를 이용하였고 백로그 작성이 처음이다보니 헷갈리는 부분이 많았다. 처음에는 DOD 작성이나 스토리포인트를 어떻게 정해야 할 지가 막막했다. 하지만 하다보니 오히려 놓칠 뻔 했던 부분들을 다잡는 시간이 된 거 같다.
하고 멘토링 한 번 더 했고 API나 기능 구현에 대한 피드백을 받았고
DOD를 구현 방법까지 너무 디테일하게 들어가서 백로그 작성하는데 삽질했고
팀장님이 바로 잡았고 환경 세팅 후 개발 시작할 수 있게 되었다...
[지금 시점에서의 회고..]
팀원들이 다들 열정적인 분들이라 의견도 자유롭게 내고 다양한 의견들이 오가는 것 같다. 혼자 프로젝트를 할 때는 느낄 수 없었던.. 팀원들이 있어 가장 좋은 점은 삽질하지 않아도 된다는 점. 혼자 프로젝트를 진행할 때는 내가 생각하고 내가 결론을 내리니 잘못된 방향으로 가도 바로 잡아줄 사람이 없어 뒤늦게 깨닫는 경우들이 많은데 서로 지식 공유나 구현 방법에 대해서 얘기하다보면 바로 바로 피드백이 들어오기 때문에 시간이 단축된다는 점이 협업의 큰 메리트라고 생각한다. 또, 내가 생각한 설계, 구현 방법보다 더 효율적이고 좋은 아이디어가 넘친다는 것. 나 혼자 프로젝트를 했으면 비슷한 결과물 , 비슷한 코드가 구현되겠지만 다양한 의견이 오가면서 더 좋은 의견을 흡수하게 된다. 그리고 무엇보다 우리 팀이 마음에 드는 건 대화법이다. 서로 아닌 것 같거나 불만이 있는 점은 꿍해있지 않고 바로 바로 얘기를 함으로써 그 상황에서 서로 충분히 얘기를 하고 모르거나 이해 안되는 부분들도 서로 서로 솔직히 물어보고 채워주며 보완해나가고 있다. 팀원들이 한 분 한 분 다 배울 점이 있는 분들이라 너무 좋다. 그 분들의 장점이 나의 장점이 될 수 있도록 받아들이고 더 노력해야 겠다.
| Lombok | @Builder 동작 원리 (0) | 2023.09.21 |
|---|
어디서든 값을 변경 할 수 있는 setter 대신에 빌더 메서드를 사용하는 것을 지향한다.
빌더 메서드를 사용하기 위해서는 빌더 클래스를 직접 생성해도 되지만
Lombok에서 제공해주는 @Builder 어노테이션으로 간단하게 생성 할 수 있다.
@Builder 어노테이션은 클래스 단에 붙여도 되지만 그보다는 생성자 메서드 단에 붙이는 것이 더 좋다.
그 이유는 설명을 너무 잘 해둔 블로그가 있어 소개하겠다.
https://velog.io/@park2348190/Lombok-Builder%EC%9D%98-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC
Lombok @Builder의 동작 원리
보일러플레이트 메서드(getter/setter, constructor 등)를 직접 작성하지 않아도 대신 작성해주는 Lombok를 최근에 많이 활용하고 있다. 그나마 setter 메서드같은 경우는 값을 변경시키는 메서드는 그 목
velog.io
클래스 레벨에서는 가능한 모든 필드에 대하여 빌더 메서드를 생성했다면 생성자 레벨에서는 생성자의 파라미터 필드에 대해서만 빌더 메서드를 생성한다는 점이 차이가 있다.
클래스 레벨과 달리 생성자를 직접 생성해서 @Builder 를 적용하면 빌더로 설정하도록 제공하는 항목 역시 직접 고를 수 있다는 장점이 있다. 특히 JPA 엔티티 같은 경우 영속되기 전에는 식별자가 존재하지 않아 필연적으로 null 값을 가져야 한다. 이런 경우 생성자로 null 값을 전달하기보다는 아예 생성자에서 null 값을 받지 않도록 직접 구성하는 편이 좋다.
| [Thymeleaf] 문법 (0) | 2023.09.21 |
|---|
Thymeleaf를 이용해 view를 구현하고 있는데 th:object에 객체가 담기지 않는 오류가 발생했다.
컨트롤러에서 메서드를 어떻게 만져도 해결되지 않았다.
상단의 타임리프 라이브러리 추가하는 부분에 www.를 제거하면 된다.
<html xmlns:th="http://www.thymeleaf.org"><html xmlns:th="http://thymeleaf.org">
말끔히 해결..ㅎ
코드 오류가 아닌 라이브러리 주소 참조 오류였다..
이렇게 배우는 것 없는 오류 잡는게 제일 허무한 것 같다.
그래도 이런 라이브러리 참조에서도 오류가 날 수 있다는 점을 깨달았다.
다음에 같은 오류를 만나게 되면 더 빨리 오류를 해결할 수 있을 것 같다!
4~5시간은 이 오류를 해결하는데 시간 투자를 한거 같다.. 아무튼 오류 잡았으니 해^ㅡㅡ^피!
출처 : https://stackoverflow.com/questions/38710585/spring-boot-thymeleaf-in-intellij-cannot-resolve-vars