250x250
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 혼공SQL
- 알고리즘분석
- AWS
- mysql
- DDD
- CleanCode
- MariaDB
- 자바스터디
- 기술면접
- 네트워크
- 자바예외
- 알고리즘
- 클린코드
- 이팩티브 자바
- 스프링부트와AWS로혼자구현하는웹서비스
- 이펙티브 자바
- 인프런백기선
- java
- 도메인 주도 개발 시작하기
- AWS RDS
- SQL쿡북
- 이펙티브자바
- 인프런김영한
- aop
- jpa
- 자료구조
- 자바
- 인덱스
- react
- vue.js
Archives
- Today
- Total
목록좋은설계 (1)
기록이 힘이다.
좋은 설계는 제약이 있는 것이다
@Around만 있으면 되는데 왜? 이렇게 제약을 두는가? 제약은 실수를 미연에 방지한다. 일종에 가이드 역할을 한다. 만약 @Around를 사용했는데, 중간에 다른 개발자가 해당 코드(Object result = joinPoint.proceed();)를 수정해서 후출하지 않았다면? 큰 장애가 발생했을 것이다. 처음부터 @Before 를 사용했다면 이런 문제 자체가 발생하지 않는다. 제약 덕분에 역할이 명확해진다. 다른 개발자도 이 코드를 보고 고민해야 하는 범위가 줄어들고 코드의 의도도 파악하기 쉽다. @Around("hello.aop.order.aop.Pointcuts.orderAndService()") public Object doTransaction(ProceedingJoinPoint joinPo..
SpringBoot
2023. 7. 16. 14:37