2022 마스터즈 코스(백엔드) 64일차 회고(2022. 4. 7.) - "일과 휴식의 균형"

해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)

 

수강 회고

오늘로 팀 프로젝트를 시작한지 벌써 4일차가 되었다. 지난 12주간 과정을 진행하면서도 시간이 빨리 지나갔지만 역시 프론트 엔드 팀원들과 함께 작업을 진행하면서 여러 논의들을 하다보니(몰입을 하다보니) 시간이 더욱 빨리 지나갔다. 자칫 지치기 쉬운 환경에 있지만 그래도 이번에는 같은 백엔드 팀원 Hanse와 협의하여 충분한 휴식 시간을 갖은 덕분에 한결 가벼운 마음으로 프로젝트에 임할 수 있었다.

 

프로그래밍을 하다 보면 몇시간이 훌쩍 가도록 몰입하게 되는 경우가 많이 있다. 물론 단기적으로는 컨디션에 큰 지장은 없을 수 있겠지만 프로그래밍은 장기전이다. 또한 코드스쿼드 마스터즈 코스 과정 역시 앞으로 약 3개월간 지속해야만 한다. 따라서 팀 프로젝트 과정을 최선을 다해 임하면서도 동시에 컨디션 조절도 잘 이루어져야 한다. 더욱이 지금은 팀 프로젝트 과정의 초반이므로 벌써부터 조급하게 그리고 무리해서 자신을 혹사시킬 필요는 없다는 생각이 들었다.

 

 

학습 회고

• 투두리스트 구현 프로젝트
  
  • 팀원들(백 엔드 2명, 프론트 엔드 2명)과 zoom 회의실에서 학습

 

SOLID란?

객체 지향 언어의 시초라고 하는 Simula67이 1960년 발표된 후 그동안 수많은 시행착오와 베스트 프랙티스 속에서 객체 지향 설계(OOD, Object Oriented Design)의 정수라고 할 수 있는 5원칙이 집대성됐는데, 이것이 바로 SOLID이다. SOLID는 로버트 C 마틴이 2000년대 초반 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙으로 제시한 것을 마이클 페더스가 두문자어(SOLID)로 소개한 것이다.

 

구분	요약
단일 책임 원칙 SRP(Single Responsibility Principle)	어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
개방 폐쇄 원칙 OCP(Open Closed Principle)	자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다.
리스코프 치환 원칙 LSP(Liskov Substitution Principle)	서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다.
인터페이스 분리 원칙 ISP(Interface Segregation Principle)	클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다.
의존 역전 원칙 DIP(Dependency Inversion Principle)	자신보다 변하기 쉬운 것에 의존해서는 안된다.

이 SOLID 원칙은 응집도는 높이고(High Cohesion), 결합도는 낮추라(Loose Coupling)는 고전 원칙을 객체 지향의 관점에서 재정립한 것이다.

좋은 소프트웨어 설계를 위해서는 결합도(coupling)는 낮추고 응집도(cohesion)는 높이는 것이 바람직하다. 결합도는 모듈(클래스) 간의 상호 의존 정도로서 결합도가 낮으면 모듈 간의 상호 의존성이 줄어들어 객체의 재사용이나 수정, 유지보수가 용이하다. 응집도는 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로, 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용이나 기능의 수정, 유지보수가 용이하다.

 

 

좋았던 점

• 오늘 같은 백엔드 팀원 Hanse와 협의하여 각자 충분한 휴식 시간을 가져 재충전할 수 있었습니다. 💪

 

 

아쉬웠던 점

• 오늘 팀 프로젝트를 진행하면서 '지금 당장' 구현하지 않아도 되는 기능에 대해 논의하느라 많은 시간을 소요하게 된 것(Time Loss)이 아쉬웠습니다. 😥

 

 

이전 보다 개선되었던 점

• 이전 보다 미션 추진에 급급하기 보다는 적당한 휴식 가져 재충전을 할 수 있는 마음의 여유를 가질 수 있었습니다. 🎈

 

 

참고자료

• 위키북스 출판 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'