ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 우아한 테크코스 2기 프리코스 3주차 후기
    우아한 테크코스/기타 2019. 12. 18. 02:28
    반응형

    진행하며 느낀 점과 아쉬웠던 점

    기능 요구사항을 명확하게 파악하자

     지금 생각해보면 기능 요구사항 정리부터 폭삭 망할 징조를 보였었다. 요구사항을 대충 훑었기 때문일까, 아니면 게임을 이해하지 못했기 때문일까? 처음 작성했을 때와 완성을 하고 났을 때의 이해한 기능 요구사항이 굉장히 다르다. 이해도가 부족한 것 같아 인터넷으로 게임 방법을 찾아보았었는데, 그게 오히려 더 혼동을 준 것 같았다. 초반에 기능을 다르게 생각했기 때문에 그것을 바로잡으려 하자 수정해야 할 것이 1주차, 2주차와 다르게 어마어마했다. 결국, 다 수정하긴 했지만, 처음에 기능 정리할 때 너무 조급해하지 않고 찬찬히 훑으며 명확하게 파악하는 게 정말 중요하다는 것을 느꼈다.

    나중으로 미루지 말고 처음부터 생각하자

     이번에는 UI 로직과 비즈니스 로직을 나름 분리하였고, 2주차처럼 기능별 메서드를 모아 클래스를 만들었다.

     처음부터 그렇게 생성한 것은 아니었다. 일단 main 메서드가 있는 클래스에 무작위로 메서드를 넣었고, UI 로직과 비즈니스 로직은 마치 한 몸과 같았다. 다른 클래스로 분리하는 것을 계획하자니 접근제한자, 인스턴스 변수, 파라미터 등 신경을 써줘야 할 부분이 많았고, UI와 비즈니스를 분리하는 건 일단 너무 복잡해 보였다. 그래서 일단 구현부터 해보고 나중에 생각하자는 마음으로 대강 구현을 완료했다.

     하지만 위와 같은 행동이 결국 나를 굉장히 힘들게 했다. 대강 구현 후 오류를 수정하고, 기능을 추가할 때마다 코드를 자세히 들여다봐야 했다. 직관성이 너무 떨어졌다. 결국, 메서드들을 묶어서 다른 클래스들로 빼내었는데, 각종 변수와 접근제한자가 나를 괴롭혔다. private! final! 하나를 옮기면 에러가 1개 이상 무조건 발생하고, 그 부분을 수정하고를 반복했다. 또한, 클래스 분리 후 로직 역시 분리하려 했는데, 이미 한 뭉텅이가 된 UI 로직과 비즈니스 로직을 분리하는 것은 정말 손이 많이 가는 일이었다.

     물론 분리하면서 배우고 느낀 것도 정말 많지만, 처음부터 잘 설계했었다면 이런 대혼돈은 없었을 텐데. 한 번 겪었고 교훈도 충분히 얻었으니 다음부터는 꼭 처음부터 제대로 만들어야겠다.

    메서드 10줄과 1 indent depth(들여쓰기)는 코드를 직관적이게 만든다.

     메서드 10줄 이하와 1 indent depth는 메서드를 기능별로 반강제로 나누는 데 도움이 되었다. 기능이 두 개 이상 들어간 메서드는 여지없이 10줄이 넘어가고, 조건식이 많은 메서드 역시 마찬가지였다. 기능이 두 개 이상인 경우엔 기능을 나눠주었고, 조건식이 많을 땐 &&와 || 연산자 등을 이용하여 내용을 간추렸다. try - catch문의 경우에도 1 indent depth이므로 메서드를 또 나눠주었다.

     아직도 익숙한 방식이 아니라, "아 이것도 나눠야 하는 건가?" 싶었던 부분도 물론 있었다. 하지만 나누면서 접근제어자를 활용하며 조금 더 캡슐화된 것 같기도 하다. 나누고 나니 본인의 코드를 봤을 때 훨씬 직관적으로 내용이 다가왔다. 메서드 내용이 짧아서 한눈에 들어오는 것은 물론이요, 기능별로 나눠놓은 메서드 덕에 메서드명만 봐도 해당 메서드의 기능이 직관적으로 보였다. 앞으로도 신경을 쓰며 코딩해야겠다고 다시금 생각하게 되었다.

    기능별 commit을 잊지 말자

     진행하면서, 코딩에 집중하다 보니 기능별 commit을 간혹 건너뛰고는 했다. 그래서 몇몇 기능은 뭉뚱그려 commit이 되었는데, 나중에 GitHub에서 commit 기록을 봤을 때, 한눈에 알아보기도 어렵고 어떤 변경이 어떤 기능을 수정한 것인지 확인하기도 어려웠다. 이 부분을 다음엔 꼭 유의하여 작성했으면 한다.

    프리코스 3회(1주차 ~ 3주차) 후 느낀 점

    학습 방법

     미션이 주어지면 그 미션에 필요한 기능들을 구현할 때 부족한 부분을 책이나 인터넷을 통해 학습하여 구현하였다.

     자바 컨벤션이나 기초 학습의 경우 미션의 요구사항이므로 미션을 구현하면서 자동으로 학습하게 되는 효과가 있었다.

    3주 전과 비교하여 성장했다고 느끼는 부분

    1. 기능 설계(정리) 후 코딩할 수 있게 됨

     가장 크게 성장했다고 느끼는 부분은 바로, 생성할 기능을 체계적으로 설계한 후 코딩을 할 수 있게 되었다는 점이다. 기존에는 코딩을 별로 해보지도 못했지만, 머릿속으로 대충 구상한 후 코딩하곤 했다. 사람은 망각의 동물이라지만, 너무나도 빠른 망각의 동물인 나는 결국 뭘 하려던 것인지 기억을 하지 못하거나, 어떤 것을 구현하려고 했는지 헷갈리고는 했다.

     기능 설계 후 코딩을 하게 되니, 내가 뭘 해야 할지 명확하게 그려졌을 뿐만 아니라, 그 시점이 지난 다음 날 혹은 그 이후에 작업하더라도 정리한 기능을 확인하며 빠르게 작업에 몰입할 수 있었다. 또한, 어디까지를 설계해야 할지 몰라서 리턴 타입이나 변수명까지 너무 세세하게 정리했던 부분도 공통 피드백을 통해 필요한 설계까지만 딱 진행할 수 있게 되었다.

     어떻게 보면 개발자는 당연히 해야 하고, 할 수 있어야 하는 부분일 수 있지만 그렇게 해야 한다는 생각조차 없던 나에게 정말 좋은 깨달음이 되어주었다.

    2. 기능별로 메서드를 분리할 수 있게 됨

     메인 메서드에 모든 내용을 욱여넣었던 지난 시절은 모두 안녕. 기능별로 메서드 더 나아가서는 클래스를 분리할 수 있게 되었다. 예전에는 기능을 나눈다는 생각조차 하지 않았었는데, 이젠 동작하는 기능별로 어느 정도 메서드를 분리할 수 있게 되었다.

     메서드당 코드가 짧아져 가독성이 좋아지는 것은 물론이요, 메서드 기능별로 메서드명을 짓다 보니, 메서드 내용을 보지 않고 메서드명만 보더라도 훨씬 직관적인 코드가 되었다. 또한, 나눠놓으니 메서드 재사용도 쉬워져서 중복되는 내용이 정말 많이 줄어들었다. 앞으로도 꾸준히 연습하여, 생각하지 않아도 자연스럽게 분리할 수 있게끔 되어야겠다.

    3. 조금 더 생각하고 명명하게 됨

     int a; private void user_name() {}; class users;와 같이 명명규칙을 무시했던 지난날들은 나중에 코드를 봤을 때 이해하는 데 시간이 오래 걸리게 된 이유 중 하나였다. 잠시 쓸거라고 생각하여 t1, t2, t3 같은 느낌으로 변수를 생성하고, 카멜 케이스고 뭐고 필요 없이 밑줄 최고를 외치며 메서드명을 정해버리고, 가끔은 클래스명도 소문자로! 완벽하게 생각이 없는 명명이었었다.

     처음에 받았던 자바 컨벤션 자료를 보며 많은 생각을 했고, 실제로 그렇게 명명하며 영어사전에 폭풍 검색도 하고, 고민하며 시간을 투자해 명명하고, 또 본인 코드를 보면서 진짜 이름을 잘 지어야 한다는 생각을 했다. 이름을 마구잡이로 지었을 땐 흐름을 보면서 이건 대체 뭘까 고민을 많이 했는데, 잘 지어놓은 후엔 아, 이건 이거군 하고 넘어갈 수 있게 되었다.

     아직 동사 명사 구분하며 작성하는 건 힘들긴 하고, 익숙한 단어임에도 불구하고 영어사전을 자꾸 확인하게 되지만, 전에 비해선 훨씬 많이 더 생각하고 명명하게 되었다.

    4. 접근제한자, 제어자에 익숙해짐

     private, (default), protect, public, final, static에 대해 많이 사용하면서 익숙해지는 기회였다. 기존에는 무조건 public으로 생성하는 버릇이 있었는데, 이젠 용도에 따라 접근 제어자를 구분하며 사용하려 신경을 쓰게 되었고, 변경이 필요 없는 값은 final로, static하게 생성할 필요가 있는 값은 static으로 구현할 수 있게 되었다. 접근 제어자를 구분해서 사용하다 보니 나중에 코드를 다시 확인할 때, 어떤 부분에서 쓰이는 코드인지 더 알아보기 쉬워진 것은 기분 좋은 덤!

    5. 하드 코딩에 대한 개념이 생기고 상수를 사용하게 됨

     메서드 호출이나 조건식에, 또는 변수에 숫자나 문자열을 그냥 넣는 것을 하드 코딩이라고 생각해본 적이 없었던 것 같다. 그냥 당연하게, 뭐 한두 번 쓸 거니까 하고 넣어뒀던 것들이 알고 보니 다 하드 코딩이었다. 상수를 사용하니 일단 대문자라 보기에도 좋고 한눈에 들어올 뿐만 아니라, 나중에 그 값을 바꾸고 싶을 때 무척 편하게 변경 및 롤백을 할 수 있게 되었다.

    6. 컬렉션과 친해짐

     컬렉션, 특히 List와 굉장히 친해졌다. 기존엔 ArrayList는 거의 사용하지 않고 배열만 사용했었는데, List와 친해지게 되니 코드가 훨씬 효율적으로 짜졌다. 배열과 다르게 컬렉션은 제공하는 API도 많아서, 구현이 없이 사용만 해도 되는 기능들이 많아서 좋았다.

     잘 쓰지 않다 보니 공부를 하다가도 매번 잊어버리는 부분이었는데, 이번 기회에 정말 많이 사용하면서 익숙해졌다.

    7.  void를 제외한 친구들과도 친해짐

     기존에는 System.out.println을 이용하여 거의 모든 메서드를 void로 반환했었는데, 이젠 기능에 따라 분리를 하다 보니 필요한 반환 타입에 맞춰 메서드를 작성 및 리턴이 가능하게 되었다! void로 반환하지 않게 되니, 해당 메서드를 호출한 쪽에서 추가 가공이 가능해져 조금 더 기능을 풍성하게 늘려갈 수 있었다.

    8. 스스로 짠 코드를 수정할 수 있게 됨

     위의 모든 항목을 통해, 이젠 스스로 짠 코드를 수정할 수 있게 되었다. 기존에는 수정하는 것보다 차라리 새로 작성하는 것이 빠르겠다고 생각하며 소스를 다 날리곤 했는데, 이제 무슨 이유로 이렇게 생성했는지가 직관적으로 한눈에 보이니 수정이 매우 편해졌다.

     중복된 항목도 줄어들면서, 수정했을 때 사이드 이펙트도 적었고, 접근제어자나 반환타입, 컬렉션 등을 자유롭게 이용할 수 있게 된 것도 수정하기 좋게 만든 이유 중 하나이다. 본인 코드를 본인도 수정이 못한다면, 그 코드가 정말 너무 아니거나, 실력이 부족한 것으로 생각하는데, 그 둘을 탈피하게 되어 매우 기쁘다.

    9. 인텔리제이를 사용할 수 있게 됨

     원래는 이클립스만 가끔 사용하다가, 우아한 테크코스 프리코스 미션을 통해 인텔리제이를 처음 사용해보았다. 초반에는 어색하기도 하고 단축키도 달라서 매번 검색해봤었는데, 3주차 미션을 끝낸 지금은 자주 쓰는 기능의 경우 인텔리제이가 더 편하게 느껴지기까지 했다. 앞으로도 많이 사용하면서 다양한 내장 기능을 활용하고 싶다.

    ?. 나라는 사람에 대해 새롭게 알게 됨

     새벽까지 코딩에 매달릴 수 있는 사람, 1박 2일 여행 갈 때 노트북을 챙겨가서 틈틈이 코드를 짜는 사람(구박은 받았지만), 과제를 재미있게 하는 사람, 미션이 주어지면 그것을 해냈을 때뿐만 아니라 헤쳐나갈 때 기분 좋음을 느끼는 사람, 공부하면서 발전해나가는 나를 보며 행복해하는 사람

     프리코스를 진행하면서 내가 생각한 나와는 약간 다른 나를 새롭게 알게 되어 정말 뜻깊었다. 프리코스 시작 전만 하더라도 온라인 교육도 아닌 미션에 대한 과제 제출로 뭔가 많이 배워갈 수 있겠느냔 고민을 했는데, 정말 부질없는 고민이었다! 한 주 한 주 미션을 진행하면서 알게 되는 것들과 익숙해지는 것들, 그리고 그걸 진행하는 나. 나라는 사람에 대해 새로 알게 된 부분만 생각하더라도 정말 뜻깊고, 재미있던 삼 주였다.

     이 느낌을 나중에 또 되뇌기 위해, 그리고 다른 우아한 테크코스에 관심 있어 하는 사람을 위해 블로그에 포스팅 해둔다.

     

    반응형

    댓글

Designed by Tistory.