[우아한테크코스 7기 프리코스] 3주차 회고

유소정·2024년 11월 3일
0
post-thumbnail

🙋 '함수 호출' 그리고 '함수 선언'의 위치

이번 미션에서는 두 가지 질문이 계속 떠올랐다. 바로 “이 함수를 어디에서 호출해야 할까?”와 “이 함수를 어디에 선언해야 할까?”라는 고민이었다. 클래스와 함수의 역할이 명확하지 않을 때 이런 고민이 생긴다는 걸 깨닫게 되었고, 깨달으며 얻은 인사이트를 정리해 보았다.

🚀 적절한 함수 호출 위치를 찾지 못했다

3주차 코드를 보면 적절한 호출 위치를 찾지 못해 결국 App 클래스의 run 메서드에 여러 기능의 호출을 몰아넣는 구조가 되었다. 특히 run 메서드 안에서 입력과 유효성 검사의 호출을 모두 처리하다 보니, 코드가 아래처럼 길어지며 가독성이 떨어지는 문제가 생겼다. 각 기능을 호출할 적절한 위치를 찾아야 했다.

run() {
	const 당첨금액 = 당첨금액을_입력받는_함수()
	당첨금액_유효성검사_함수1(당첨금액)
	당첨금액_유효성검사_함수2(당첨금액)
	당첨금액_유효성검사_함수3(당첨금액)
  	...
}

🚀 함수는 단일 역할을 수행해야 한다

처음에는 '당첨금액을 입력받는 함수' 안에 유효성 검사 기능을 포함시키면 될 것 같았다. 결국 유효성 검사를 통과한 결과가 필요했기 때문이다. 하지만 이 방식은 입력 기능이 단순 입력 이상의 역할을 하게 되어 함수의 본래 목적이 모호해질 위험이 있었다. 함수는 하나의 역할만 수행하는 것이 좋기 때문에, 이런 방식은 코드 설계 측면에서 적절하지 않다는 결론에 도달했다.

🚀 상위 함수로 역할을 명확히 할 수 있다

2주차 코드 리뷰를 하며 통찰을 얻었다. ‘각 함수가 하나의 역할을 하도록 잘 구성되었다면, 이제 이 함수들을 묶어줄 상위 함수가 필요하고, 그 상위 함수는 역할과 관련이 깊은 클래스에서 관리해야 한다’는 것이다. 이 접근법을 적용하니, run 메서드에서 모든 기능을 호출할 필요가 없어졌고, 각 역할에 맞는 클래스로 기능을 옮기면서 코드가 깔끔하게 정리될 수 있었다.

🚀 클래스의 역할이 명확해야 선언 위치도 명확해진다

이 과정에서 함수 선언 위치도 클래스의 역할에 따라 결정된다는 점을 깨달았다. 클래스의 역할이 불분명하면 함수 선언 위치가 애매해지기 마련이다. 하지만 역할이 명확해지니 각 함수의 위치가 자연스럽게 정리되었고, 코드의 구조가 한층 깔끔해지며 유지보수가 쉬워졌다.

🚀 전체적인 시야가 네이밍에도 도움을 준다

이 경험을 통해, 네이밍에서 넓은 시야가 중요하다는 점도 느꼈다. 처음에 입력 함수 이름을 'getUserMoney', 유효성 검사 함수 이름을 'validateUserMoney'로 지었다. 하지만 이 둘을 묶어 호출할 함수를 정하기가 어려웠다. 반면 묶음 함수가 있는 것을 고려해서 입력 함수 이름을 'readUserMoney'로 설정했다면, 묶음 함수 이름을 'getUserMoney'로 자연스럽게 지을 수 있었을 것이다. 전체적인 코드 흐름을 고려하면 네이밍을 일관성 있게 구성할 수 있음을 깨달았다.

🙋 다음 주차 목표: MVC 패턴을 적용해보기

2주차 회고에서 MVC 패턴이 필요하지 않다고 느꼈지만, 다음 주차에는 이 패턴을 적용해보기로 했다. 지금까지는 파일을 역할별로 나눴지만, 자유롭게 폴더명을 정하다 보니 'Utils' 폴더에 'Input.js', 'Output.js'와 같은 입출력 파일을 넣게 되었다. 리뷰어가 폴더명과 파일 내용이 일치하지 않아 혼란을 느꼈다고 했다. 이에 따라 정해진 패턴을 바탕으로 구성된 MVC 구조로 개선해보려 한다.

🙋 프리코스 목표: 마인드셋을 통한 오류 해결

프리코스 목표는 '한 미션 안에서 최소 3개 이상의 오류를 마인드셋 과정을 통해 해결하는 것'이었다. 1주차부터 3주차까지 발생한 오류들을 구글 스프레드시트에 기록하며 해결했고, 이제는 기록을 하기 전에도 머릿속에서 자동으로 오류 해결 단계를 밟는 과정이 떠오른다. 오류를 무작정 해결하는 것이 아니라, 문제를 먼저 이해하는 습관이 자연스럽게 자리 잡았다.

예를 들어, 이번 미션에서 [1, 2, 3].includes(값) 코드가 예상과 달리 'false'가 나오는 상황이 있었다. 예전 같았으면 console.log를 찍어보며 원인을 추측했겠지만, 이번에는 정상 동작을 생각해보고, 예상과 실제 동작을 비교하며 가능한 원인을 세 가지로 정리해 보았다. 그리고 VSC 디버깅을 통해 문제를 추적하니 값이 숫자가 아닌 문자열로 들어오는 버그를 빠르게 찾아낼 수 있었다.

이번 미션은 지난 미션보다 더 복잡해서 오류가 2개 더 발생했지만, 차근차근 잘 해결했다. 다음 미션에서도 마인드셋 과정을 적용해나갈 생각이다

🤔 다음 주차에 중점적으로 고민할 것

  • ApplicationTest 파일을 분석해 모킹 학습하기
  • 4주차에서는 클래스 역할을 명확히 하는 연습에 집중해보기
  • 상수를 비슷한 역할끼리 묶고 Object.freeze를 이용해 데이터 보호해보기
profile
기술을 위한 기술이 되지 않도록!

0개의 댓글