내용에 문제가 있는 경우 삭제,수정 조치 하겠습니다.
네이버 부스트캠프 4주차를 마치고, 수료했다!!!!!
배우고 느낀 것들
피드백 하는 것을 두려워 하지 말 것
피드백을 할때, 항상 내 피드백으로 인해 이 사람이 잘못된 방향을 잡으면 어떻게 하지?라는 생각을 가졌었고, 그래서 조금 꺼려했던 것 같다.
한 가지 문제를 풀이하는 방법은 수 없이도 많다. 하지만 어떤 것이 최적의 풀이인지는 상황에 따라 달라진다.
A상황에서는 1이라는 풀이가 좋고, B라는 상황에서는 2라는 풀이가 좋을 수 있다.
문제를 풀때 항상 A상황이라면 너무나도 명백하게 항상 1이라는 풀이가 좋을 것이다. 하지만 현실에서의 상황은 계속 변한다. 또한 같은문제를 어떻게 문제를 정의하느냐에 따라서도 조건이 변하게 된다.
A라는 조건내에서 풀어야할 수 도 있지만 B라는 조건내에서는 2라는 풀이로 풀어낼 수 있어야한다.
그래서 결론적으로 다양한 조건에서 다양한 풀이방법을 익히는것이 좋다는 생각을 갖게 되었다.
그러면 내가 다른 사람에게 피드백을 하는 것이 그 사람에게 하나의 풀이로 인식될 수 있고, 그것을 받아들임으로써 이후에 그 사람의 다른 풀이방식에라도 도움이 될 수 있다는 것을 알게되었다.
잘못된 방향이란 없다. 어떤 상황, 조건에서 왜 이렇게 했느냐가 중요하다.
성장한 부분
믿을 건 테스트코드 뿐...
테스트코드를 작성하기 위해서는 모듈을 작게 구성해야 하고, 테스트를 거치면 해당 모듈에 대한 신뢰가 생긴다.
항상 나는 코드를 작성할때 예외처리를 마지막에 수행하는데, 구현을 다하고나면 예외처리가 뒷전으로 밀려나기 일수였다. 하지만 테스트코드를 작성하다 보니 그런 미흡한 부분을 더 보완할 수 있었다. 또한 작성하면서 더 많은 예외상황을 생각하게 되기에 보다 내가 의도한 기능으로 작동하는 함수와 기능들을 작성할 수 있었다.
무엇보다 비동기적인 테스트 코드, 모킹하는 코드들을 처음 작성해보았는데, 항상 막혔던 부분이라 정말 엄청난 성취감을 느낄 수 있었다. 이후 프로젝트에 적용할 생각에 조금 신난다.
테스트코드를 작성하자 이후 개선 작업을 진행할때 코드 스타일을 바꾸는 것은 물론, 구조자체를 뜯어고쳐도 개선에 걸리는 시간이 매우 줄어들었다.
이는 디버그 시간이 줄어들기 때문인데,
원래라면
1. npm start
2. 인자 입력, 값 입력, 값입력...
3. 어 왜 안돼?
4. 의심되는 코드 중간에 console.log
5. 다시 npm start
6. 입력, 입력 입력,,,
7. 오 여기다!
8. 수정작업
9. 디버그완료!
인데
테스트코드가 있으니
1. npm test
2. 어 왜 안돼?
3. 테스트 코드에 console.log
4. npm test
5. 오 여기다!
6. 수정작업
7. 디버그 완료!
입력하는 과정과 디버그용 console.log를 출력하는 부분을 찾아내는 시간이 매우 단축되었다.
엄.. 이렇게 과정만 쓰니까 별 차이가 없어보이기도 하는데, 정말 시간이 1/3정도로 줄어드는 걸 느낄 수 있을 것이다.
입력 과정이 정말 테스트하기 어려운데, 혹여나 실수로 잘못 입력하면 다시 입력을 해야하기때문이다....
(이게 굉장히 스트레스였고, 예외케이스를 처리하기 힘들게 하는 요인이었다.)
나머지는 수료회고로 이어진다.
부스트캠프 8기를 수료하며
아쉬운 점
네트워킹
이게 4주차 수료식 전까지는 잘 몰랐는데 네트워킹이 참 부족하다고 느꼈다.
정말 좋은 사람들이 많은 부스트캠프였는데, 여러 동료활동을 제외하고는 좀 적극적으로 임하지 못한 것 같아 아쉬움이 남는다.
왜 한번도 모각코를 들어가볼 생각을 못했는지... 많은 좋은 인연들을 얻을 수 있었을텐데 정말 아쉽다...
나름 사회화 된 intp이라고 생각했는데 한참 남았다... 다른것보다 소프트스킬을 키워야 할듯 하다.
성장한 부분
나의 의견과 의도을 명확하게 전달하고, 잘 질문하기
나의 의견을 근거와 더불어 전달하고, 다른 사람의 의견을 더 적극적으로 물어볼 수 있게 되었고, 이를 토대로 좋은 질문이 무엇인지, 어떻게 질문해야 할지를 학습 커뮤니티를 통해 배울 수 있었다.
함께 성장하기
정의되지 않은, 답이 존재하지 않는 문제에 대해 토론하고 시도하며 지식을 쌓아가는 방식이야 말로 잘하기가 아닌, 자라기라는 것을 알게 되었다. 덕분에 다른 사람들의 접근법을 이해하고, 내것에 적용시키는 법을 배웠고, 내가 어떤 의도에서 어떻게 풀었는지를 피드백 형태로 전달할 수 있게 되었다.
도움을 주고 도움을 얻는 문화를 몸소 체험하며 함께 자라기가 무엇인지 터득할 수 있었다.
제대로된 설계
몇개의 클래스, 상속을 했다고 설계 한게 아니다.
절대 기능만 보고 설계하지 말고, 기능 아래에 무엇이 필요할지 생각할 수 있게되었다.
설계 능력이 한층 향상되었다.
하지만 설계에 너무 집착하지 말것
설계된 청사진을 너무 고수하지 말고, 변경할 부분을 적극적으로 구분하자.
그러다보면 사용해야할 디자인패턴, 매개변수, 클래스들이 보이게 된다!
테스트코드를 반드시 작성할 것
위에 작성했으니 생략한다.
문제해결능력
피자 한 판을 한입에 다 넣고자 하면 입이 찢어지고 말 것이다.
누군가 피자 한판을 다먹으라고 한다면 막막함을 느낄 것이다. 미션이 딱 이런 느낌이었다.
정의조차 잘 되지 않는 거대한 문제를 마주하다보니 어렵기도 어렵거니와 좌절감을 느끼기도 했다.
하지만 4주동안의 훈련 과정을 통해 문제를 해석하고, 해결하기 위한 작은 체크포인트를 만들고, 하나씩 정복해나갔다.
지금 내 상태를 확인하고, 모르는 것을 체크하고, 내가 할 수 있는 것을 설정하고, 그것을 행한다.
매우 큰 문제는 해결할 수 없지만, 작은 여러가지 문제는 충분히 해결할 수 있다.
문제를 한입 크기로 먹기 좋게 써는 방법을 터득할 수 있었던 것 같다.
앞으로 어떤 문제든 해결할 수 있겠다는 자신감을 얻을 수 있었다.
대충 과정을 요약하면 이렇다.
1. 문제를 읽는다.
2. 이해안되는, 모르는 단어를 찾는다. (대충 아는 것은 모르는 것이다.)
3. 용어를 학습한다.
4. 명세를 읽고, 기능을 한번씩 다 적어본다.
5. 역할과 책임별로 나눠본다.
6. 설계도를 그린다.
7. 역할과 책임에 맞춰서 기능을 하나씩 설정한다.
8. 기능, 함수 하나씩 구현 해나간다.
제대로 된 회고
원래라면 하나의 경험이 끝나야 회고를 올리는 나였지만, 이번 부스트캠프는 너무나도 압축적인 과정이라 주마다 회고를 작성했다. 이게 정말 크게 작용했던 것 같다.
매주 끝나면 잘한점과 아쉬운 점을 기록했고, 미션을 해결하면서 의식적으로 나의 사고과정을 기록했다.
그 후, 미션을 진행할때, 기록했던 것을 떠올리며 잘한 점은 더 발전시키고, 아쉬운 점은 보완하고자 노력했다. 덕분에 너무나도 많은 부분에서 성장할 수 있었다.
무언가 잘하고 싶다면, 현재 내 상태가 어떤지부터 확인해야한다. 매주 진행하는 회고가 내가 어디쯤에 있는지 확인할 수 있게 도왔다.
마지막에 지속 가능한 개발자가 되기 위한 퀘스트를 만들었는데, 이를 위해서는 정기적인 회고가 필수라고 생각하여 프로젝트 진행시 주별회고/프로젝트 종료후 회고/ 매 분기별 회고를 나만의 퀘스트로 만들었다.
회고를 통해 메타인지를 높히자.
마치며
다시 돌아가서 처음부터 하라고하면 못할정도로 모든걸 쏟아부은 4주였다.
그만큼 많이 성장했음을 느끼며... 이번주말은 좀 쉬자.
이런 좋은 기회를 얻을 수 있었음에 정말 감사하다.
앞으로도 회고하고, 개선하고 함께 자라자.
