개린이의 일기장

git branch 전략과 commit 방법은 이미 많은 레퍼런스가 존재합니다. 하지만 지금 내 환경에 적합한 전략을 선택하는 것은 조금 다른 이야기입니다. 이 글에서는 사이드 프로젝트를 진행하면서 내가 해본 선택 과정을 기록합니다. GitHub - Our-Class-Bank/core-backend: [side-project] 우리반은행 [side-project] 우리반은행. Contribute to Our-Class-Bank/core-backend development by creating an account on GitHub. github.com 배경 github repository 에서 1인 백엔드 개발 프론트 개발은 별도의 repository 사용 dev, prod 배포 환경 지원 필요 전략 선택..

GitHub - Hyune-c/blogcode-errormessage Contribute to Hyune-c/blogcode-errormessage development by creating an account on GitHub. github.com HTTP status code는 3자리의 코드와 설명으로 표현됩니다. 하지만 실무에서는 더 많고 다양한 종류의 에러 표현을 위해 name, code, reason을 활용하곤 합니다. 그리고 간결함과 생산성을 위해 프로젝트 내에서도 code와 reason이 직관적으로 연결되기를 기대합니다. STEP 1. Enum으로 관리하기 @Getter @RequiredArgsConstructor public enum Errorcode { NOT_EXIST_PRODUCT("..

로직은 같지만 개발과 운영에서 필요한 값이 다른 경우가 있는데, 대표적으로 url이 있습니다. 지금의 회사에서는 enum을 통해 관리하고 있지만, 그 방식이 enum 스럽지 않다고 생각하고 있었습니다. 그러던 중 기존 test - dev - stage - prod로 구성되었던 환경이 dev - qa - stage - prod로 변경되었고, 이 과정에서 코드를 개선한 내용을 기록해 봅니다. Before 환경 변수 enum public enum DeploymentEnvironment { DEV, QA, STAGE, PROD; private static final String AUTH_SERVER_NAME = Optional.ofNullable(System.getenv("AUTH_SERVER_NAME")) ...

enum 은 서로 연관된 상수들의 집합으로 반복적으로 사용되는 코드 값을 표현할 때 유용합니다. 실무에서는 개발 편의성을 위해 DB에 있는 업무 코드들을 표현하기도 합니다. (등급 코드, 사용 여부 등) 하지만 프로젝트가 나눠지면 매번 복사해줘야 되고, 변경점이 생기면 반영이 필요하기에 썩 좋은 아이디어는 아닙니다. 때문에 쉬운 방법으로는 코드 테이블을 만들거나, 최신의 개발에서는 코드 정보를 MSA로 나누기도 합니다. 그럼에도 불구하고 업무 성격상 변경이 매우 적은 경우에는 개발 편의성과 성능 향상을 위해 사용할 수 있기에 실무에서 해본 리팩토링 내용을 기록해봅니다. Java Enum 활용기 | 우아한형제들 기술블로그 {{item.name}} 안녕하세요? 우아한 형제들에서 결제/정산 시스템을 개발하고 ..

개발 초기에는 AWS 구성을 하는 것도 일이기에, 지금까지는 프론트 개발자가 백엔드 소스를 받아서 local에서 서버를 띄우는 방식으로 진행했습니다. 물론 매번 DB를 올리지 않아도 되도록 local h2 구성을 해주고, 실행 편의 방법과 README를 제공해줬지만 프론트 개발자 입장에서는 불편한 게 현실이었습니다. 그러던 중 슬슬 목표한 앱의 한바퀴가 성공했기에 AWS 구성을 해보았고 그 기록을 남겨봅니다. ⚠️ 주의! 이 글은 사이드 프로젝트 구성을 위한 삽질기이기에 접근 제어 및 보안이 실무 수준에 미치지 못합니다. 실무에서 고려해야될 사항이나 도움이 될만한 내용은 코멘트했지만, 개인적인 경험에서 나온 기록이기에 선별적으로 이해해주시면 감사하겠습니다. # 계획 작업 전 배경 지식 실물 장비 기반의 ..

옛날에 채널에 글을 작성하는 슬랙 연동을 했을 때는 webhook으로 했던 것 같은데, 다시 해보니 잘 안됐습니다. 정확히는 local 에서는 됐지만 github에 올리면 webhook url 이 바뀌는 현상이 발생했습니다. 이상해서 검색해보니 요즘은 slack API 를 연동하는 것이 최신이기도 하고 webhook 보다 다양하게 쓸 수 있을 것 같아서 연동해본 내용을 기록합니다. 사전 조사 Using Slack APIs Every Slack app has access to a bag of tricks—a range of APIs that provide access to read, write, and update all kinds of data in Slack. api.slack.com 먼저 slack ..

GitHub - Hyune-c/blog-code: https://hyune-c.tistory.com/ 의 예제 code https://hyune-c.tistory.com/ 의 예제 code. Contribute to Hyune-c/blog-code development by creating an account on GitHub. github.com 팀으로 진행하고 있는 사이드 프로젝트에서는 회원 관리를 자체적으로 구현했습니다. 로그인도 별 문제없고 잘 되는 줄 알았는데, 어느 순간 로그인이 되지 않는 현상이 발생했습니다. 다행히도 문제는 금방 해결했지만 생각할게 많아진 주제였기에 기록을 남겨봅니다. 1. 회원 구현 @Entity public class Member { @Id @GeneratedValue(..

Step 3. 비동기 로직 @Configuration @EnableAsync public class AsyncConfiguration implements AsyncConfigurer { } 먼저 비동기 사용을 위한 설정을 추가합니다. @RestController public class AsyncTestController { private final AsyncService asyncService; @GetMapping("/api/test/async") public void asyncTest() throws InterruptedException { for (int i = 1; i { if (copyOfContextMap != null) { MDC.setContextMap(copyOfContextMap); }..

이전에 코드스쿼드에 공개해서 반응이 뜨거웠던(?) 표준 예외 처리가 있습니다. 하지만 실무를 하다 보니 부족한 점이 보이고, 고도화하는 김에 로깅까지 해야겠다고 생각해서 글을 작성해봅니다. 이전의 repository 도 남기지만 굳이 참고하지 않고 본 코드만 따라오셔도 무방합니다. [deprecated] 표준 예외 처리 표준 예외 처리에서 로깅까지 Step 1. 리팩터링 이전에 작성한 표준 예외 처리를 리팩터링 하는 것으로 시작하겠습니다. 1. ExceptionAdvice 분리 2. 테스트 케이스 이 정도로 장애 원인을 추적할 수 있나? 실무에서는 장애를 추적하기 위해 장애 난 시점만이 아닌 연관된 흐름을 봐야 합니다. 하지만 Step 1 에서는 logId 가 에러 발생 시점에만 존재하기 때문에 동시에 ..

Step 4. Custom Annotation 을 통해 로그인 정보 가져오기 1. Custom Annotation 구현 @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.PARAMETER) public @interface LoginMember { boolean required() default true; } annotation 은 기본 값을 true 로 두고 필요한 api 에서만 사용합니다. @Component public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver { private static final String AUTHORIZATION_HEADER = "au..