우디의 성장일기

2주차... 이전에 3주차 코드 리뷰를 먼저 정리해보려고 한다..! 1. Converting String to Numeric value 처음에 나의 코드는 아래와 같이 NumberFormatException에 대한 고려를 전혀 하지 않은 코드였다. 만약 nativeWebRequest.getParameter("offset")이라는 코드에서 "0L" 숫자가 아닌 문자가 섞여있다면 바로 예외 상황이 발생할 것이다. Long offset = Long.parseLong(nativeWebRequest.getParameter("offset")); ✨ 이후 예외 상황으로부터 안전한 코드를 만들기 위해서 Apache Commons에 있는 NumberUtils를 활용했다. // toLong(String str, long ..

1주차는 간단한 자기소개, intro 느낌이었지만 2주차부터는 좀 더 본격적으로 멘토님에게 직무 혹은 취업에 관련된 이야기를 들을 수 있었다. 멘토님의 이력은... 매우 화려했다..ㅠ 보잘 것없는 취준생에게 이런 고급 인력이 나에게 1시간을 감히 쓰셔도 되는건가 싶을 정도로..ㅎ 오늘 멘토링 시간에서 가장 좋았던 건 내가 관심있는 분야에 대해서 대화를 할 수 있다는 것 자체도 너무 좋았고 IT 업계의 좀 더 큰 흐름에 대해 알 수 있어서 재밌었다. 그리고 요즘 취준 생각에 좀 다운되어있었는데 놀랍게도 멘토링 이후 의욕 게이지가 상승했다ㅎㅎ 동기부여도 되고 조금 더 불확실한 미래에 갈피를 잡을 수 있게 되어서일지도 모르겠다. 그럼 오늘 멘토링 받은 내용들을 간단히 요약해보자! 기업의 기본 사이클 삼성전자를..

[공식 문서 참조] 1. 이전 계정의 깃 repository와 연결된 폴더로 이동 후 2. 현재 remote 정보 확인 git remote -v > origin https://github.com/USERNAME/REPOSITORY.git (fetch) > origin https://github.com/USERNAME/REPOSITORY.git (push) 3. 바꾸고자 하는 remote url을 set-url 명령어와 함께 입력 git remote set-url origin https://github.com/USERNAME/REPOSITORY.git 4. 바뀐 remote 정보 확인 git remote -v > origin https://github.com/USERNAME/REPOSITORY.git (f..

서로 완전히 다른 branch를 merge - merge unrelated project [참고] git merge main --allow-unrelated-histories # 위의 명령어를 실행하면 # 현재 checkout 되어있는 브랜치와 로컬의 main 브랜치와 병합 # (요즘은 github에서 repository 생성하면 기본 브랜치명이 main이더라)

SOLID는 다섯 가지 원칙에 대한 약자이다. 단일 책임 원칙 Single Responsiblity Principle (SRP) 한 클래스 하나의 책임(기능). 한 클래스에 여러 가지 기능들이 쏠리게 되면 내부 코드를 수정할 때 다른 코드들도 함께 영향을 받을 확률이 높아진다. 즉, 결합도가 올라가게 되어 유지보수가 어려워진다. 그렇기 때문에 책임 단위로 캡슐화시켜 코드의 응집도는 높이고 결합도는 낮추어야한다. 개방-폐쇄 원칙 Open Closed Principle (OCP) 수정에는 닫혀있고, 확장에는 열려있고. 이를 위해서는 어떤 부분이 바뀌는(update) 부분인지를 먼저 찾아야한다. 바뀌는 부분은 따로 뽑아서 캡슐화시킨다. 그렇게 하면 시스템의 유연성이 높아져, 해당 코드를 수정 혹은 확장하더라도..

1주차로 작성한 스프링 부트 프로젝트에 대해 리뷰받은 내용을 정리해보려고 한다..! 1. Controller Based Injection @RestController @RequestMapping("/api/users") public class UserRestController { @Autowired UserService userService; public UserRestController(UserService userService){ this.userService = userService; } 원래 내가 쓰던 코드였다. 하지만 여기서 ✨ UserService는 이미 생성자를 통해서 DI(Dependency Injection)되기 때문에 따로 @Autowired 표기를 하지 않아도 된다. 이렇게 Contr..

JWT는 Json Web Token의 약자이다 헤더.페이로드.서명 이 세 가지로 구성되어있고 각각의 요소는 '.'을 통해서 구분된다. 가장 먼저 헤더(Header)는 해당 JWT를 어떻게 검증할 지에 대한 정보를 담고있다. { "alg": "서명 시에 사용하는 알고리즘", "kid": "서명 시에 사용하는 키 식별 값(public/private key)" } 위의 JSON 객체 직렬화 → '{"alg": "알고리즘","kid": "키 식별 값"}' → UTF-8로 인코딩 → UTF-8(직렬화된 JSON객체) → Base64 URL-Safe로 인코딩→ Base64URLSafe(UTF-8 인코딩 결과) → eyAAAAAA 헤더 짜란 JSON 객체를 직렬화하고 인코딩한 최종결과가 헤더이다. (ey~~ 요론게)..

Creational Design Pattern 중 하나이다. Head First Design Pattern의 예시를 통해 살펴보면 Vacation 인스턴스를 만드는데 client 1은 호텔, 점심, 렌트카 client 2는 호텔 client 3는 호텔, 저녁, 렌트카, 전망대 를 요청했다고 가정하면 Vacation 클래스는 client 모두의 요청을 포괄해야하기 때문에 각 client들의 요청을 인스턴스화하기 위해서는 client 1을 위한 Vacation(호텔 h, 점심 l, 렌트카 c) client 2을 위한 Vacation(호텔 h) client 3을 위한 Vacation(호텔 h, 저녁 d, 렌트카 c, 전망대 v) 이렇게 3개의 다른 생성자를 만들어주거나, 모든 변수를 포괄하는 생성자 하나를 만..

의미있는 이름은 중요하다고 생각한다. 프로젝트가 커지면 커질 수록, 협업 인원이 늘어날 수록 더 중요해지는 것같다. 클린 코드에서는 이름에 대한 몇 가지 원칙을 제시해주고있다. '의도를 밝혀라' 즉, 코드를 보았을 때 코드 맥락에 관한 정보를 제공할 수 있도록 하기위해서는 이름에 의도가 드러나야한다.(코드의 단순성 < 코드의 함축성) 가령, 보드판 게임에 관한 코드를 작성할 때 List 보다는 List, 그리고 if(cell[STATUS] == FLAGGED)보다는 if(cell.isFlagged()) 라는 명시적인 함수가 더 적절하다. '그릇된 정보를 피하라' 프로그래머에게 혼동을 줄 수 있는 이름들도 '그릇된 정보'에 해당하는 것같다. 명령을 담당하는 클래스를 Manager라고 했다가, 다른 쪽에서는..

최근 Spring Boot 프로젝트 스터디에 들어갔는데.. 현직자들이 많은 것같았다. 따라가기가 사실 너어어어무 힘들지만 일단 다른 사람들 코드를 보면서, 그리고 멘토님 코드를 보면서 계속 공부해야겠다 스터디에서 추천해준 책인 '토비의 스프링 3.1'도 정말정말 큰 도움이 되고있다. 정말 말 그대로 스프링의 기술적인 부분보다도 스프링 자체를 이해하고싶다면 이 책은 정말 ㄹㅇ 바이블.. 주변에 벡앤드 공부하는 친구가 있다면 추천해주고 싶지만 그런 친구가 없기때문에... (훌쩍) 이 기쁨을 함께할 수 없어서 살짝 아쉽다.. 요 근래 느낀 바, 배운 점들에 대해 적어보려한다. Commit period Commit을 기능 단위로 해야한다고 말은 들었지만, 와닿지 않았다. 근데 정말 생각보다 ..