🙋 이 글을 쓰는 이유는?
2024년 10월 15일 ~ 11월 11일 기간 동안에 우아한테크코스 7기 프리코스에 참여합니다. 프리코스 기간인 4주를 의미있게 보내기 위해서 매주 회고를 작성하겠습니다.
과제 진행 소감에는 미션을 진행하면서 느끼고 배운 점, 많은 시간을 투자한 부분 등도 포함하면 더 좋을 것 같습니다. 🙂
🙋 미션을 어떻게 풀어나갈까?
이번 미션을 시작하며 가장 먼저 한 일은 요구사항을 꼼꼼히 읽는 것이었어요. 단순히 주어진 기능을 구현하는 것에서 끝나지 않고, 이 프로젝트가 어떤 프로그래밍 방식을 지향하는지 파악하는 데 집중했습니다.
그 과정을 통해 핵심적인 세 가지 질문을 뽑아냈고, 이 질문들에 답을 찾아가며 미션을 진행해나갔어요.
- 기능을 구현하기 전에 기능 목록을 만들 수 있나요?
- 기능 단위로 커밋할 수 있나요?
- 기능 요구 사항에 기재되지 않은 내용은 스스로 판단할 수 있나요?
👨🚀 1. 기능을 구현하기 전에 기능 목록을 만들 수 있나요?
핵심 기능을 먼저 도출하고 이를 목록으로 정리하는 작업에 집중했어요.
🚀 '문자열 덧셈 계산기'의 핵심 기능은 뭘까?
이번 과제는 '문자열 덧셈 계산기'를 구현하는 것이었어요. 가장 중요한 기능은 문자열을 더하는 것이었고, 그래서 제일 먼저 '두 문자열을 더하는 기능'부터 고민했죠.
만약 이런 핵심 기능에 집중하지 않았다면, 프로그램 흐름상 먼저 떠오르는 '입력 처리'부터 구현했을 거예요. 하지만 가장 중요한 것은 '사용자에게 직접 가치를 주는 핵심 기능'이라는 것을 깨닫고 덧셈 기능부터 시작하게 되었습니다.
🚀 '사람의 관점'에서 기능 목록을 작성해볼까?
프로그래밍하기 전에 노트에 직접 문제를 풀어가며 필요한 기능을 하나씩 정리해봤어요. 사용자가 어떤 흐름으로 이 프로그램을 이용할지 생각하며 사람 관점에서 기능을 설계하려고 노력했죠.
모든 기능과 예외 상황을 완벽하게 생각하지는 못했지만, 이를 '버전 1'이라고 여기고 점진적으로 개선해나가는 방식을 택했습니다.
만약 이런 구체적인 구상이 없었다면, 아마 처음부터 'split' 내장 함수를 써서 문자열을 나누었을 겁니다. 하지만 split을 사용하면 음수 처리와 같은 예외 상황을 더 복잡하게 만들어버리더라고요. 대신 for문을 사용해 문자를 순회하며 '-'를 슬레시 같은 특수 기호로 인식하면, 불필요한 예외 처리가 필요 없어졌어요. 이 과정을 통해, 미리 고민하고 설계하는 중요성을 느낄 수 있었습니다.
👨🚀 2. 기능 단위로 커밋할 수 있나요?
기능 단위로 커밋하라는 요구사항은 다음과 같이 해석했어요.
하나의 기능을 구현하고 하나의 커밋을 남긴다.
⇒ 하나의 기능이 하나의 역할을 담당하도록 한다.
⇒ 한 번에 처리하기 어렵다면 기능을 더 작게 나눈다.
이 방식을 적용하면서 깨달은 점은, 커밋마다 의도가 명확하다는 것이었어요. 특정 시점으로 돌아가거나, 코드를 추적할 때도 훨씬 편리하겠다는 생각이 들었습니다.
🚀 TDD 방식을 이용해보자
TDD 방식을 활용해 기능 단위로 작업을 나누고 커밋했어요. 사실, 테스트 코드를 작성하는 것도 처음이라 조금 낯설고 어려웠지만, 직접 해보니 여러 가지 매력과 장점을 느낄 수 있었습니다.
- 한 함수가 한 가지 기능에 집중하도록 설계할 수 있었어요.
- 테스트가 통과하는지 빠르게 피드백을 받아, 점진적으로 코드를 완성할 수 있었어요.
- 리팩터링 시에도 테스트 코드가 기존 기능을 잘 유지하는지 보장해주니 안심할 수 있었어요.
이번 경험 덕분에 TDD가 단순한 테스트 도구가 아니라 개발 전반에 안정성을 부여하는 방식임을 깨달았어요. 앞으로의 미션에서도 이 방식을 활용할 계획입니다.
👨🚀 3. 기능 요구 사항에 기재되지 않은 내용은 스스로 판단할 수 있나요?
'사용자가 잘못된 값을 입력할 경우'를 처리해야 했어요. 평소 풀던 알고리즘 문제와는 달리, 현실적인 불확실성이 있는 문제였습니다.
특히, 공백이 들어오거나 잘못된 구분자가 입력될 때 어떻게 처리할지 고민하면서, 어떤 값이든 들어올 수 있다는 전제를 두고 예측하고 대비하는 훈련이 필요하다고 느꼈어요.
그리고 이런 고민들이 쌓여야 사용자 관점에서 더 나은 프로그램을 만들 수 있겠다는 생각이 들었습니다.
🙋 프리코스 목표 설정, 돌아보기
이번 프리코스에서 저는 자기소개서에 작성한 목표를 바탕으로 미션을 수행했습니다.
- 프리코스 목표
- 한 미션 안에서 최소 3개 이상의 오류를 마인드셋 과정을 통해 해결하는 것
- 성공 여부
- 성공 O 🎉
- 기록
🚀 마인드셋 과정
- 1단계: 해결하고자 하는 문제를 한 문장으로 정리합니다.
- 2단계: 올바르게 동작한다면 어떤 일이, 어떤 순서로 벌어져야 하는지를 명확히 서술합니다.
- 3단계: 원인이 될 만한 옵션들을 나열합니다.
- 4단계: 나열한 옵션 중 하나를 선택하여 가설을 세우고 검증합니다.
🚀 이번 미션에서 겪은 오류와 해결
이번 미션에서는 3가지 오류를 마인드셋 과정을 통해 해결했어요.
모두 외부 라이브러리(ESLint 설정, Jest 사용)와 관련된 오류였는데, 이 문제들은 원인을 바로 알려주지 않아서 해결이 쉽지 않았어요.
하지만 단계별로 원인을 분석하고, 하나씩 시도해보니 의외로 빠르게 해결할 수 있었어요. 이런 경험을 통해, 문제를 풀 때 차분하게 접근하는 것의 중요성을 느꼈습니다.
또한, 해결 과정을 기록으로 남기니 다음에 같은 문제가 발생하더라도 자신감 있게 해결할 수 있을 것 같더라고요.
🚀 다음 목표
이번 목표인 오류 3개 해결이 적당하다고 느꼈고, 다음 미션에서도 같은 목표를 유지하며 진행하려고 합니다.
🙋 다음에는 무엇을 시도해볼까?
🚀 최소 한 분에게 명확한 의도가 담긴 변수명을 짓는 방법 여쭤보기
이번 미션을 진행하면서 변수명을 개발자의 의도가 잘 드러나게 짓는 것이 쉽지 않다는 걸 느꼈어요. 그래서 1주차 미션이 끝나면 다른 사람들의 코드를 보며 변수명이 개발자의 의도를 얼마나 명확하게 드러내는지 중점적으로 살펴볼 계획입니다.
특히, 명확한 의도가 담긴 변수명을 발견하면, 그분이 어떤 과정을 거쳐 그런 이름을 지었는지 직접 질문해보려 해요. 최소 한 분에게라도 직접 물어보면서 좋은 변수명을 짓는 방법을 배우고 싶습니다.
🚀 파일 구조에 대해 고민해보기
이번 미션에서는 모든 기능을 하나의 파일에 작성했지만, 다행히도 가독성에는 큰 문제가 없었어요.
하지만 다음 미션에서 더 복잡한 문제가 나온다면, 효율적인 파일 구조에 대해 고민해보려 합니다.
🍵 마무리
이번 미션에서 가장 크게 얻은 교훈은 바로 ‘프로그래밍을 멈추고 생각하기’의 중요성이었어요.
출제 의도를 고민할 때, 요구사항을 분석할 때, 손으로 프로그램을 설계할 때, 그리고 디버깅의 원인을 찾을 때까지, 잠시 멈춰서 정리하는 시간이 필요하다는 것을 느꼈습니다.
무작정 코딩을 시작하면 머릿속에 명확한 그림이 없어서 결국 진행이 막히고 비효율적이더라고요. 반대로, 의도와 목적이 분명해지면 작업에 더 깊이 몰입할 수 있었고, 진행 과정이 훨씬 매끄러워졌어요.
이번 미션을 바탕으로, 앞으로도 프로그래밍하기 전에 충분히 고민하고 계획하는 습관을 유지하려 합니다.
