9월 둘째 주의 주간 회고

Spes Lim·2021년 9월 14일
1

Retrospective

목록 보기
2/2

주말 저녁부터 몸이 아프기 시작했고, 해야할 일이 많이 늦어졌다.
주간 회고를 작성하는 것도 그 일환의 하나였는데, 공부한 것은 하루의 끝에 비동기적으로 올리고 반성과 성찰은 주 후반에 붙이는 것이 좀 더 나은 것 같다. 덧 붙여서, 컨디션이 안 좋을때는 그냥 편하게 푹 쉬고 일어나는 것이 그 다음날의 컨디션을 회복하는데 빠른 루트가 된다.

변화.

  • 이제 intelliJIDEA 사용할 때 트랙패드를 더 이상 필요로 하지 않는다.
  • 왜 사람들이 Vim을 선호하는지 더 와닿는 시간을 보냈다. 키보드로 제어가 능숙해지면 생산성은 더 향상된다. 작업 속도가 빨라졌고, 이제는 느린 작업을 참지 못하게 됐다.
  • IDE를 틈틈이 뜯어보는 것이 오전 일과 중 하나인데, 내가 제일 많이 보는 영역은 Preference > Refactor > Debug > Project Structure 순으로 자주 보고있다.
  • 생각없이 코딩하는 일이 줄어들었다. 엄밀히 말하자면 무엇을 설계하는지 정의하고, 정의한 내용을 기반으로 작업을 잘게 조각낸다. 하나의 작업 이후 빌드를 거쳐서 다시 하나씩 코드를 덧 붙여 가는 형태로 코드를 작성하는 습관이 생겼다.
  • 에러 메시지는 내가 앞으로 행동해야 할 방향을 알려주는 메시지로 인식이 많이 변화했다.

인텔리제이 사용하면서 알게 된 자잘한 것들.

  1. 코드가 자동으로 접히는 것이 싫다면
    Preference > Editor > Code Folding 사용중인 체크박스 전부 해제

  2. 탭의 닫기 버튼 위치 변경하기
    Preference > Editor > Editor Tabs에서 Close Button Position Right > Left 변경

  3. 스프링 부트 실행할 때 마다 뜨는 OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. 문구를 더 이상 보고싶지 않다면

Run/Debug > Enable Launch Optimization / Enable JMX agent 체크박스 해제

  1. 메소드 IMPORT 할 때, 다른 프레임워크의 메소드가 서두에 뜬다면?

Project Structure (Command + ;) > Project > Project SDK 에 내가 사용중인 SDK를 확인.

트러블슈팅 일지.

가능하면 영어 해석을 정확하게 하고, 그것을 바탕으로 가설을 세우고 검증하고, 관련 지식을 찾아서 습득하는 방향으로 학습을 한다.

JWT 모듈이 build.gradle에서 sync failed가 떴다.
에러메시지는 다음과 같았다.

내가 읽어야 할 부분은 Could not find runtime() 이 부분일 것이다. 문제 해결의 중요한 열쇠다.

직역하자면, runtime 메소드가 없다는 말 이다.
runtime 이란 메소드가 없다는 말은 무엇을 의미하는 것일까?
시스템에서는 기존의 runtime을 새로운 메소드로 바꾸어서 제공했을 확률이 높을 것이다.

여기서 봐야할 것이 두 가지가 있다.

  1. runtime 메소드가 교체된 시점은 gradle 몇 버전 부터인가?
  2. 교체된 새로운 메소드는 무엇인가?

정답은 아래에 있었다.
확인

개발은 결국 그림을 그리는 것과 비슷하다.

HTTP REST API를 만든다고 가정을 하자.
만들어야 할 기능은 크게 몇가지가 있을까? CRUD. 4가지 일 것이다. CRUD 명세를 작성하고 가장 먼저 작성해야 할 부분은 어디일까를 생각해본다. 우선, CREATE 부터 만든다고 한다면, 어디를 먼저 보겠는가? 회원 가입, 혹은 웹 에서의 등록과 같은 부분을 받아서 처리할 url이 매핑이 될 컨트롤러 부터 필요할지도 모른다. (이 순서도 설계에 따라서 달라질 수 있다.)

컨트롤러를 만들고, 컨트롤러 내부에 요청을 처리할 핸들러 내지 메소드를 구현한다. 하지만 컨트롤러는 간접적으로 요청을 받아서 처리하는 위임 패턴을 가졌기에, 실질적인 요청 처리는 service 안에서 하도록 하고 service 인터페이스를 구현한다. 컨트롤러 인터페이스 밖에 RequestMapping을 선언한다. 요청이 들어오면 매핑이 될 url을 처리하는 부분을 구현하는 것이다. 그림을 그리는 것으로 비유하면, 유화에서 그림을 그리기 전 색을 입히는 것과 비슷하다.

구현 한 뒤, 빌드를 하면 단연 에러메시지가 뜰 것이다.
에러메시지를 잘 봐야 한다. 무엇이 부족해서 생기는 것인지 알아야 한다. 그리고 필요한 것을 찾아서 하나씩 붙여서 넣어줘야 한다.

설계와 코딩이 함께 가려면 이와 같은 방법을 따라야 한다.

나는 이러한 사고의 흐름을 철칙으로 세우고 기존에 작성하던 코드를 과감하게 지웠다. 시간이 걸리더라도 그 방법으로 설계해서 완성하는 것이 1차적인 목표이다. 목표를 달성한 뒤에는 또 다시 지울것이고 이 같은 과정을 눈감고서 할 수 있을 때까지 반복해야 겠다는 생각이 들었다.

이런 성장에 큰 도움을 주신 분들에게 너무 감사하다.

profile
Software Developer

0개의 댓글