우당탕탕 우테코 7기 1주차 프리코스 회고 🔥

안녕하세요, 개발하는 토마토 입니다 ! 우테코 프리코스 1주차의 과제가 빠르게 진행이 되고 어느새 오늘 2주차 과제가 오픈되는 날이네요☺️ 개발을 하면서의 느낀점 및 오전에 스터디 팀원들의 코드리뷰를 진행하며 느낀점 등 주간 회고를 진행해보려고 합니다!

 

이번 과제는 문자열 덧셈 계산기로, 기본 구분자 혹은 커스텀 구분자가 지정된 경우 사용자가 입력한 문자열을 구분자로 분리하여 숫자들이 합을 반환하는 계산기를 구현하는 과제였습니다!

 

📑 1. 요구 사항을 꼼꼼히 보고 기능 명세서를 작성하자

 

분명 요구사항을 꼼꼼히 봤다고 생각했는데, 빈 문자열을 0으로 반환해야 하는 요구 사항에 있어 실수를 해버렸습니다. 단순히 빈 문자열이 입력될 경우, 0으로 반환해야 하지만 유효하지 않은 값으로 에러를 던지는 실수를 하는 바람에,, 그걸 심지어 오늘 아침에 알았답니다 제출 후에,, 🥲 2주차 과제 부터는 기능 명세서에 예시로 준 케이스들도 꼼꼼히 적는 연습을 해야겠다고 생각했습니다!

 

-> 2주차 부터 적용해야 할 점 : 기능 정의 명확하게 하고 check list로 관리하기

🚨 2. 예외 처리를 잘하자

 

이번 과제 주제의 특성 상 "사용자가 잘못 입력한 경우" 에 대해 알아서 판단하고 오류케이스를 나눠보았어야 했습니다. 

아래는 맨 처음에 기능 명세서를 작성하면서 러프하게 작성해보았던 오류 케이스 입니다 🤔

// - 구분자를 입력하였으나 그 구분자로 구분이 불가능할 경우(숫자만 있고 구분자가 다르거나 없을 때)
// - 숫자 없이 구분자만 있는 경우
// - 기타 영문 등의 글자가 들어올 경우
// - 구분자가 여러 개 연속되어 나올 경우
// - 아무것도 입력하지 않을 경우
// - 기본 구분자가 아님에도 커스텀 구분자 양식을 지키지 않았을 경우

 

문제점

input 을 받고 바로 유효성을 따질 수 있는 조건 / 분리를 한번 거쳐야 따질 수 있는 조건 이 섞여있었고, 결국 후에 오류에 관한 조건문 분기처리를 할때 혼동이 많이 되었습니다.. 

 

-> 2주차 부터 적용해야 할 점: 오류 검사 시점에 대해 분리하고, 유효성 검사를 무조건 하나의 validate 함수에 두는게 아니라 기능 별 오류 검사로 쪼개어 파일을 구성하기

 

 

⛏️ 3. 함수의 기능을 명확히 하자

'하나의 함수는 하나의 기능을 해야 한다' 라는 말이 있죠 분명 저는 split(문자열 분리) 와 calculator (게산) 함수를 두개 두어서 이 부분을 정확하게 만족했다 생각했지만, 사실은 두 가지가 섞여버린 형태가 나왔습니다. 아래의 경우 문자열을 분리하는 split 함수에서 Calculator이라는 계산기 함수를 Import 해서 사용하고 있었습니다

 

 // split 함수의 일부분
 
 ***
 ///
 ***
 const splitedNum = splitedInputs.map((num) => Number(num));

 return Calculator(splitedNum);

 

-> App.js 에서 calculator 함수를 import 했으면 기능 분리가 더 명확했을 것!

 

문제점

1. 함수의 길이가 생각보다 길다.

이 부분 역시 함수의 기능이 한 개로 좁혀지지 않아 발생한 문제입니다.. 유효성 검사 함수 (validateInputs)에서 걸러지지 않은 부분에 대해 결국 커스텀 구분자인지 아닌지로 분기 처리 후에 다시 유효성 검사를 하게 된 경우가 있었습니다

 

 // 분리했더니 커스텀 구분자랑 다른 구분자가 있는 경우 에러

    const numTest = /^[0-9]+$/;
    splitedInputs.forEach((input) => {
        if (!numTest.test(input)) {
            throw new Error(
                '[ERROR] 커스텀 구분자와 다른 구분자로는 구분할 수 없습니다.',
            );
        }
    });

 

결국 문자열 분리 기능만 해야 했던 split 함수에서 유효성 검사까지 하게 되니 함수의 길이가 불필요하게 길어졌어요🥲

(이전 기수 과제에서는 함수의 길이가 최대 15줄이었던 제한이 있었는데, 만약 그 제한이 그대로 적용됐다면 요구사항 충족이 어려울 뻔,,)

 

-> 2주차 부터 적용해야 할 점 : 함수의 기능을 작게 쪼개기 위해 노력하기, 또한, 필요에 의한 것이 아닌 이상은 서로 혼용해서 ㅋ꙼̈쓰는게 아니라 App.js에서 import 해서 사용하는 방식을 취해보기

 

💡 4. 테스트 케이스 및 코드를 잘 활용하자

저는 이미 주어진 테스트 케이스의 양식만 가져다가 안에 테스트케이스의 내용만 살짝씩 바꿔서 넣었는데,, 다른 분들 Input,output 모든 단계에 테스트를 넣거나 테스트 파일을 추가적으로 만들어 두신 것을 보았습니다 ☺️ 테스트를 예외 처리를 위해서 오류케이스를 넣는 것으로만 생각해서 크게 구현은 하지 않았지만, 테스트 코드를 직접 짜는 것 역시 중요한 부분이라고 생각이 드네요!

  test('예외 테스트4', async () => {
        const inputs = ['//;\\n1;2;3:4'];
        mockQuestions(inputs);

        const app = new App();

        await expect(app.run()).rejects.toThrow('[ERROR]');

 

문제점

input, 계산 등 기능 단위로 쪼개서 테스트 코드를 작성해보지 않고 기존 양식을 그대로 쓴 것

 

-> 2주차부터 적용해야 할 점 : 테스트 케이스 기능 별로 나눠서 파일 만들고, 직접 짜보기

🏃‍♀️ 5. 현 상태에서 안주하지 말자

앞 선 내용들의 종합적인 항목이라고 할 수 있겠네요 ㅎㅎ 사실 오늘 아침 잘못된 부분이 있다는 걸 깨닫고 굉장히 침울했습니다.. 사소해보일지 몰라도 결국 요구사항 충족이 가장 중요한 부분인데, 그 요구사항을 순전히 실수로 놓쳤다고 생각하니 첫 단추부터 잘못 껴버린 느낌이 들었습니다 ,, 그치만 이미 1주차는 제출했고, 이미 잘못된 부분도 알았으니 2주차꺼부터는 더 열심히 개선해 나가야겠다는 생각이 들었어요 !

'아 잘못했으니 이제 끝이야' 라는 생각만 하게 되면 앞으로의 발전은 어렵다고 생각이 되기 때문에, 무조건 지금 실수를 기반으로 성장하겠다는 마인드로 더 몰입하는 2~4주차를 보내보려고 합니다. 사실 진짜 몰입했는가? 에 대한 질문을 하면 'Maybe' 정도로 답할 수 있을 것 같아요. GPT 도 사용하지 않으려 노력해보고, 여러 노력을 했다고 나름 생각했지만 '진짜 몰입했는가?', '더이상 이만큼 할 수 없다 라고 말할 수 있을 정도인가?' 라고 물어본다면 아닐 수도 있을 것 같더라구요 ☺️ 이것도 결국 제가 더 몰입을 할 수 있는 여지가 있다는 거니까 딛고 잘 일어서 보려고 합니다 !

잘하는 분이 굉장히 많고, 코드를 읽으면서 많은 것들을 생각하게 되었어요 , 이래서 코드리뷰가 중요하구나 싶었습니다 ㅎㅎ 내일 스터디원분들과 함께 주간 회고 및 코드리뷰를 진행하게 될텐데 두근거리기도 하고 걱정도 되고 하네요 🥹 하지만 이번주에 마음속에 새긴 "뭐가 됐든 즐기자" 라는 마인드로 헤쳐나가보겠습니다! 다들 2주차도 화이팅 :)