090.10 a
Description: As a first stage with 9th batch student, it was an opportunity to think about the "Basics" as a comprehensive developer, including analyzing requirements, designing data, organizing, and evaluating algorithms and performance before running the two-week program.
#000#IT_Knowledge#090#External_Insights#090.10#Activity#090.10 a#Naver_boostcamp_Basic
결과 2차 문제해결력 탈락
- Naver boostcamp basic 소개
- Basic에서 배운 것들
- 요구사항, 설계, 다이어그램
- 회고
- 내가 되고싶은 개발자를 사자성어로 표현하면 "무혈입성"
Naver boostcamp basic 소개
네이버에서 운영하는 웹,모바일 부스트캠프에 basic이라는 과정이 이번 기수(2024년7월 9기) 신설됐다. 기존의 코딩테스트보다는 좀더 개발을 잘하기 위한 과정을 녹여내여, 끝까지 할 수 있는가를 몇주에 걸쳐서 과제와함께 수행하는 제도이다.
스스로 성장해야하는 개인 미션뿐만아니라 그룹미션도 함께 수행하게된다. Basic의 수행과제에서 느낀점은 다른 분의 말을 빌리자면 **"정말 심사숙해서 과제를 고르신 것같다. 실제로 도움이 될만한, 된 과제도 많다" **
Basic에서 배운 것들
- 기술적인 부분
- 요구사항 분석하기
- 설계하기
- 다이어그램
- 학습적인 부분
- 회고
해당 것들을 배우면서 느낀것이 나중에 문제가 생겼을때 "아 처음부터 다시해야하는건가"라는 절망감이 들지 않게 하기 위해선 코드 작성만큼 정확한 명세가 중요하다는 것을 느꼈었다.
1.요구사항 분석하기
일반적으로 현업에서의 요구사항은 어떨까? 애매한 단어, 모호한 표현, 틀린 정보 등등... 정말 우리가 코딩테스트하듯이 모든것이 깔끔하게 정리된 상태는 아닐 것이다. 그런 의미에서 요구사항을 전달받았을 때 제한조건, 의미분석 , 제약사항등을 제대로 체크하는 것이 중요할 것이다. 이는 요구사항의 경우 몇십 줄이아닌 몇 백줄이 넘어가는 경우도 많아서 이를 처음부터 끝까지 제대로 읽는 것 자체도 힘든 경우가 많다.
예를 들어 어떤 요구사항을 받았는데 너무 길어서 중간에 집중을 놓친 나머지 중요한 부분을 이해하지 못했다치자,
그러다가 나중에 중간 이상 진행된 상황에서 "어 이 부분 결과값형식이 이상한데요?" 라는 말과함께 다시 수정할 수 있는 사항이 생길 수 있다. 내 생각에는 요구사항 분석하면서 최대한 애매한것이나 모호한것은 서로 협의를 통해 "우리 이건 이렇게 하기로 한거다?" 라는 약속을 명확히 하는 과정의 중요성을 깨달았다.
2. 설계하기
기술적으로 데이터구조와 알고리즘에 생각해보자. 데이터구조를 잘 설계하는 것 만으로도 구현 및 운영 난이도가 확 낮아진다. 하지만 그 깊이를 좀 세밀하게 살펴볼 필요가 있다.
- 단순히 1차원 배열인가? 1차원 배열의 원소로는 다른 타입이 들어가는가? 2차원인가? 다른 외부 타입이 참조되는가? 여기서 더나아가서
- 함수로 만드는것이 나은가? 클래스로 만드는 것이 나은가? 더 더 나아가서
- 이 부분은 비동기로 처리하는게나은가? 그렇다면 async 사용할지 Promise 객체 형태로 사용할지?
- 함수로 만드는것이 나은가? 클래스로 만드는 것이 나은가? 더 더 나아가서
- 제약사항과 검증사항을 잘 지켰는가?
이런 점들을 요구사항 분석이후에 설계할 필요가 있다. 접근법부터도 input output형식이나 성는이 무조건 빨라야하는 검색의 경우 O(1)을 가능하게 하는 데이터구조라던가 등등 많은 것을 생각해봐야한다.
데이터 구조 참조 글 010.10 b
3. 다이어그램
시각적으로 프로그램이 무엇을하는지, 컴포넌트를 무엇을 가져야하고 어떻게 변하는지, 액터와 어떻게 상호작용하는지 시각적으로 보여주는 다이어그램이다.
개인적으로 느낀점중 하나는 다이어그램으로 내가 직접그리다보니 "어 이 변수 필요했네 근데 처음에는 생각하지 않았었네" 라거나 "어 이 함수 필요했었네"와 같은 내가 미쳐 생각하지 못한점을 스스로 깨달은게 좋았다. 또 협업에 있어서 서로의 의견을 합일하는데 거의 필수일거 같다고 생각이들었다. 물론 텍스트로만 가능하면 그게 best지만, 다이어그램 그리는게 결국 필요할 것이다.
하지만 다이어그램의 경우 그리는 것은 별로 어렵지 않고 제일 중요한 것은 어떤 다이어그램을 선택할지 와 어떤 요소들을 구별할지 가 중요하다. 간단하게 설명하면 다이어그램의 목적성과 현재 요구사항을 제대로 파악할것, 정말 쓸모있는 다이어그램을 그리기 위해선 적절한 선택이 필요할 것 이라는 거다.
다이어그램 참조 글 010.20 a
회고
기록에대해서도 배워본 경험이었다. 기록 또는 명세 이런말들로 표현하지만 어떤의미로 스스로의 지식을 점검해보는 계기가 아닐까 생각한다.
다음은 위키피디아에서 가져온 학습 효율 곡선이다.
여기서 주목할점은 가장 효율좋은 방법은 "남에게 가르치는것" 이라는 것이다 .(그래서 과외가 제일 비싼걸지도?) ㅍ
그런 의미에서 회고는 자기 자신에게 가르치는 것 같은 느낌으로 생각이됐다. 말그대로 자신이 쓰면서도 마치 다른사람에게 설명하듯이 어떤걸 배우고, 어떤 걸느꼈고 등을 조리있게 설명한다는 것이 유사 다른사람에게 가르치는 것이지 않을까 생각이든다. 그리고 그런 행동은 높은 학습효과를 보인다.
| Retention rate | Learning activity before test of knowledge |
|---|---|
| 90% | Teach someone else/use immediately. |
| 75% | Practice what one learned. |
| 50% | Engage in a group discussion. |
| 30% | Watch a demonstration. |
| 20% | Watch audiovisual. |
| 10% | Read. |
| 5% | Listen to a lecture. |
위키피디아 링크: https://en.wikipedia.org/wiki/Learning_pyramid
또 어딘가에서 본 기억만있는데 사람은 input을 수동적으로 받아들일 때보다, 내면의 데이터를 output할 때 학습이 더잘되며, 이런 경우 장기기억으로 잘 이어진다는 것을 유튜브 어딘가에서 봤던거 같다. 이런 느낌과 유사하게 회고 라는 것은 이번 basic을 통해 느껴보니 스스로에게 가르치면서 output위주의 학습을 통해 학습 효율성을 늘리는 행위가 될 수 있었다.
내가 되고싶은 개발자를 사자성어로 표현하면 "무혈입성"
개발자마다 철학이 다르다고 생각한다. 그것을 사자성어로 비유하면 좀더 이해하기 쉬울것이다.
예를 들어 동고동락
: 힘들때도 즐거울때 도 함께하기에 옆에있는 동료와의 관계를 중시함. 힘들떄도 즐거운 경우를 생각하고, 즐거울 때도 힘들때를 생각하는 협업형.
이건 동료와의 협동을 중시하는 개발자가 생각나서 쓴 사자성어
예를 들어 근면성실
: 부지런하고 성실함
-> 이건 주석을 정말 예쁘고 잘다는 사람이 생각나서 쓴 사자성어다. 그만큼 성실하면서 남을 배려하는 철학을 가진 사람에게 어울리는 사자성어
이런 식으로 자신의 개발철학을 사자성어로 표현할 수 있을 텐데 본인의 경우 무혈입성.
피를 흘리지않고 성을 들어간다는 뜻인데 조금 더 풀어쓰자면 "코드를 수정하지않고 문제를 해결하는 자세" 이다. 코드의 경우 내가 작성하는 것보다 외부패키지나 레거시코드를 건드는일이 매우 많을 것이다. 그렇다보니 마음대로 , 막 수정하는 것은 지양될 일이라고 생각한다.
그리고 코드를 수정하지 않고 문제를 해결한다는 것은 어떤의미로 문제의 본질을 꿰둟고 있다는 의미로 해석된다.무조건 바로 코드를 수정한다기보단 먼저 문제를 듣고, 생각해보고 , 물어보고 탐색하고 근본원인, 의미 등을 모두 파악하고 나서 코드를 건드는게 본인이 생각하는 개발 철학이다. 물론 딱봐도 코드만 건드리면 해결되는부분이 있다면 그렇겠지만, 나중에 좀더 복잡하고 다양하고 어쩔수없는 상황이라던가 그런게 생기면 코드부터 건드는 행동은 좀 나중으로 미루는게 좋지 않을까라는 개인적인 느낌적인 느낌.