개인 프로젝트 회고 (2일차)

<회고록>

오늘은 Todo-List를 만들면서 겪었던 트러블 슈팅에 대해서 정리하려고 한다. 트러블 슈팅은 신입 개발자로써 성장할 수 있는 아주 좋은 양분이다. 즉 신입 개발자에게 트러블 슈팅이란 우리가 일상적으로 먹는 밥 같은 존재다. 맨날 마주치면서 우리를 성장시켜주는 촉진재인 셈이다. 그래서 오늘은 겪어던 트러블 슈팅들에 대해서 적어볼려고 한다.

<트러블 슈팅>

1. 문제상황

 

• 컴포넌트 분리는 사실 정답이라고 하는 것은 없다. 하지만 나중에 프로젝트가 커졌을 때 확장성에 유연한 프로젝트가 되는 지, 확장성에 유연하지 못한 프로젝트가 되는 지는 컴포넌트 분리가 결정한다.
• 내가 만들려고 하는 헤더의 영역을 캘린더 까지를 헤더로 볼 것인지 , 아님 제목 영역 까지로 봐야할 것인지에 대한 설계에서의 문제가 발생함

2. 해결 방법

 

• 문제상황을 가지고 크게 2가지 대안을 생각함
• 헤더 영역을 캘린더까지로 생각
• 헤더 영역을 제목까지로 생각

3. 결과

 

• 헤더 영역을 캘린더까지로 생각했을 때 나온 결과
  • 장점
    • 폴더 구조를 잡을 때 더 명확해짐 ⇒ 아키택쳐 설계를 할 때 각각의 역할들이 명확해짐
    • 단일 책임을 강조할 수 있었음
  • 단점
    • 헤더 영역이 무거워진다는 점
    • 헤더 영역의 로직 및 컴포넌트의 수가 많다는 점
• 헤더 영역을 제목까지로 생각
  • 장점
    • 헤더 영역이 가벼워진다는 점
    • 헤더 영역의 로직 및 컴포넌트의 수가 적다는 점
  • 단점
    • 폴더 구조를 잡을 때 모호해짐 ⇒ 아키택쳐 설계를 할 때 각각의 역할들이 명확해지지 않음
    • 단일 책임을 강조할 수 없었음
• 나의 선택
  • 헤더 영역을 캘린더까지로 생각
    • 이유 : 코드가 길어진다고 해서 이 코드가 클린코드가 아니라고 생각하는 것은 잘못된 생각이다. 아마도 이런 생각이 나온 이유는 코드가 길어지면 내가 원하는 코드를 찾기 힘들고 유지보수 적인 측면에서 어려워진다는 생각으로 인해서 이런 결과가 나온다고 생각함. 하지만 코드가 길어진다고 해도 하나의 역할이 명확하다면 즉 단일 책임의 역할이 명확하다면 나는 이 코드도 클린코드라고 생각함. 나중에 확장성을 위해서는 단일 책임의 역할이 명확한 코드가 가능성이 높음. 따라서 나는 나중에 확장성을 위해서 위 방안을 선택함