우아한 테크코스 6기 지원 후기

우아한 테크코스 6기

 

 

우아한 테크코스. 배달의 민족(우아한 형제들)에서 운영하는,

저와 같은 주니어 개발자 사이에서는 너무나도 유명한 부트캠프인데요.

 

 

 

 

포크 수가 2.7k인 1주차 과제 레포지토리...

 

 

저는 백엔드로 지원하였는데, 모집 인원이 가장 많지만 지원자 수 역시 가장 많은 분야입니다.

우아한 테크코스 백엔드의 지원자 수가 몇 인지는 공개되지 않지만,

1주차 과제 레포지토리의 포크 수로 어느정도인지 대략 가늠은 할 수 있는데요.

포크 수만 2700회네요.

85 : 2700 = 약 1 : 31.7 정도 되는 것 같습니다. ㅎㅎ;

 

 

 

1~4주차 프리코스 후기

 

우아한 테크코스의 선발과정은 서류(자기소개서) -> 프리코스 -> 최종 미션으로 진행하는데,

가장 큰 비중을 차지하는 건 자기소개서라고 하네요.

자기소개서에는 몰입에 관한 경험, 실패와 극복, 원하는 모습, 효과적인 학습방법 등이였던 것 같은데,

아마 1일 1코딩테스트와 1일 1커밋을 500일 넘게하며

매일 공부하고 매일 성장하고 싶다는 이야기를 적었던 것 같습니다.

 

프리코스는 총 4주 동안 진행하였는데, 상당히 재밌게 참여했어요.

과제의 구현 난이도 자체는 그리 높지는 않습니다.

단순히 구현을 목적으로 한다면 꽤 금방 풀 수 있으나,

객체지향적으로 사고하고 설계하고, 개발하기 위해 꽤나 시간이 걸렸던 것 같아요.

 

 

 

메소드(함수)와 클래스가 한 가지 역할만을 수행하는가? 

 

int x1 = 1;
int y1 = 1;
int x2 = 2;
int y2 = 2;

double distance = Math.sqrt(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2));

public static void main(String[] args) {

    int x1 = 1;
    int y1 = 1;
    int x2 = 2;
    int y2 = 2;

    double distance = getDistance(x2, x1, y2, y1);
}

private static double getDistance(int x2, int x1, int y2, int y1) {
    return Math.sqrt(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2));
}

 

예전에는 어차피 한 번만 실행되는 기능같은 경우에는 함수로 나누는 이유가 없다 생각해 분리를 안하곤 했는데,

 

김영한님의 강의를 듣다가, 함수를 나눠놓으면 해당 부분이 무엇을 하는지,

해당 함수의 이름만 보고도 이게 어떤 역할을 하는구나~ 라고 바로 떠올릴 수 있다는

내용을 본 뒤로 함수로 빼는 연습을 했습니다.

 

물론 해당 코드를 모듈화 해놓으면 나중에 재사용할 수 있다는 점은 기본적으로 가져가는 장점이고요.

 

두 점 사이의 직선거리를 구하는 방법은 자주 쓰이니 딱 보고 바로 아시는 분들도 계시겠지만,

아무래도 Math.sqrt(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2)); 보다는

double distance = getDistance(x2, x1, y2, y1);가 한 눈에 더 알아보기 편한 코드가 되긴 하는 것 같네요.

 

함수의 들여쓰기가 3을 초과하면 안된다, 함수 라인 수가 15가 넘어가면 안된다, else문을 쓰지 말아라 등

처음에는 엥? 스러웠지만 습관이 되니, 메소드를 분리하는 것과 ealry return 기법 등도 조금은 능숙해진 것 같네요.

 

 

 

setter 대신 메시지를 던져라...?

사실 스프링을 처음 공부할 때 setter를 닫아놓는 것에 굉장히 놀랐습니다. 어색하기도 했고요.

안드로이드 프레임워크, Swing, 웹 프론트 등 UI 작업을 하다 보면

StatusBar, Text, Color, Style, Theme, Margin/Pagging 등등...

정말 설정 하나 하나 바꾸기 위해 setter를 굉장히 자주 사용하기 때문입니다.

(MVVM 패턴을 적용하면서 setText의 사용빈도는 줄어들었습니다만

다른 UI 설정을 하기 위해 여전히 많이 사용하긴 합니다)

설정 하나 바꾸자고 객체를 처음부터 새로 생성해 전달해주거나,

일일히 메시지를 던지기 위한 모듈을 만드는 것도 일이고요.

객체 내부의 리스트/객체를 getter로 갖고 와 조작하거나 원소를 추가하는 것도 굉장히 많았습니다.

 

하지만, UI 관련 설정할 일이 크게 없는 애플리케이션을 개발할 때에는

캡슐화와 의존성/응집도 관점에서는 봤을 땐, 객체에 메시지를 던지는 것이 OOP 적으로 더 맞는 것 같네요.

물론, 어떤 걸 개발하고 어떻게 설계하냐에 따라 다르고, setter를 쓰는 것이 꼭 나쁜 것만은 아니지만,

UI 작업을 하는 것이 아니라면 최대한 지양해보려 합니다.

 

 

 

줄여쓰기?

기존에도 함수와 메소드, 클래스 등 이름을 지을 때에는 역할을 잘 드러내도록 많은 고민을 하며 지었지만,

변수명이 너무 길어지면 읽기 힘들지 않을까 하며

count -> cnt, pointer -> ptr, studentNumber -> sn 등 줄여쓰기도 하였는데,

끝나고 나서 다른 사람들의 회고들을 보니까 변수명이 정말 긴 사람도 많더라고요...

조금 길더라도 무슨 의미인지 한눈에 이름이 좋다는 걸 깨닳았습니다.

 

최근 모 온라인 실시간 강의를 보다가, 변수명을 줄이지 말라 라는 내용의 강의 직후

강사분께서 화면 공유를 하며 자신의 작업물을 보여주시더니,

Configuration을 Cfgr로 줄여쓴게 보여서 아... 현업자들도 몸과 마음이 따로구나 싶긴 했습니다.

(평소에는 잘 안줄여쓴다며 머쓱해하는 강사님 반응은 덤ㅎㅎ)

귀찮더라도 풀어쓰는 습관을 들이는게 좋겠네요.

 

 

 

유닛 테스트

모든 모듈에 테스트를 해야 하다 보니

와! 이정도면 어느정도 된 것 같은데?! 싶다가도, 테스트가 불편한 설계를 종종 나타나긴 했습니다.

결국 테스트를 하기 위해 갈아엎은 적도 있었고요.

이래서 테스트를 먼저 만드는 테스트 주도 개발(TDD, Test Driven Development)를 사용하는구나 싶었습니다.

 

 

 

 

마치며

 

 

 

4주간 꽤 재밌게 참여하였지만 결국 최종 코테 전 프리코스에서 탈락하였습니다 🤣

 

 

 

 

결과 통보 메일 마지막 즈음에 학습 로드맵을 제공해주네요.

지속해서 도전해나가는 것이 저를 떨어뜨린 우테코에 복수하는 가장 좋은 방법이라...

마지막까지 우테코답다 해야 할까요 🤣

(처음봤을땐 감동이였는데 알고보니 지난 기수 멘트 복붙이길래 감동은 와장창 ⸜( ‵_′ )⸝ 😕 )

 

비록 불합격하긴 했지만

프리코스에 참여하는 동안 저는 제가 할 수 있는 최선을 다 했기에 딱히 미련이나 후회는 남지 않습니다.

무엇보다 프리코스에 참여하면서 꽤 얻어가는 게 많거든요.

 

불합했어도 해야할 건 늘 똑같습니다.

우테코는 과정이지 목표가 아니니까요.

저는 저 대로 계속 공부하며 제 역량과 지식을 끊임없이 늘려가는 개발자가 되면 됩니다.