새 프로젝트에 임하는 초년 개발자의 마음가짐(?)

서론

입사한지 이제 4개월 남짓..

드디어 개발 한 사이클을 돌릴 수 있는 

사내 전사 시스템의 완전개편 !! 에 대한

새삥 프로젝트를 시작하게 되었다.

 

 

 

 

서버 / 파이프라인 구축부터 하나하나 다 직접 해볼 수 있는 값진 기회가 될 것 같다.

 

오래된 기존 서비스 코드는 컨벤션도 딱히 없고, 앞 번 개발자의 스타일에 따라 이리저리 막 작성되어 있어서

특히 어느 순간부터 단순 쿼리문을 사용하는 게 편했던건지

DB Access를 단순 쿼리로만 작성해놔서 쿼리빌더로 짬날 때 마다 변경하는 수고로움을 요구했다..

 

 

---

 

 

목표

 

업무를 하면서, 항상 새 프로젝트를 시작하면 반드시 수행하려고 했던 것들을 정리해놨었다.

 

1. 프로젝트 컨벤션 문서화하기

2. 사소한 것도 문서화하기

3. 프로젝트 구조에 대한 고민 녹여내기

4. 로깅 확실하게 해보기 ( 시간 나면 시각화까지 )

5. 에러 명세 잘하기

 

이 중 4, 5번에 대한 인사이트는 각각 배민 기술블로그와 향로님의 블로그에서 인상깊게 읽고

따로 기회가 있으면 적용해보고자 메모해뒀었는데 드디어!!!

 

따끈따끈한 전사 로그 시스템 전환기: ELK Stack에서 Loki로 전환한 이유 | 우아한형제들 기술블로그

 

좋은 예외(Exception) 처리

 

 

 

모든 것을, 같이 협업하는 백엔드 개발자 분이 없기 때문에

백엔드에 대한 컨벤션은 혼자 헤쳐나가야 된다는 문제가 있지만...

(아예 고착화돼서 다른 시도를 안할까봐 / 내 것이 맞다고 자연스레 여길까봐에 대한..)

일단 부딪혀보기로?

 

어떤 것이든, 고민한 것을 해결하는 과정을 정리하면서 나아가기로...

 

 

 

 

추가(24.01.10)

 

협업하는 백엔드 개발자는 없지만.. 그래도 뭔가 규칙을 확실히 잡는 습관을 들이는 것이 중요한 것 같아

(만약 옳지않은 규칙이라도...(?))

 

컨벤션을 작성해서 README에 올려놓았다.

 

커밋 규칙과 브렌치 전략은 좀 오래되긴 했지만, 각 아래 포스팅에서 참조했다.

[협업] 협업을 위한 git 커밋컨벤션 설정하기

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그