일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- AWS
- Paging
- JPA
- 스프링부트
- 프로그래머스
- mock
- Spring Batch
- 트랜잭션
- HTTP
- CircuitBreaker
- 우아한테크코스
- 레벨2
- Docker
- REDIS
- AOP
- 자바
- 미션
- 백준
- 우테코
- MSA
- 의존성
- JUnit5
- 코드리뷰
- yml
- 프리코스
- 스프링 부트
- Level2
- 세션
- 서블릿
- 우아한세미나
- Today
- Total
목록우아한테크코스 4기 (41)
늘
1. Transactional(readOnly = true)효과 1.성능상에 이점 readOnly일 경우 트랜잭션 ID를 부여하지 않아 조금의 성능 향상이 있다. 2.안전성 읽기가 아닌 수정하는 동작이 발생하면 TransientDataAccessResourceException 예외를 발생하여 변경을 막아줄 수 있습니다. 그런데 디비에 따라 다르고 Mysql은 위처럼 발생하지만 h2 인메모리 디비에서는 예외가 발생하지 않는다고 한다. 3. 가독성 readOnly가 붙은 메서드는 모두 조회 메서드라는 것을 한 눈에 파악할수 있다는게 장점이다. 예를 들어 프로그램이 커지면 수많은 메서드들이 존재할텐데 그중에서 조회 로직을 수정해야한다면, readOnly가 달린 메서드들만 빠르게 찾아 수정할수 있다는 장점이 있..
@JdbcTest @Sql("/schema.sql") class RoomDaoTest { @Autowired private JdbcTemplate jdbcTemplate; private RoomDao roomDao = new RoomDaoImpl(jdbcTemplate); } 위 코드는 현재 NPE가 발생합니다. 반면에 아래 코드처럼 텍스트픽쳐스를 이용한 테스트는 정상 동작합니다. @Sql("/schema.sql") @JdbcTest class PieceDaoTest { @Autowired private JdbcTemplate jdbcTemplate; private PieceDao pieceDao; @BeforeEach void setUp(){ pieceDao = new PieceDaoImpl(jdbcT..
1. 의존성 주입 방법 setter를 통한 주입 생성자를 통합 주입 필드를 통한 주입 스프링 공식 문서에서도 생성자를 통한 주입을 추천한다고 한다. 생성자를 통한 장점으로는 아래와 같다. setter를 통한 주입과 달리 필드에 final을 선언해줄 수 있고 불변으로 만들 수 있다는 장점이 있다. 결합도를 낮춰 테스트 코드 작성에 용이해지는 장점이 있고 null을 주입하지 않는 한 NPE가 발생하지 않도록 보장해준다. 순환 참조가 발생하면 애플리케이션 실행 시 미리 알려주기 때문에 예방할 수 있다. 왜냐하면 생성자 주입 방식은 객체가 생성되고 필요한 빈을 빈팩토리에서 생성해서 생성자를 찾아 주입하기 때문이다. 반면에 다른 2가지 방법들은 빈이 먼저 생성된 이후에 객체가 생성되고 주입이 되기 때문에 빈을 생..
우테코 강의 시간에 차이점에 대해 알아봤었는데 다 까먹고...매번 볼때마다 다시 찾아보는 것 같아서 정리해두려고 한다.🙂 자바에는 크게 두 가지 Exception 종류가 있다. checked Exception과 unchecked Exception이다. checked Exception checked Exception은 RuntimeException의 하위 클래스가 아니면서 Exception 클래스의 하위 클래스들이다. Compile Exception으로도 불리며 반드시 예외 처리를 해줘야 한다. 주로 예외를 활용해서 다른 작업을 할 때 사용된다. 예시로 IOException, SQLException이 있다. 예외 발생시 트랜잭션이 롤백 해주지 않는다. unchecked Exception RuntimeExc..
테스트 코드 @DisplayName()을 사용하면 아스키코드 warning이 안뜨므로 운영할떄 로고가 안찍혀서 좋다. 리펙토링을 할때는 기존의 테스트 코드가 깨지지않도록 해야한다! private 매서드 테스트할떄 로직을 테스트 코드 작성하는 곳에 가져와서 테스트를 돌려본다.. JDK11 타입 추론 final을 붙여서 타입 불변으로 해주는게 좋다. 뭐든 커지면 의심하자 패키지가 커지면 응집도에 관해 의심해보고, 매서드가 커지면 단일책임 원칙에 대해서 의심해보자... Static 언제 사용하는게 좋나? util 클래스와 같은 곳 , 상태관리를 안해도 되므로, 생성자를 private으로 하여 인스턴스화를 막기도 한다.(util이라는 것을 명확히 보여주기 위해) 값을 비교할 때, 이상? 초과? 어떤 방식을 이용..
Level 1의 마지막 미션으로는 체스 미션을 진행했다. 1단계에서는 콘솔 창에서 명령어를 입력해서 체스 게임을 할 수 있도록 구현했다. 2단계에서는 1단계에서 작성했던 도메인을 기반으로 자바 spark로 jdbc를 이용해 db와 연동되도록 구현했다. 1. 상황에 적절한 예외를 던지자. 이펙티브 자바에 의하면 IllegalArgumentException은 허용하지 않는 인수가 들어오는 경우 IllegalStateException은 객체가 메서드를 수행하기에 적절하지 않은 상태인 경우 UnsupportedOpertionException 은 호출한 메서드를 지원하지 않을 때 사용한다. 위 코드는 한 번 override된 메서드이므로 UnsupportedOperationException보다는 IllegalSt..
우테코 나와 맞을까? 옷을 멀리서 보기만 해서는 나와 사이즈가 맞는지 알 수 없다. 직접 입어 보기 전까지는 모른다. 처음 우테코를 지원할 때만 해도 전공자이고 스프링 공부도 하고 있었기 때문에 쉽게 적응할 것이라고 생각했다. 하지만 1단계, 2단계 미션이 진행될수록 여유로움은 점점 사라지고 안일했던 나를 반성하게 되었다. 나에게 작아 보였던 우테코라는 옷은 나에게 맞지 않은 큰 옷처럼 보였다. 맞지 않은 옷 초등학교시절 엄마와 옷을 사러 가면 엄마는 항상 소매보다 긴 옷을 사 입혔다. 그때는 왜 옷을 크게 사주는지 몰랐지만 지금은 알 수 있다. '유년기 시절에는 빠르게 성장하기 때문에 미리 큰 옷을 사 입힌 것이었다.' 처음 ot를 시작으로 메타버스에서의 활동, 보이는 라디오, 온라인 회식, 페어 프로..
1. 자료구조를 사용하자 여러 값들을 담을 때 생각없이 매번 List를 쓰는 버릇을 고쳐야겠다. 적절한 자료구조를 사용하면 코드가 많이 줄여지고 깔끔해진다. 2. 정적 팩토리 매서드 네이밍 정적 팩토리 메서드 명명 규칙 from : 매개변수 하나를 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드 ex) Date date = Date.from(instant); of : 매개변수 여러개를 받아서 적합한 타입의 인스턴스를 반환하는 집계 메서드 ex) Set cards = EnumSet.of(JACK, QUEEN, KING); valueOf : from과 of의 더 자세한 버전 ex) BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE); instance o..
리뷰를 폭탄으로 맞았다 🤣🤣 오히려 좋다.. 배울게 너무 많아서 😬😬 이번 2주 차 미션을 진행하면서 새롭게 배운 것들이 많다. 1. 멀티 스레드 환경에서 상태 공유 바로 찾아보았다. 학교 운영체재 시간에 배운 동시성 이슈라고 생각했다. final로 완전한 불변이 안 만들어져서 아예 내부 상태를 갖지 않도록 하는 게 좋은 것 같다! 당연한 거지만 자주 까먹는 것 같다.🤣 이번에는 기억해 두자!! 2. 방어적 복사 핵심은 객체 내부의 값을 외부로부터 보호하는 것이라는 것을 유념하자. 생성자의 인자로 객체를 받았을 때 외부에서 넘겨줬던 객체를 변경해도 내부의 객체는 변하지 않아야 한다. 따라서 방어적 복사가 적절하다. getter를 통해 객체를 리턴할 때 이 상황에선 방어적 복사를 통해 복사본을 반환해도 좋..
로또 미션을 진행하면서 리뷰 폭탄에 정신없이 해결해야겠다고 생각해서 rebase를 진행하지 않고 step1 브랜치에 바로 진행을 했다. 열심히 코드를 리펙토링 하고 마지막에 리뷰 요청을 보냈는데 충돌이 발생해서 충돌을 해결하고 요청을 보내라고 했다.. git cherry-pick vs git rebase 간단히 다른 브랜치의 커밋 기록을 현재 브랜치로 가져올 수 있는 기능이다. git rebase와 비슷한 성격이지만 조금 다르다. rebase는 현재 브랜치에서만 가능하고 다른 브랜치에서 commit을 가져오려면 merge를 한 후 rebase를 해야 한다. 반면에 cherry-pick은 이러한 과정 없이 바로 다르 브랜치의 commit#만 알면 가능하다는 장점이 있다. 하지만 cherry-pick은 같은..