애자일

개발일지

하뽀로로 2024. 1. 12. 00:01

오늘부터 개발일지를 써보려고한다.
내가 매일 회사나 집에서하는 사이드프로젝트에서 나오는 일들을 적어봐야겠다 !!



매일 쓰려고하니까 쓸말이 없군..

나는 회사에서 여러업무를 해봤다 😫
재밋게 다니다보니 벌써 만 10년이 넘었다..ㅋㅋ
5년은 다닐 수 있을까 생각했는데 😅
가끔 다른 회사가 궁금하기도 하당.
좋은것도있고 나쁜것도 있지만
지금 되돌아보면 좋은점이 더 많은것 같다.

깊지는 않지만 보는눈을 넓힌게 생각해보니까 크다.

단점은 나만의 소프트웨어, 정말 깊은 찐 전문가 등은 못 한것 같다.

오늘 일어난 일
나는 클라이언트쪽만 담당하고있다.
그런데 서버 파트에서 기간도 부족하고, 의존성이있는 프레임워크도 안정화가 되지않아 개발에 어려움을 겪고있었다.
그래서 서버 기술스택을 변경하면서 우리쪽에서 API 서버를 함께 개발하기로했다.

우리회사는 지금 많은 애자일 스크럼이 존재한다 🚅
계속 늘어나고 있다고하더라고 !!

우리 스크럼은 2주마다 하나의 스프린트를 진행한다.
시작과 종료는 매 2주 목요일
그루밍은 매 2주 목요일
오늘 시점은 !!!
스프린트 데모가 일주일 남은 상황 !!!

선택해야한다.


1. 스프린트 엎는다.
2. 신규 서버와 기존 클라이언트 기능을 붙인다.

1번 선택 시
- 마음편해짐
- 구조 잡을 수 있음
- 리스크 사전에 잡을 수 있음
- 디비 설계 다시 할 시간 생김
- 플래닝한게 다 없어짐 ㅜㅜ

2번 선택 시
- 구조 설계 절대 불가
- 레포 설정 할 시간없음(lint, ts 등)
- 디비 스키마 확정 불가(폭망)
- 기술 스택 변경 가능하겠다는 확신
- 프로젝트 개발 기간 단축
- 팀내 기술스택 맞춰짐

뭘 선택 했을까 😇







나는 2번 선택


이 글을 쓰는 이유기도 하지만
이걸 기록해 두고 싶었다.

당장 설계하지않고 최대한 빠른 프로토타입을 만들자.
이번 스프린트에서 돌아가는 소프트웨어를 모두에게 보여주자!!! 가즈아!!!
서비스 구조 설계는 리팩토링으로 반영하자.
디비 스키마는 리팩토링하기전 설계/문서화하자.
그나마 nestjs이기 때문에 어렵지 않겠다 생각!

2번을 선택하고, 하루 종일 보일러플레이트 코드에 동작하는 API를 후다다다닥 만들었다.
요즘 nestjs에서는 swagger 모듈을 지원해주기 때문에 코드를 개발하고 테코레이터를달면 문서까지 다 만들어줬다.

소감


진짜 힘들다.

그래도 신규 프레임워크로 개발하니까 재미있다.

프로토타입을 생각하고 만들다보니 거슬리는 코드가 너무 많아!!!!
데이터 레이어가 없어서 디비모델에서 바로 접근한다. 이건 진짜 큰 문제다. 제일 빨리 바꿔야한다 ㅋㅋ(대충보면 문제없어보이지만 지금 상황에 디비 바뀌면 nestjs service 모든코드 업데이트 해야함 ㄷㄷ)
가독성이 너무 떨어진다다다.
내가 짠코드이고 내가 방금친건데도 너무 읽기 어렵다.
개발하면서 어느정도 개발이 깔끔하게 된 코드는 신규 기능 개발하는 시간이 점점 줄어들었다 !! (이전 프로젝트에서 완전 느낌, 같은 일을하는데 시간은 반정도??)

보기좋은 코드가 가지고 오기 쉽다.
보기좋은 코드가 에러 확률이 낮다.
보기좋은 코드가 재활용이 좋다.

얼른 구조잡고 설계해서 깔끔한 코드를 만들고 싶다 !