연말 프로젝트 회고

안녕하세요 여러분 일단고팀입니다. 베하!

 

 

 

이제 2023년이 몇 일 남지 않았습니다. 다들 2023년은 어떠셨나요?

2024년에도 즐거운 나날을 보내셨으면 합니다.

2023년에 저는 개발에 대해 공부하면서 프로젝트를 많이 했습니다.

초보 개발자에게 현업 개발은 쉽지가 않았고 우여곡절이 너무 많았습니다.

프로젝트를 짧든 길든 참여했던 프로젝트가 무려 3개를 진행했습니다. (찍먹도 있습니다 ㅎㅎ)

오늘 글은 저의 이 3개 프로젝트에서 백엔드 프런트엔드 개발 작업을 진행하면서 개인적인 회고를 한번 적어볼고 공유해볼까 합니다. 2023년의 일단고 팀의 일단 가봤던 프로젝트 회고를 통해 깨달은 점을 2024년에 꼭 그 깨달음을 반영할 수 있는 사람이 되어야 겠습니다.

 

오늘은 앞 시간에 예고한 대로 저의 개인적이자 초보개발자로 현업 프로젝트에 참여하고 회고를 작성해볼까 합니다.

 

참여 프로젝트

1. 공공기관 발주 프로젝트
   1. 기존의 회사 어플리케이션을 오픈소스 라이센스로 변경해서 오픈하는 것이 목적이었습니다.
   2. 해당 프로젝트에서 Vue2를 통해 유료 라이센스를 무료라이센스로 변경하는 작업을 진행했습니다.
   3. 이때 vue2에 대해 많이 알게 되었고 지금도 사용중인 프레임워크로 잘 사용했던 것 같습니다.
2. 통신사 발주 프로젝트
   1. 가장 규모가 컸던 프로젝트로 기억합니다.(사실 찍먹했습니다)
   2. java를 통해 Spring boot 프레임워크로 프로젝트를 진행했고 기존 통신사가 가지고 있는 애플리케이션을 확장하고 보수하는 작업입니다.
   3. 이 프로젝트로 백엔드 mvc 형태에 대해 가장 많이 배웠고 소스작성법 및 트랜잭션 처리 , 대규모 데이터 이관에 대해 기초를 배울 수 있었습니다.
   4. 많은 고급 개발자 분들 아래에서 좋은 소스코드를 보기도 했고 가장 많이 성장했던 프로젝트가 아닐까 생각합니다.
3. 금융사 발주 프로젝트
   1. 규모도 적정한 프로젝트로 기존 애플리케이션을 private하게 이관하는 작업과 추가적인 새로운 개발을 진행했습니다.
   2. 이때 vue, spring boot를 모두 사용하면서 풀스택 개발을 진행했습니다.
   3. 먼가 재밌었고 힘들었던…. 느낌이고 2023년의 마무리 프로젝트 입니다.

 

프로젝트로 느낀점

전체적으로 현업 프로젝트 3개를 하며 느낀점 및 저의 개발 회고를 통해 더 나은 개발을 해보자 생각하며 여러분들도 잠시 생각을 해보고 저의 느낀점을 통해 개선을 해보면 어떨까요? 물론 저는 초보 개발자로 당연한거 아니야? 라고 생각하시겠지만 다른 초보 분들이 있다면 도움이 되었으면 합니다.

 

1. 백엔드 개발시 응답 model(resultModel)을 사용하자.

제가 백엔드를 개발시 controller, service ,repository 구조로 처음부터 끝까지 개발 할 때 요청에 대한 응답을 그저 필요한 데이터만 던져 주었습니다.

이때 큰 문제는 못느꼈지만 백엔드 작업을 끝내고 프런트 작업을 진행할 때 응답 모델의 중요성을 알게 되었습니다.

{
	"status" : "OK"
  "Data" : {

	}
}

{
	"status" : "ERROR",
  "message" :{
		"code" : xxxx,
    "message" : "xxxxxx" 
	}
}

위와 같은 모델이 중요했던 이유는 프런트에서 좀 더 사용자 친화적인 형태를 구현할 때 매우 중요했습니다.

정형화된 응답 모델을 통해서 문제가 발생시 그 문제에 대해 프런트에서 처리하기 용이하고 코드의 유연성이 증가한다고 깨달았습니다.

2. 이름은 자식이름을 짓는 것 처럼.

api 이름, method, 변수 등 급해서 막 짓거나 나는 아는데? 정도로 작성하면 협업에 있어 시간이 너무 많이 잡아먹힙니다.

개발이 바쁜 상황에서 사치일 수 있지만 추후 유지보수시 아마 절실히 느끼게 됩니다. 이름을 잘 지어야 금방 찾고 금방 적응합니다. ㅠㅠ

그리고 API는 반드시 RESTFUL 하게

3. 백엔드에서도 제한사항을 반영

제한사항 및 예외? 같은 상황에 대해서 프런트에서 방지를 하지만 백엔드에서 반드시 반영을 해야겠다고 생각했습니다.

프런트에서 제한을 하더라도 api를 통해서 언제든지 예외사항 및 제한사항이 백엔드에서 처리되어 데이터가 이상하게 처리 될 수 있습니다.

4. 초기 DB 설계

DB 스키마 정의는 정말 어려운 영역이 아닐까 생각합니다. 이 설계에 따라 저의 개발이 좌지우지 되었던…. DB 설계가 잘 되어 있지 않으면 비즈니스 로직에서 크리틸컬 한 에러가 발생했었던…

5. 함수화

저는 이것을 가장 중요하게 생각하고 개발을 했었습니다.

사람이 걸을 수 있을 만큼 작은 계단 여러 개를 쌓아 높이 올라갈 수 있듯이 쪼갤 수 있다면 작은 도메인 기능 단위로 나누었으면 합니다.

문제가 되는 부분을 금방 찾을 수 있고 재사용 기회가 많아짐을 알았습니다. 관리 포인트가 많이지는 느낌이지만 문제 발생시 가장 빠르게 대처가 가능했던 경험이 있습니다.

이것은 프런트 백엔드 모두 포함되는 내용으로 vue에서도 최대한 method를 사용해서 데이터와 동적화면을 만들었습니다.

method 뿐 아니라 프런트에서 컴포넌트 같은 것도 재사용을 생각하고 개발하면 컴포넌트를 만들 때 힘들지만 다른 분들 혹은 제가 다른 곳에서 사용할 때 매우매우 편리하게 사용할 수 있습니다.

6. 일정관리 매우 중요

현업에서는 결국 일정관리 입니다. 프로젝트 관리 tool을 이용해서 프로젝트를 추적하기도 하고 현재 현황과 앞으로 대응 방안도 모색할 수 있습니다. 저는 일정관리가 되지 않았던 프로젝트에 투입되면서 정말 많은 변경사항을 마주했기도 하고 일정이 심각하게 밀리는 프로젝트를 했습니다…. 퇴근이 쉽지가 않더군요

7. 요구사항과 고객 미팅은 문서로 남기자.

문서화는 중요합니다. 어떤 내용에 대응하기 위한 근거 사항이 되며 동시에 문서를 통해 빠르게 팀원들 및 고객에게 전파할 수 있습니다.

고객은 착하지 않습니다. 팀원은 엄청난 천재가 아닙니다! 문서화를 통해 근거를 남기고 공유해야 합니다.

8. 모듈 사용은 코드 및 문서읽기

저는 vue를 사용할 때 검색기능을 추가해야 했었는데 이때 생각보다 시간이 많이 걸렸습니다. 그런데 제가 사용하던 컴포넌트의 소스코드를 나중에 되어서 읽어보니 검색기능이 boolean을 통해 지원하고 있음을 깨닫고 허탈함을 감출 수 없었습니다.

모듈을 다운해서 컴포넌트로 사용 시 문서가 있다면 문서를 읽고 코드도 반드시 한번 읽어보면 지름길을 찾을 수 있을 것입니다.

9. 주석 좀 달자….

통신사 프로젝트를 할 때 알게 되었습니다. 각 method 부분 마다 기능을 설명하고 그 안에 작은 구조 마다 소스 코드의 의도를 작성하는 것을 보았습니다.

이 주석들은 나중에 해당 기능을 찾을 때, 해당 기능의 flow를 파악해야 할 때 굉장히 유용하게 사용되었고 특히나 협업시 굉장히 중요합니다. 흔히 ‘클린코드’라 해서 코드를 아무리 잘 작성해도 한글만큼 편하진 않습니다.

/**
* 주석을 생성하는 함수
* @Params String : 코멘트
* @Return Object
*/
public Object makeComment(String comment){
  // comment에 앞뒤 공백이 들어 갈 수 있어서
	comment.trim()
}

저는 위와 같이 주석을 사용합니다. method의 기능을 설명하고 method 안의 코드는 의도를 바탕으로 큰 단락을 나누어서 주석을 작성합니다. (한 코드에 주석 하나를 작성하면 더 보기가 힘들어집니다!)

10. 프런트는 사용자의 것이다.

사실 정의된 화면 설계서 대로 화면을 만들었는데 결국 질타를 받으면 개발자가 받습니다. 프런트를 개발 할 때 화면설계서를 바탕으로 사용자가 얼만큼 편하고 쉽게 사용할 수 있을까가 굉장히 중요합니다.

사실 프런트를 개발하면 보이는게 많아서 재밌고 이것저것 해보고 새 기능도 넣어보고 했습니다. 사실 이것은 개발자로써 생각이지 사용자로써 굉장히 불편한 기능이 될 수 있습니다.

아무것도 모르는 사용자가 처음 접속을 했을 때 눈에 쉽게 들어오고 사용도 쉽게 되게 개발을 하는게 가장 중요하고 그것을 위해서 프런트 기술이 존재함을 잊지 않아야 합니다.

11. 백엔드 개발 시에는 의도적으로 log를 남겨야 편하다.

금융권 프로젝트는 원격지에서 push하고 빌드하고 테스트 할 수 없고 현장에서 진행해야 했습니다. 그리고 그 시간 자체가 오래걸리기 때문에 한 부분을 개발하고 테스트하기가 많이 힘들었습니다. 그래서 의도적으로 개발을 할 때 log.info 또는 System.out.println을 통해서 http 통신의 페이로드 확인 및 model의 현재 데이터 구성을 파악해서 문제를 찾고 해결한다면 좀 더 많은 기능을 일괄적으로 고치고 현장에서 빌드 후 테스트 할 수 있다고 느꼈습니다.

12. 기술의 사용 방법보다 기술의 탄생 배경

특정 기술을 사용해야 할 때 사용 방법보다 그 탄생 배경을 알면 나중에 그 기술을 잊지 않을 수 있고 더 자유롭게 사용할 수 있습니다.

대부분 git이나 다른 곳에서 다운해서 가져올 때 탄생 배경들이 존재합니다. 그 부분을 읽고 나서 사용방법을 파악한다면 어떻게 사용해야 더 좋은 결과를 가져올 수 있을지 알게 될 것 입니다.

 

 

저의 느낀점은 여기까지 입니다. 어쩌면 저건 아닌데, 저건 당연한데 할 수 있지만 저 같은 초보에게는 배워가는 과정이라고 생각해주시고 고수님들이 계시다면 댓글로도 알려주시면 생각해보고 배워보겠습니다!

 

 

2023년 btc와 일단고 모두 고생하셨고 이 글을 읽는 모든 독자들도 고생 많으셨습니다. 2024년에 새롭게 만나 뵙겠습니다.

새해 복 많이 받으세요! 저도 새해 복 다 가져보겠습니다 ㅎㅎ.