본문 바로가기
개발자 일기/일일회고 (TIL)

부트캠프 12일차 (객체)

by MS_developer 2022. 9. 5.

 

큰 깨달음

오늘의 생각

오늘도 페어 프로그래밍을 진행했는데, 마지막 문제에서 고생했다. 문제 자체가 꽤 까다롭고 요구하는 논리 구조는 이해했지만 그 결과값을 찾는데 어려움이 있었다. 오랜 고민 끝에 페어 분과 함께 레퍼런스를 보기로 했는데, 생애 최초로 레퍼런스를 보고 답을 알게 되자 아쉬웠다. 왜 논리 구조를 올바르게 생각하지 못했나 싶으면서도 조금 더 붙들어 볼 걸 하는 마음이 들었다. 30분 이상 막히면 레퍼런스를 보는 걸 권장했고, 마땅한 답이 나오지 않았기 때문에 레퍼런스를 보는게 합리적이고 생산적인 선택이 맞았지만...스스로 답을 구하지 못한 것에 아쉬움이 들었다. 

 

그래도 아쉬운 마음에 적었던 코드를 다시 내가 생각했던 논리 구조에 맞춰서 적어보았다.

 

그제야 납득할 수 있었다.

 

내가 생각한 구조로는 답을 구할 수 없었고, 레퍼런스가 제시한 방법은 매우 합리적이라는 것을. 아마 나 스스로 납득할 시간이 모자랐기 때문에 아쉬운 마음이 들었던 것 같다. 코드를 다시 적어보고, 우리 페어 나름의 방식에 맞게 코드를 적었을 때 스스로 체화할 수 있는 기회였다는 것을 알 수 있었다. 꽁해 있었던 건 아니지만, 조금 더 노력해보자고 말하지 못한 내게 석연치 않았던 마음이 들었던 건 사실이다. 하지만 고집을 부리는 게 능사는 아니라는 것을 알았다.

우리는 하루에 배워야 할 것이 많고 시간은 제한적이기 때문에 막힌 문제가 있으면 하루고 이틀이고 붙들고 있을 시간이 없다. 개발자란 직업은 주어진 시간 내에 기능을 구현해야 하기 때문에 효율이 중요한데, 하나만 붙들고 전체의 흐름을 망치는 것은 좋지 않은 일이라는 걸 깨달았다. 타협할 줄 알고, 다른 코드(레퍼런스)에서 아이디어를 얻고, 나만의 것으로 소화하는 것이 얼마나 중요한 일이고 효율적인 일 처리 방식인지 생각해 볼 수 있는 시간이었다.

 

새삼 페어 프로그래밍의 의의와 중요성을 알 수 있는 하루였다. 평소의 나였다면 쉽게 하지 못할 일이었기 때문에 이런 제의를 해준 페어에게 감사할 따름이다. 무언가 프로그래머로서 더 성잘할 수 있었던 하루였던 것 같다.


오늘의 키워드

객체, Dot notation, Bracket notation, delete 키워드, in 연산자


오늘의 학습내용

  • 객체의 정의와 선언 방법
  • 키-값 쌍의 구분, 활용 방법
  • 객체 값을 사용하는 방법(dot notation, bracket notation)
  • 객체의 여러가지 메서드와 변형(mutation) 여부

어려웠던 keyword

  • in 연산자
  • for ... in 과 for ... of 
  • bracket notation의 활용

내가 질문한다면

  • [key] in object 조건식을 어떨 때 활용하면 유용한가요? 
  • object[index]가 가능한지, 안 된다면 왜 안되는 지 설명해주세요.
  • for ... in 문과 for ... of 문을 사용할 때 객체와 배열의 바른 사용법을 정의해주세요.
  • bracket notation을 쓸 때 주의해야할 점이 무엇인가요? 문자열이면 모두 사용이 가능한가요?

댓글