감사하게도 멤버십에 합격하여 부스트캠프 활동을 지속할 수 있게되었다.
1주차를 지내보며 회고를 해보고자한다.
배우고 느낀 것들
문제에 접근하는 법
1. 문제는 무엇인가?
문제가 일어나는 현상을 명확하게 정의한다.
이것이 가장 처음에 이뤄져야할 단계이다.
2. 정말 문제인가?
기대한 현상과 실제 현상을 비교해보고, 어떤부분이 기대한 것과 다른지 파악한다.
3. 가설을 세운다.
이론적 접근을 통해 가설을 세우고, 실제 실천하여 확인해보는 과정을 거친다.
4. 무한 반복
계속해서 추론, 실천 과정을 반복한다. 답을 찾을때 까지.
성장을 위한 단계
1. 인지
인지가 중요하다. 하지만, 우리는 살아온 경험, 편견 때문에 제대로 인지하기가 쉽지않다.
여기서 제대로 인지하는 것이란 무엇일까?
우리의 지식 구조가 이럴 거라고 생각한다.
아는 것은 아는 것이고, 모르는 것은 모르는 것이다. 따라서 모르는 것을 익혀나가면 된다고 생각하기 쉽다.
하지만 실제는 아래와 같은 그림이 된다.
안다고 착각하는 부분이 반드시 생기게된다. 이는 경험과 편견때문에 만들어진다.
한번 경험에 봤다고 아는 것이 아니다. 이 부분을 모른다고 인지, 인정하지 못하면, 평생 이 부분을 익힐 수 없게 된다.
2. 학습
필요한 정보를 이론적으로 학습하는 단계다.
3. 경험
학습한 정보를 실제로 적용하고, 가설을 세우고 검증하는 단계이다.
4. 정리
정리하는 과정이 반드시 필요하다.
정리는 학습과 경험을 통합하는 과정이다.
둘중 하나라도 제대로 되지 않으면 아는 지식이라기보단 안다고 착각하는 지식이 되기 매우 쉽다.
흔히 개발자라면 하게되는
왜 됨? / 왜 안됨?
이 대표적인 정리가 되지 않은 상태, 안다고 착각하는 지식이다.
그래서 새로운 기술을 접하고, 경험하고, 구현했다면 최대한 블로그에 남기려 하고 있다.
반드시 정리를 하는 습관을 만들어서 안다고 착각하는 지식을 만들지 말자.
5. 공유
그럼에도 시간은 한정적이다. 지식을 배우고, 경험하고, 정리하는 시간은 무한하지 않다. 개인이 정리할 수 있는 지식은 한정적이다. 그래서 우리는 정리한 지식을 공유하고, 나눠야한다.
나의 정리가 다른 사람의 학습이 될 수 있도록.
명세에 접근하는 방식
나만의 방식을 한번 정리해보는 기회가 있었다.
1. 명세를 읽고 나만의 언어로 한번 정리하기
명세를 읽다보면 이게 당최 무슨 말인지 이해가 안되는 부분이 생긴다.(물론 나만의 한국어 이슈일 수 있다.)
이런 부분이 생기지 않도록, 읽으면서 나의 언어로 다시 정리해보면서 읽는다.
2. 필요한 데이터구조 확립하기
기능들(task)간에 데이터를 반드시 주고 받기 마련이다.
그럴 수 밖에 없는게, 소프트웨어는 데이터를 처리하기 위해 있기 때문이다.
3. 필요한 기능을 도출하고, 체크리스트 작성하기
명세에서 필요한 기능들을 도출한다.
여기서는 어떤 기능이, 여기서는 어떤 기능이 필요하고, 이 기능들 사이에는 어떤 연관 관계가 있구나를 파악한다.
이후 기능목록별로 체크리스트를 작성한다.
4. 필요한 기능에서 필요한 작은 기능들(task)를 분류하기.
2에서 대기능을 분류했다면, 이번에는 소기능을 분류한다.
요거를 구현하려면 이게 필요하겠구나? 얘네는 공통적으로 이게 필요하네? 등을 생각해보며 소기능을 대기능 밑에 depth를 하나 늘려서 체크리스트로 작성한다.
5. 작은 기능부터 개발을 시작한다.
작은 기능부터 개발을 시작하며, 테스트 코드도 최대한 작성을 해보려고 한다.(요즘들어서...)
테스트코드가 있어야 개선하는 속도가 빨라진다. 이를테면 작업속도 개선을 위한 개선이다.
6. 기능과 코드를 개선한다.
항상 더 나은 방법이 있기 마련이다. 의견을 나누고, 구조와 코드를 개선시키자.
아쉬운 부분/개선할 부분
부족한 학습
이번 주는 구현을 100% 해보겠다는 목표가 있었는데, 이 부분 때문에 학습이 좀 부족했다고 생각한다.
양보다는 질적인 부분에서 부족했다.
이론적 학습에 그쳤고, 이 부분이 온전히 나의 코드로 담기지 못했다.
논블로킹과 블로킹을 학습하긴했으나, 이 부분을 적용시킬 생각을 하지 못했는데, 피어세션을 통해 인지하게 되었다. 나는 또 안다고 착각했다.
학습을 할 때는 이걸 어떻게 적용할 수 있을지 생각해보는 습관을 들여야 할 것 같다.
클라이언트측 테스트코드 부재
부스트캠프 챌린지가 끝나고, 테스트모킹을 학습한 덕분에 백엔드 서비스로직에 대한 테스트코드는 잘 작성했고, 이 부분에서는 성장했다고 느꼈다.
하지만, 클라이언트 테스트 코드를 작성하지 못했다.
프론트엔드를 열심히 학습해왔다 생각했었는데, 돌이켜보니 테스트코드를 써본적은 한번도 없구나...약간 반성하게 되었다.
DOM이 Node 환경에는 없는데 이걸 어떻게 처리하지? 라이브러리를 써야하나? 쓴다면 어떤걸 써야하지? 하느라 못썼다.
jsdom이나 jest-environment-jsdom, jest-dom이 있는데 무슨 차이가 있는지, 어떤 장점이 있는지 명확하게 파악하지 못했다.
조사가 더 필요한 부분이다.
2주차도 화이팅~!
