이걸 쓰는 이유
회사에서 주어진 일을 열-심-히 하다보니까, 가끔이긴 하지만 분명 배우는 것들이 있다.
그치만 그 배움의 순간에서 그걸 확실히 내 것으로 만들지 못하면 스쳐지나갈 것만 같은 불안한 기분이 들었다.
그래서 벌써 3년째 해오던대로 글로 기록하면서 최대한 내것으로 만들고자 한다.
그리고 1년차가 되고, 2년차가 되고, 그렇게 시간이 지나면서 과거 회상도 좀 해보고자 일기 형식으로 시리즈를 연재하기로 마음 먹었다!
왜 0년차?
사실 경력이 시작되는 순간 1년차라고 부르긴 한다. 통상적으로.
그런데 내가 느끼기에 나는 1년차라고 부를 자격이 없다.
정말 1년을 꽉 채웠을 때, 만으로 1년일 때, 1년차라고 스스로를 인정할 수 있게 될 것 같아서 0년차로 타이틀을 정했다.
0년차로써 나의 직무
현재 풀스택 웹 개발자로 일하고 있다.
운이 좋게도 회사가 판교에 있어서 개발자로서는 부족함 없는 인프라속에 성장해나가고 있는 중이다.
- Vue.js 를 아주 일부 사용하여 프론트엔드 개발
- Spring Boot 를 기반으로 한 백엔드 개발
- 이외에도 레거시라고 부를만한 기술 몇개를 사용중.
뭔가 프론트와 백을 구분짓고 싶어서 위처럼 말했지만, 사실 그냥 다 한다..
여기서 말하는 "다" 라는게 진짜 다이다....ㅎㅠ
사용중인 기술 스택을 나열하자면 한 20가지는 될 듯 싶다.
내가 개발을 대하는 순서
- 기획서를 검토한다. (기획서가 만들어질 당시에는 내가 근무하고 있지 않았기 때문에 기획자와 함께 리뷰하진 못했다.)
- 기획서에서 이해안가는 점들을 골라서 기획자에게 문의 및 상의한다.
- 데이터베이스 테이블을 살펴보고 설계 가능한 방향을 찾는다.
- 확실히 되는건 제외하고, 이게 되려나? 싶은 것들은 쿼리를 짜서 먼저 실험해본다.
- 된다는 걸 알았으면 그 쿼리가 혹시 안티패턴 같은 건 아닐지 찾아본다.
- 이제 진짜 된다는 걸 알았으면 기획에 나온 페이지를 우선 프론트에 붙여둔다.
- MyBatis 또는 JPA 또는 Querydsl 을 활용해서 필요한 DAO를 만든다.
- 비지니스 로직을 서비스에 짜둔다.
- API의 URI를 뭐라고 할 지 잠깐 고민하고 컨트롤러를 만든다.
- Vue에서 Axios request 로 요청하고 리턴받은 데이터를 바인딩해준다. 끝!
보통 이런 순서로 개발을 하고 있는데, 역시나 부족한게 너무 많다.
지금 느끼는 부족한 점
설계다.
개발을 하는 중간중간, 계속해서 어떻게 설계해야 더 효율적일 수 있지? 이걸 매번 생각하는데, 좋은 결론을 얻기가 쉽지 않다.
구글링을 통해 ~~이렇게 하는게 좋다더라 하는 정도의 답은 얻을 수 있는데, 실제 내가 짠 코드가 좋은 코드인지도 알고 싶다.
그치만 현재 회사의 개발자분들에게 이런걸 물어볼 수가 없다... 지금의 회사는 그런 분위기가 아니다......
로그는 어디에 어떻게 남겨야 효율적일지.
쿼리에 서브쿼리나 조인이 많다면 이걸 분리할 수도 있는 더 나은 쿼리가 있을지.
혹은 비즈니스 로직 단에서 이걸 해결할 수 있을지.
지금 문제를 백엔드에서 해결하는 게 옳은 건지.
아니면 프론트로 던져서 그 쪽에서 해결하는 게 나은지.
해결책, 그리고 별도로 배운 것들.
먼저 로그는 그 목적을 생각해봤다.
로그를 왜 남겨야 하는가
내 생각에는 무슨 일이 생겼을 때, 그게 어떤 일인지 알리기 위해서다.
그래서 우선 에러를 표현하는 용도로 사용하고 있다.
그리고 한 가지 커다란 로직을 돌면서 중간에 어떤 데이터들이 돌고 있는지 확인해볼 때 log.info를 활용하고 있다.
서브쿼리는 1일 1깃으로 유명하신 개발자분의 블로그에서 보면 안티패턴으로 생각하고 계셨고 그 이유는 실제로도 속도 차이가 있기 때문이라고 하셨다.
하지만 나는 그것보다도 서브쿼리를 짰을 때 Null 익셉션에 대처하기가 더 어렵다고 느껴서 사용을 안하기로 했다.
즉, 서브쿼리를 지양한다는 점에서 결과는 같았지만 내 의도는 내가 이해하기 어려워서... 인걸로..ㅎ
왜냐면 서브쿼리에서 에러가 났을 때 Querydsl 기준으로는 그걸 찾을 방법?이 없어보였다.
그런데 쿼리를 쪼개고 비지니스 로직에서 예외처리를 해주면 간단히 해결되니까, 이렇게 하기로 했다.
풀스택의 최고 장점은 프론트엔드와 백엔드, 그 어디서도 대충할 수 없다는 것이다.
백엔드에서 뭣 같이 해서 던져줘도 결국 그걸 받는게 프론트의 나다...^^
때문에 API를 설계할때 어느정도까지 설계해서 프론트로 리턴을 해줘야할 지 고민하는 건 아직 확실한 해답을 찾지 못했다.
다만, 가능하면 서버 호출 횟수를 줄이는 게 좋다는 개발자 선배님의 말과 내가 자바스크립트 보다는 자바가 편하기 때문에 겸사겸사..
그냥 스프링에서 가능한 모든걸 처리한 뒤에 프론트로 내려주고 있다.
근데 이렇게 하니까 프론트 코드가 간결해져서 가독성도 올라가고 좋은 것 같다.
그럼 백엔드 쪽에서는 코드가 더러운지 보면, 또 그것도 아니다.
API를 최대한 프론트에서 필요한 데이터에 가깝게 가공해서 리턴해주는 게 생각보다 서로 윈윈하는 방법인 것 같다고 느끼고 있다.
별도로 배운것.
-
1. 프론트에서 날짜가 필요할 때 이제는 Date 가 아닌, moment를 사용하고 있다.
그런데 moment로 어디까지 할 수 있는지는 잘 모른다.
이번에 매 달마다 그 달의 시작일자와 마지막 일자를 구해와야하는 문제가 있었다.
예를 들어 3월이라면 2022.03.01 ~ 2022.03.30 뭐 이런식으로 말이다.
근데 달마다 일 수가 달라지니까 이걸 자동으로 할 수 있는 방법이 뭐가 있을지 찾아보니 이것도 moment로 가능했다.
moment.startOf('month') 그리고 moment.endOf('month') 이거면 해결된다. -
2. Vue에서 화면을 뿌리기 까지의 라이프사이클에서 중간에 변경되는 데이터를 감지하지 못해서 바인딩에 실패하는 경우가 있었다.
그럴 때는 Watch 를 사용할 수도 있는데, 찾아보니 배열의 경우 arr = [10, 29] 이런식으로 push가 아닌 직접 초기화를 한다면 watch로 잡을 수 없다고 한다.
그래서 지연 로딩을 해야하나? 고민이 많았는데 강제 리로딩하는 방법이 있었다.
this.forceUpdate(); 를 하게되면 context상의 this에 해당하는 값을 강제로 리로딩한다.
Vue에서 직접 제공하는 기능임으로 안전하지만, 당연히 사용을 권장하진 않는다.
그래서 아예 프론트 구조자체를 변경해서 해결해볼 순 없을까 생각해봤다.
얻은 답은 가능이었지만 지금 개발팀의 기술적 상황에서는 불가능이었다.
Vue를 100% 제대로 사용하는 것이 아니라 jQuery + jsp 와 병행하며 사용중이기 때문이다.
이렇게 사용하는 이유는 프로젝트를 처음 시작하던 당시 개발팀이 Vue에 익숙하지 않았기 때문이라고 한다.
순간의 최선이었을테니 어쩔 수 없이 강제 리로딩을 했지만, 아무래도 찝찝하다...ㅠ
아래는 최근에 읽고 있는 책 : JPA라던지 각종 기술서적도 당연히 읽고 있지만, 그냥 뭔가 효율적인 설계에 계속해서 호기심이 생기는 중이다..
