오늘의 생각
피곤한 하루다..."간단한" 웹앱 만들기로 계산기를 만들어 보았는데...기능 구현에 엄청 애 먹었다. 기본적인 구현은 쉬운 편이었는데 이후 심화 과정(자율인데 이제 열정을 곁들인)은 어려웠다. 오늘 함께한 페어 분도 함께 심화 과정에 뛰어들었는데, 함께 으쌰으쌰하면서 묘한 전우애를 느낄 수 있었다. 같이 고통스러워하니 조금 덜 힘든 것 같기도 했다...기본적인 코드가 완성된 템플릿을 기반으로 시작했기 때문에 처음에 html/css/js 구조를 침착하게 파악해 나간 것이 성공 요인이 아닐까.
과정
만들었던 계산기의 기본 원리 같은 경우 각 버튼의 "click" 이벤트가 발생했을 때 이벤트리스너 기능을 구현하는 것으로, 먼저 클릭된 HTML 요소(버튼들)의 클래스 정보를 가져왔고, 이에 따라 숫자/연산자/소수점/초기화/발행(계산)으로 분류해 각 버튼에 알맞은 기능을 구현하는 게 핵심이었다.
먼저 주어진 변수가 어떤 요소나 값에 할당되었는지 확인해 보았다.
display같은 경우 .textContent 속성을 활용하기 위해 주어진 것으로 보였고, 네 변수는 임의로 그 값을 할당해 계산기의 사칙 연산을 해결하는 데 도움이 될 것처럼 보였다. 특히 prevAction 변수는 이전에 누른 버튼 이벤트(action)의 저장값으로 이벤트 핸들러 역할의 변수로 보였다.
이벤트 리스너 내부에 주어진 변수는 미리 HTML태그에 부여한 각 클래스를 가져오는 변수와 현재 이벤트 타겟의 텍스트 컨텐츠를 가져오는 변수들이었다.
먼저 주어진 구조를 파악한 후에는 각 상황에 맞는 코드를 작성하면 됐다.
다섯가지 조건문을 보고 난 후 먼저 기본적인 기능들을 구현했고, 이후에 본격적인 테스트 케이스를 통해 기능을 세분화했다.
- 화면에 누른 버튼의 숫자 입력 (연속으로 숫자를 누를 시 결합)
- 계산 및 초기화 기능 구현
- 연산자를 활용한 사칙연산 구현
여기까지가 Advanced 레벨이었는데 생각보다 시간이 걸렸지만 엄청 어렵지는 않았다. 조금 막히는 부분이 있더라도 다시 한 번 생각해보면 풀 수 있을 정도라 꽤 자신만만해진 게 사실이다. 그런데 이게 왠걸, Nightmare 레벨이 나를 반기고 있었다.
Advanced 수준이 기본적인 기능 구현이었다면, Nightmare의 경우 좀 더 다양한 경우에 대한 에러를 대비하고 기본적인 논리 구조에서 발생할 수 있는 문제점들을 짚어주고 있다. 대표적으로 연산자를 연속해서 눌렀을 경우 가장 마지막에 눌린 연산자로 사칙연산을 실행할 수 있게 논리적으로 보완해야 했다. 이 외에도 여러가지 테스트 케이스를 해결해야 했는데, 그 중 몇 가지 에러는 해결하는데 너무나도 어려웠다.
특히 마지막에 2시간 넘게 한 개의 테스트 케이스 때문에 계속 JS를 뜯어보고 고민해봐야했는데, 그 과정이 너무나도 고통스러웠다. 연산자를 연속해서 쓸 때 '계산' 버튼을 누르지 않아도 자체적으로 연산값을 누적해야 하는 것이 테스트 케이스가 확인하고자 하는 것으로 보였다.
먼저 테스트 케이스가 원하는 바를 파악한 후, 어떤 식으로 문제를 해결해야할 지 좋을지 그 과정을 순서대로 적어보았다.
- 연산자에서 Enter(계산) 버튼을 누르지 않아도 연산자에서 이전 수를 기록 -> prevAction이 "연산자"일 때의 if문에서 구현
- 이전 수를 기록할 때 기존의 [계산]함수를 활용해서 사칙연산 -> firstNum, secondNum 변수에 할당
- 연산이 된 수를 기억해 놓은 후 이후 계산 버튼 없이 연산자가 눌렸을 때 계속해서 누적 -> prevAction을 확인해서 사칙연산 여부를 결정
이미 계산기가 기능적으로 대부분 구현되어 있기 때문에 연산과정을 실시간으로 확인할 수 있었는데, 아니나 다를까...에러가 우후죽순 일어났다. 기존에 통과했던 테이스 케이스들에서도 에러가 발생했고, 무너져 내려가는 내 논리 구조에 멘탈이 흔들렸다. 새롭게 적은 코드야 지우면 됐지만...기존의 논리 구조를 헤치지 않으면서 새로운 테스트 케이스를 통과시키는 게 생각보다 어려웠다.
오랜 시간 검색 끝에 알아냈던 사실은 기존 논리 구조에서 "이전 수를 기록 할 때"에 이전 수(firstNum)을 현재 연산자를 활용해 새롭게 입력된 수(secondNum)와 미리 계산을 해 이전 수를 계산값으로 재할당 시켜야한다는 사실이었다. 하지만 어째선지 계속해서 논리 구조에 문제가 생겼다. 오랜 시간 코딩에 지친 것이었을까, 쉽게 답이 나오지 않았다.
잠시 휴식을 취하며 쌓였던 스트레스를 조금 가라 앉혔다. 스트레칭도 하고, 시원한 물 한 잔, 그리고 바로 코딩에 들어가지 않고 남은 일과를 마무리하면서 고민해봤다. 어떤 게 문제였는지, 코드를 하나하나 뜯어보기보단 전체적인 논리 구조에 어떤 문제점이 있었는지 생각해 보았다.
순간 아이디어가 번뜩였다.
그리고 기존의 논리 구조를 천천히 살펴보면서 기존의 과정을 수정했다.
- 연산자에서 Enter(계산) 버튼을 누르지 않아도 연산자에서 이전 수를 기록
- firstNum이 첫 연산자 버튼을 눌렀을 때 할당된다. -> secondNum을 연산자 버튼 이후 숫자 버튼이 눌렸을 때 현재 디스플레이 값을 할당 -> 이 값을 이후에 다시 연산자 버튼이 눌렸을 때 if문 조건으로 통과
- prevAction이 "연산자"일 때 먼저 secondNum 값이 할당 되어 있는지 (!== undefined) 확인
- secondNum 값이 할당되어 있으면 "연산자" 버튼이 연속으로 눌렸는지 확인 (prevAction은 해당 버튼이 눌릴 때 클래스 명과 일치하게 값을 재할당 하고 있다)
- 이전 수를 기록할 때 기존의 [계산]함수를 활용해서 사칙연산
- 앞의 두 조건이 모두 만족되면 (secondNum 값이 할당이 되어 있고, prevAction이 "연산자"로 눌려있지 않을 때, 즉 숫자 버튼이 눌려있고 연산자가 새롭게 눌렸을 때) 기존의 숫자(fistNum)을 *[계산] 함수를 활용해 새로운 값으로 할당 *[계산(firstNum, operator, secondNum)]
수정된 과정에서 초기화 버튼에서 초기화 시 각 숫자 값이 "0"이 아닌 undefined로 수정이 되었고, [operato = buttonContent]로 지정하는 것과 [prevAction = "operator"]로 설정하는 코드의 배치가 바뀌었다.
그리고...됐다. 모든 테스트 케이스에 초록불이 들어왔다.
이 맛에 개발자 하나 싶다...누구에겐 너무나도 간단한 논리 구조인데 이게 뭐라고...진짜 방방 뛰었다. 뿌듯한 하루였고, 포기하지 않은 내가 대견했다. 함께 페어분이 고생해서 어떻게든 해결해보고 싶다는 욕심과 스스로 레퍼런스 없이도 풀 수 있었다는 성취감이 들어 짜릿한 하루였다.
'개발자 일기 > 일일회고 (TIL)' 카테고리의 다른 글
부트캠프 11일차 (배열) (0) | 2022.09.02 |
---|---|
부트캠프 10일차 (CLI, Node.js, Git) (0) | 2022.09.02 |
부트캠프 8일차 (CSS 활용 2) (0) | 2022.08.30 |
부트캠프 7일차 (CSS 활용) (0) | 2022.08.30 |
부트캠프 6일차 (CSS 기초) (0) | 2022.08.26 |
댓글