오늘은 Udemy에서 하는 개발자의 학습법이라는 라이브 세션을 수강했다.
이 세션을 듣고 나름대로 정리를 해보았다. 개인적으로 Maker Jun님의 TDD 관련 세션이 정말 좋았다. TDD( 테스트 주도 개발)에 대해 많이 들어는 봤지만, 그게 대체 왜 좋은지 알 수 없었는데 덕분에 TDD의 장점에 대해 쉽게 이해할 수 있었다.
1. TDD
"농구공을 던졌는데, 골대에 들어갔는지 한 달 후에 알 수 있다면 어떨까요? "
생각만 해도 답답한 일일 것이다. 이처럼 테스트 코드 없이 그냥 프로덕션 코드를 짜게 되면, 내가 작성한 코드가 문제가 있는지 없는지 어느 정도 시간이 지난 후에야 알게 될 수 밖에 없다. 하지만 테스트 주도 방식으로 개발하면 테스트 코드를 먼저 작성하고 그 뒤에 기능을 구현하기 때문에 즉각적으로 문제가 있는지 여부를 알 수 있다.
즉, TDD의 핵심은 빠른 피드백이다.
테스트 코드 작성 -> success -> 기능1 구현 -> 테스트 코드 작성 -> success -> 기능2 구현
이런 식이다. 상당히 애자일한 방식이다.
한 질문에 답변을 하시며 더 구체적인 예를 들어주셨는데, 무척 좋은 내용인 것 같아 적어두었다.
간단히 메모한 걸 문장으로 옮긴 거라 실제 말씀하신 것과 조금 다르다. (하지만 핵심은 동일함)
Q. 강의는 많이 들었는데 개발은 어떻게 시작해야 할지 모르겠어요.
🧑🏻🔧 💬
내가 할 수 있는 가장 작은 영역부터 시작하세요. 단, 만들고자 하는 것의 핵심이 포함되어야 합니다.
계산기를 예로 들어봅시다. 계산기에서 가장 중요한 기능이 무엇일까요? 아마 사칙연산이겠지요.
그 중심기능인 사칙연산 기능부터 만들어보는 겁니다. 순서를 적는다면 다음과 같습니다.
- 먼저 ui 없이 사칙연산이 되는 것만 먼저 빠르게 만들기.
- iput으로 사용자 입력 받고 이벤트 처리하기
- 숫자 UI 추가하고 이벤트 처리하기
- UI 레이아웃 잡기
- 스타일 입히기
-> 나는 여태 UI를 먼저 만들고 기능구현을 하는 방식으로 개발했었는데,
앞으로는 이런 workflow로 작업해보면 좋겠다는 생각이 들었다.
Q. 현업에서 TDD 적용하기?
🧑🏻🔧 💬
테스트코드를 프로덕션 코드보다 먼저 작성해야 합니다. 프로덕션을 먼저 짜면 답정너처럼 제가 원하는 결과가 나오도록 테스트를 짜게 되기 때문이죠. 하지만 여러 이유로 실제 현업에서 프론트엔드가 tdd 개발하는게 쉽지 않긴 합니다. 너무 부담갖지 말고, 내가 원하는대로 잘 동작하는지 피드백 받는다는 느낌으로 생각하면 됩니다.
2. 개발자의 저주
Poco Jang님의 세션의 내용은 간단히 말해서 메타인지와 개발에 임하는 태도에 관한 내용이었다. 개발은 원래 어려운 게 맞으니, 쉬운 길을 찾지 말고 꾸준히 성실하게 공부하라는 게 핵심 메시지였다.상당히 쓴 소리를 잘 하셔서 Q&A가 인상 깊었다.
Q. 기술이 계속 변하잖아요. 공부하는 의미가 있는 건가요?
🧑🏻🔧 💬
정말 자주 듣는 질문인데, 솔직히 말하자면 공부하기 싫어서 변명을 하는 걸로 보입니다.
-> ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이 슬라이드 두 장은 보면서 공감되서 스크린샷으로 찍어두었다.
앞서 말했다시피 포기하지 않고 "꾸준히" 공부하라는 것이 이 세션의 요지였는데
포기에 관련된 부분이 인상 깊어 이것도 메모해두었다.
"네카라쿠배 그런 곳 가는 사람들은 천재라고 정의해버립니다. 내가 못한 게 아니라 남이 잘하는 거라고 치고 넘어가면 편하니까. 이건 그냥 포기에요. 포기할 이유를 찾지마세요. 합리화하지 마세요. 스스로 한계를 만들지 마세요. 그냥 하세요. 쭉, 꾸준히 하세요."
