프로젝트 회고 4, 꿈에서도 코드 짜는 날들

 

정말이지 꿈에서도 문서작업과 코드치는 꿈을 꾼다.

일어나도 상쾌하지않아 전혀 

 

또 자려고 누울때 왜 갑자기 번뜩이는 좋은 생각이 떠오르는지!

 

 

'효율적인 일정관리' 기본 기능을 구현하되 강력하게 본 기능에 포커싱을 두자라는 것을 염두했다. 

해야할 건 완벽히 작업을 하고 그외 부가적인 기능을 보충하는 방면으로 잡았다.

기본에 충실하기

 

 

🌱 배운 것 & 🥐 좋았던 점

현재 프로젝트 일부 화면

• 프로젝트 내 하위업무 담당
  저는 하나의 프로젝트 아래에서 업무가 보이는 하위업무(task) 부분을 담당하게 되었다.
  하나의 게시글 밑에 사용자들이 각각 담당하는 업무들을 '진행 예정', '진행 중', '완료', '보류' 으로 상태값과 '긴급, 높음, 보통, 낮음' 으로 우선순위를 선택하여 작성할 수 있게 하였다. 프로젝트 내 담당 역할을 체계적으로 관리하고, 해당 프로젝트의 전체적인 진행률을 반영할 수 있도록 했다.
  
  
• 뜻대로 되지 않지 설계
  작업을 하던 중 순환 참조 문제로 인해 DTO를 만드는 것이 코드 관리에 더 효율적이라고 판단하여 분리하게 되었다. 

 

 

 

해결방법
DTO를 사용하면 엔티티 간의 직접 참조를 피하고 필요한 데이터만 추출하여 전달할 수 있으므로, 순환 참조 문제를 방지하고 코드의 유지보수를 더 쉽게 할 수 있습니다. 이를 통해 시스템의 안정성과 성능을 향상시킬 수 있습니다.

https://hstory0208.tistory.com/entry/SpirngJPA-Dto%EC%99%80-Entity%EB%A5%BC-%EB%B6%84%EB%A6%AC%ED%95%B4%EC%84%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

 

JPA를 사용하면서 DTO를 도입한 경험을 통해 몇 가지 중요한 점을 깨달았다. 

순환 참조 문제로 인해 DTO를 만드는 것이 코드 관리에 더 효율적이라는 사실을 알게 되었고, 이를 통해 데이터 전송을 보다 명확하고 안전하게 할 수 있었다.

특히, 데이터베이스 설계의 중요성을 실감하게 되었다. 처음에 엔티티 간의 관계를 충분히 고려하지 않고 설계한 결과, 순환 참조 문제를 겪었고, 이를 해결하기 위해 DTO를 도입하는 추가 작업이 필요했다. 이 경험을 통해 데이터베이스 설계를 처음부터 철저히 하고 엔티티 간의 관계를 명확히 정의하는 것이 얼마나 중요한지 알게 되었다.

또한, DTO를 사용하여 필요한 데이터만 추출하고 전송함으로써 데이터 전송 과정에서의 불필요한 복잡성을 줄이고, 코드의 가독성과 유지보수성을 높일 수 있다는 점도 배울 수 있었다.

 

• 프론트 설계
  팀원 중 한 명은 디자인이 가능한 능력자 친구가 있었고 난 그 디자인을 보여질 자신감이 있었다.
  물론 vue 프로젝트는 처음이라 시행착오가 많았으나 오랜만에 하는 ui작업으로 즐겁게 임했다.

뷰단 영역은 처음부터 주도적으로 설계하며 시작했다.

그래도 이전에 ui화면을 해봤다고 팀의 도움이 되고 싶어 아는 사람이 먼저하자는 마인드로 공통컴포넌트, 레이아웃, 페이지구성 등 밑작업을 해두어 팀원들이 바로 화면만 붙일 수 있도록 했다. 

 

• 프론트와 백
  프론트와 백엔드 간의 데이터 통신을 효율적으로 처리하기 위해 고민했다. 우선, 백엔드에서 데이터를 불러오는 과정에서 효율성을 높이기 위해 API 경로를 .env 파일을 생성하여 환경변수에 등록하여 관리하는 방법을 생각해보았다. 이를 통해 코드 중복을 피하고, 유지보수성을 높일 수 있었다. 문제 해결에 단순한 접근 방법이었지만, 고민은 오래 하였습니다. 특히, 프로세스 통일 방법에 대한 고민을 오랜 시간 동안 진행했던 것 같다.

 

🙄아쉬운 점

• 개발 
  예상과 달리 원활하지 않았다. 역시 쉽지 않아. CRUD 기능이 생각대로 되지 않아 속상도 했다.  계획한 대로 코드를 작성하고 기능을 구현하는 것이 예상보다 더 많은 시간과 노력이 필요했다. 특히, 생각지도 못했던 부분에서 에러가 발생한 것이 가장 아쉬웠다. 이는 사전에 충분한 계획과 테스트를 거치지 않았거나, 팀 내의 커뮤니케이션이 부족했을 수 있었다. git 관련 충돌이슈나 연관기능 작업 등 문제가 있었다. 문제상황에 대한 대비와 협업이 중요했다.
  
  
• 팀원들과 커뮤니케이션
   각자의 역할에 바빠져서 지속적인 업데이트 상황을 파악하는 것이 어려웠다. 이에 대한 해결책으로, 업무 시작 전에는 오늘 할 일 리스트를 공유하였다. 또한, 중간중간 휴식 시간을 갖으면서 각자가 어려움을 겪고 있는지 확인하고 문제 상황을 교류할 수 있도록 했다. 업무를 마무리할 때는 이전에 작성한 일일 보고서를 더 상세히 작성하여 진척도를 파악할 수 있었다.
  이러한 방식으로 누군가 작업에 어려움을 겪을 때 서로 도와줄 수 있었고, 상호보완하는 면이 있었다. 특히, 어려운 상황에서 도움을 주고 받으며 서로의 역량을 존중하고 배려하는 분위기가 조성되었습니다. 팀원들끼리 솔직하게 의견을 공유하고 소통하는 과정에서 더 많은 아이디어와 해결책을 찾을 수 있었다.
  

 

🚀앞으로

• WBS 확인하며 프로젝트 일정관리하기 
• 오류사항 확인

---

정말이다. 꿈에서 코드치는 꿈을 꿨다. 

아침에 눈을 뜨고 일어나 작업하고 눈 감기 직전까지 작업을 하고.. 날을 새워 밤샘 작업을 하는 건 아니지만 그만큼 고민하면서 열심히 작업했던 주간이였다.

 

지금은 달려야할 때다. 

본격적인 개발작업에 돌입한 만큼 구체화 시키는 작업을 진행중이다. 하면서 우리모두 생각지못한 난관에 부딪히며 문제사항들을 직면하고 해결해가는 과정을 겪었다. 작업을 진행하면서 구체화하는 과정을 거치고 있다. 작업하면서 다양한 문제들을 직면하고 또 해결하는 과정들을 보내고 있다. 

정말 팀원 모두가 적극적으로 프로젝트에 임하고 있다. 그 모습에 나 또한 더 열정적으로 열심히 했다. 

 

주간회의를 통해 점검하는 시간도 갖는다. 기능적으로 부족한 부분이 있는지 혹은 너무 과하게 시간투자하는 문제가 있는지 부족하지도 또는 욕심으로 일을 그르치지 않게 하고 있다. 작업이 진행될수록 부족한 면만 보이는 것 같아서 말이다. 

처음 설정한 방향성을 유지하고, 필요한 조정을 하며 프로젝트를 진행하고 있다.