20201023-TIL

나영원·2020년 10월 23일
1

T.I.L.

목록 보기
59/145

오늘 공부할 내용

  • 프로젝트 진행
  • 프로젝트 발표 & 발표듣기
  • 프로젝트 정리
  • DB퀴즈
  • TiL 정리 및 블로그 업데이트

오늘 공부한 것 & 배운 내용

  • 출근길 강의

    • 스프링 입문 강의
      • 데이터 베이스의 접근하는 기술인 Jdbc 를 사용하고 그다음 Jdbc Templates를 사용하고 그다음 JPA를 사용하는 예제를 보여주셨다
        • 우리가 사용하는 기술이 어떻게 발전했는지 볼수 있었고 앞으로 배워나갈 기술들이 어떤것인지 대략적으로 파악할 수 있어서 좋았다
        • 하나의 기술을 너무 깊게 파지 말라고하신 강사님의 말씀이 조금 이해가는게 같은 역할을 하는 여러개의 기술이 있고 회사마다 그 기술중 하나를 선택해서 사용하기 때문에 내가 취직하는 곳에서 사용하는 기술이 무엇인지 알고 깊게 파도 늦지 않기 때문인 것 같다
          • 큰 줄기에서 자바와 스프링 스프링 부트 프레임웤으로 웹 어플리케이션의 백앤드 부분을 개발하기로 이미 정했지만 스프링 자체도 방대하고 데이터베이스와 연결하는 기술 자체도 방대하기 때문에 더 그런 경향성이 생기는 것 같다
          • 그래서 지금 과정에서는 웹 어플리케이션 개발에 어떤기술들이 있는지 파악하고 그것에 대해 어느정도 사용법을 익히는게 중요할 것 같고 또한 전체적인 워크플로우가 어떻게 돌아가는지 파악하고 적응하는데 더 방점을 두어야 할 것 같다->굿!
  • 준비시간

    • 5분명상, 10분독서 , TIL 정리
      • 아침 루틴이 어느정도 정리되어져서 기분이 좋다. 출근 시간을 앞당긴 덕에 이렇게 여유있게 시작해도 정규시간보다 30분정도는 일찍 시작할 수 있어서 공부에도 도움이 된다
        • 앞으로의 과제는 이렇게 부지런하게 움직이면서 생기는 피로를 효과적으로 해소할 방법을 찾아야 꾸준히 지속할 수 있을 것 같다
  • 아침 공부시간

    • 프로젝트 진행

      • 어제 구현한 부분 검토

        • 어제 했던 부분을 어떻게 개선할까 고민하면서 보다가 동료가 업데이트 해놓은 부분있다고 해서 update를 했는데 내용이 많이 변경되서 기존의 내가 업데이트한부분들이 날아가버렸당

          • 이래서 협업을 하더라도 같은 부분은 작업하는게 아니라는 것 같다
          • 이런 부분을 겪으면서 협업을 위한 툴인 깃을 잘못쓰는게 많이 답답하다.. 깃에 언능 익숙해지는게 또하나의 목표가 되었다
      • 테스트하는 방법 찾아서 작성한 코드 테스트해보기

        • 테스트하기 위해서 System.in과 out을 테스트 하는 예재를 찾아 따라해보는데 이해가 쉽지는 않는다
          • 거기다 지금 내가 테스트하는 메소드가 출력부터하고 입력을 받는 메소드라 어떻게 테스트해야 될지 잘 모르겠다
          • 결국 테스트는 진행하지 못하고 마무리 되었다. 이번 프로젝트에서는 테스트에 중요성에 대해 어렴풋이나마 경험한것으로 만족해야 할 것 같고 테스트를 더 공부해서 다음 프로젝트에서는 테스트위주의 개발이 될 수 있도록 준비해봐야겠다
  • 오후 프로젝트 발표

    • 발표전 잠깐 준비하는 시간이 있었는데 이미 동료가 내부분까지 하고 있던상황이라 내가 더할영역은 없었고 같이봐주는걸로 마무리했다

    • 발표또한 동료가 주도해서 진행했고 아쉬워서 한마디 덧붙이기는 했지만 별 얘기는 못하고 마무리되었다

      • 좋은 기회를 활용할 수 없는게 아쉬웠고 언능 실력을 키워서 한사람 몫을 해야 이런 기회 붙잡을 수 있을 것 같다
      • 강사님 께서 명세위주로 설계를 하고 진행하면서 설계를 조금더 유연하게 가면 더 잘풀릴 거라는 피드백을 주셨다
      • 또한 DB는 다른곳에서 접근을 하면 안되니 싱글톤패턴으로 구현하지 않는다고 말씀해 주셨다
        • 사실 피드백도 내가 진행한게 아니라서 많은 도움이 되진 않지만 프로젝트 복습할 때 도움이 될 것같다
    • 다른 조 발표들으며 느낀점

      • 발표시간 좋은 기회인데 준비 잘 안된 조들에 대해서는

      • PPT형태로 준비해서 목록을 만들고 순서대로 진행하니 어떻게 진행하는지 이해하기 좋았다

      • 주제선정이유, 개발 시간 투자비율 등 프로젝트 진행에 대해 전반적인 정보를 제공하는 것도 좋았다

      • 시연할 때는 모든 기능을 다구현한것을 보이는것보다 핵심기능을 보여주면서 너무 지루하지 않게 구성하는게 좋을 것 같다

      • 아직 구현하지 못한 기능이라도 앞으로 이렇게 구현해나갈것이라고 이야기하는 것도 상상해볼수있고 좋았던것 같다

        • 대부분 내 주관적인 평가라 참고할만한지는 모르겠지만 어떤식으로 발표하는게 좋은지 고민해보는것도 중요한 주제라는 것을 배웠다
  • 저녁 공부시간

    • DB퀴즈

      • 두시간 조금 안되서 quiz2를 모두 풀었다

      • 기본적으로는 GROUP BY와 COUNT, SUM 등의 예약어를 사용한는 것이고 1번문제는 못풀어서 검색해보니 DISTINCT라는 예약어로 중복값을 모두제거하고 COUNT하면 풀수있는 문제였다

      • 이번 퀴즈를 통해 수업에서 배운 예약어들을 연습하고 CONCAT, DISTINT같은 예약어를 검색을 통해 배울 수 있었다

  • 프로젝트 정리

    • 진행한 프로젝트의 과정들을 돌아보면서 배운점들을 정리해 보는 시간을 가졌다

    • 주제선정 및 구상

      • 주제 선정은 큰 이견 없이 가장 낮은 난이도로 되어 있는 가계부로 결정되었는데 다른 주제들보다 하나의 어플리케이션 서비스를 개발하는 경험을 해볼수 있어서 잘 선정 한 것 같다
      • 구상 단계에서는 프로젝트 첫날에 전체적인 구현범위 설정과 유저시나리오, 소프트웨어 구조설계를 동시에 진행하였다
        • 구현하고 나서 보니 첫날에 서로 진행하기로 합의한 대로 거의 진행이 된 것을 보면 이 과정이 당시 생각 했던 것 보다 더 중요했던 것 같다
          • 실제 진행해보니 첫날 합의 이후에는 대부분에 작업을 각자하게 되니 첫날 이야기한 부분을 다른 방향에서 목표로 하며 진행을 하게 되고 중간중간 진행하는 회의는 전체적인 내용보다는 세부적인 내용을 결정하는 내용이 많았기 때문인 것 같다
            • 첫 회의 때수입 거래와 지출 거래를 한번에 두는 것이 좋지 않을까 싶었는데 결국 끝내고보니 나눠서 진행하는게 좋았던 것 같다
              • 이렇게 처음 구조잡을 때 어떻게 할지 잘모르겠는 것은 조금 더 진행되면서 이야기 해볼수있는 주제로 정해놓으면 더 도움이 될 것 같다
    • 애플리케이션 구현

      • 구현을 분담하여 cui를 어떻게 구현하라는 말을 듣는데 사실 하나도 알아 들을 수가없어서 이걸 어떻게 구현해야하나 하고 막막함이 앞섰다
        • 전체적인 구조를 이해할 수 없어서 내가 구현하는 부분과 뒤에서 구현하고 있는 내용들이 어떻게 연결되는지 그려지지가 않아서 어떻게 입력을 받고 처리를 해나가야될지 머리속이 깜깜했다
          • 걱정을 많이 하다가 이때 어쩔수 없으니 일단 말이 되든 안되는 모양이라도 갖추어 구현을 시작하였고 다행히 그후 여러번의 리팩토링을 통해 최종적인 모습의 뼈대를 만들 수 있었다
            • 이해가 안될때는 일단 이해한만큼이라도 구현해보고 결과를 보여주면서 리팩토링을 해나가는 것도 하나의 방법이라는 것을 배웠다
          • 지금 완성된 모습을 보면 cui - 서비스 - 모델 - 리파지토리 - 데이터소스 등으로 이어지는 구조를 적당히는 이해할 수 있게 되었는데 만약 이런 구조를 명확히 도식화 해서 봤으면 더 도움이 되지 않았을까 생각을 해본다
            • 이런 어려움들은 중간에 동료에게 설명해주시는 것들이 이해가 어렵다고 소통하면서 동료도 더 배려해주었고 나도 모르는 것들은 모르겠다고 확실히 표현하려고 노력하며 서로 더 나아진 것 같다
      • 한번 구현하고 결과를 가지고 이야기를 나누니 내가 더 고려해야 하는 부분들에 대해서 이야기를 나눌 수 있었고 정말 기본적인 것들에서 실수한 부분들도 많이 찾아서 고쳐볼 수 있었다
        • 이런 리뷰를 받으면서 스스로 부족한 부분들에 대해서 많이 발견하고 또 부족한 부분을 채우기 위해서 고민하는 과정에서 스스로 성장하고 있다는 느낌을 받았다.
          • 리뷰나 피드백을 받을 수 있는 환경이 성장을 위해 정말 중요하구나 라는 것을 경험할 수 잇었고 앞으로 취직 준비하면서 코드리뷰를 자주 진행하는 환경을 우선순위로 두어 결정해야겠다는 생각을 했다
            • 이런 장점들을 알고나서 강사님께도 코드리뷰를 받았는데 동료에게 받을 때랑은 또 다르게 정말 많은 부분들을 배울 수 있었다
              • 리뷰를 요청하기가 어려웠는데 동료도 한번 받아보라고 하고 나도 용기를 내서 요청하여 리뷰를 받고 배운 부분들은 잘한 것 같다
      • cui에 다른 메뉴 구현에도 신경을 썻어야됬는데 input부분만 구현하고 계속 리팩토링 하다보니 다른 부분구현이 많이 빈약해져버렸다
        • 이부분은 서비스 구현이 너무 늦게되서 어떻게 내가 적용할 수 있는지 잘몰라서 일단 비워놨다고 변명하고 싶지만 그래도 구상이라도 명확하게 했어야 됬는데 프로젝트 후반기 까지 ?로 두고 갑자기 구현을 하려고 하니 용두사미가 된 꼴이 되어서 많이 반성이 된다
      • 프로젝트를 진행하면서 코드의 구현도 중요했지만 깃을 통해 협업하는 과정에서 꼬여서 파일이 날아가기도하고 동료가 해주지 않으면 멍하니 기다릴 수 밖에 없는 상황도 생겨서 깃을 잘쓰는게 얼마나 중요한지도 배우는 기회였다
      • 또한 동료가 치열하게 테스트코드를 작성하는 것을 보고 정말 테스트가 중요한 것이구나라는 것을 간접 경험 할 수 있었고 꼭찾아서 배워바야 될 것 같다
    • 발표

      • 위에도 작성했지만 정말 아쉬운 부분인데 거의 대부분의 과정을 동료가 주도하고 코드도 작성했기 때문에 내가 발표할 수 있는 부분이 없었고 자연스럽게 동료가 발표의 99.9%를 하였다
        • 그래도 생각해보면 구상이나 이런부분들은 같이했으니까 앞에부분은 내가 할 수 있었을 수도 있는데 발표준비를 할 시간을 거의 갖지를 못해서 그런 의견도 생각해보지 못했다
          • 다음에는 어덯게든 내가 할 수 있는 부분을 찾아서 조금이라도 기여하고 경험을 통해 성장할 수 있도록 목표를 설정해야겠다
    • 코드 리뷰

      • cui패키지

        • MenuController는 MainMenu와 다른 메뉴들을 연결시켜주는 클래스로 input이나 print와는 전혀 상관없이 다른 메뉴를 연결시켜주는 역할만 한다
  • 이렇게 역할이 분리되 몰라도 될것들을 최대한 모르게 구현하는것이 중요한 설계원칙이라고 한다..

  • InputHandler는 메뉴에서 받는 모든 input을 관리하는 친구로 Scanner가 아닌 bufferedReader를 통해 입력을 받아 입력속드를 빠르게 하였다

- 이렇게 input은 따로 input의 기능들을 통합하여 구현하는게 좋다고 한다

- 그리고 UIString이라는 constant를 모아놓은 클래스를 통해 상황에 맞게 출력될 메세지를 정리해두어 input과 함께 사용되게 하여 직관성을 높이고 분산되서 처리되던 메세지들을 한곳에 모아 처리할 수 있게 하였다
  • Menu인터페이스
- Menu들의 인터페이스로 메뉴들을 정의하고 또 다형성을 통해 사용될 수 있게 하는 역할을 한다
  - 어떤 메소드들을 추상화해야되는지 고민이 만힝 되었는데 최종적으로는 모든 메뉴에 들어가는 call()과 default 메서드인 backToMainMenu만 남게 되었다
- MainMenu
  - MainMenu는 MenuType에 있는 메뉴들을 통해 구현된 MainMenu에 목록을 띄워주고 입력을 받아 해당 입력을 MenuController에 전달하는 역할을 한다
    - 메뉴들을 Enum을 통해 관리하는 방식은 처음에 Menu를 모두 클래스로 만들었더니 클래스를 줄이면 좋겠다는 피드백을 받고 생각해 낸 방식인데 그게 아니었다면 구지 Enum을 만들지 않거나 내부 Enum을 활용하는 방식으로 했었을 수 도 있을것 같다
- InputTransactionMenu
  - 수입과 지출을 service를 사용해 저장하는 역할을 하는 클래스로 사용자로부터 입력을 어떻게 받을 것인가에 관해 많이 고민을 한 클래스이다
    - 가장 많은 메서드들이 들어있는 클래스이고 그만큼 최적화를 위해서 많이 노력한 클래스이다
      - 특히 inputStatementMenu메서드는 특히 많은 조건문을 가진 클래스의 핵심 메서드였는데 여러번의 Extract Method와 리팩토링을 거쳐서 그래도 처음보다 많이 나아진 모습을 보여준다
        - 강사님께서 조건문을 예외처리와 본기능 같이 기능별로 구분하는게 좋다고해서 그것을 기준으로삼아 정리한게 많이 도움이 되었다
      - 또 피드백 중 기억나는 것은 입력받는 메소드에서 재귀함수를 사용하면 프로그램이 꼬일 수 있으니 사용하지 말라는 피드백을 듣고 재귀를 사용하지 않고 조건문을 사용하거나 아니면 그냥 다른곳으로 빠져나가게 처리했다
      - 마지막 피드백에서도 의미가 불분명한 메서드가 있다고 피드백을 받아서 속상하기도 했지만 그만큼 복잡하고 어려운 구현이 클래스였고 단순히 구현 해서 작동하는게 문제가 아니라 어떻게 구현해야 안전하고 깔끔하게 잘읽히는 코드를 짤수 있는가 라는 고민을 가장 많이 하게 해준 클래스이다
    - 많은 input을 받는 클래스라 vaildation이 중요하여 uitil 패키지에 validator라는 클래스를 따로만들어 모든 입력에 대한 검증메소드를 작성하였다
      - 처음으로 정규표현식을 사용해보았는데 사용하면서도 사실 잘이해가 가지는 않았고 보충이 필요할 것 같다
        - 하지만 정규식을 통해 효과적으로 입력을 검증하고 그외에 예외적인 것만 조건문을 통해서 하면 정말 좋은 검증메소드를 만들 수 있다는 것을 배웠다
    - 나는 list를 통해 입력 메뉴를 띄었지만 동료가 리팩토링 해준 것은 StringBuilder를 통해 하나의 String 형태로 만들어 메뉴를 띄운 모습을 보고 이렇게하면 테스트도 편할것 같아서 기억해두면 좋을것 같다고 생각했다
- addCategory, InitialzationMenu, Exit 
  - 모두 각각의 기능들을 구현하는 클래스로 좀더 구현에 대해서 고민을 더해봤으면 하는 아쉬움이 많이 남는 클래스들이다
  - 전형적으로 한쪽에만 집중하다가 다른쪽에 소흘하게 된 케이스인것 같아서 한번에 묶어서 리뷰를 해봤다

- 정리

  - 수준이 많이 높은 동료와의 프로젝트는 소통과 구현의 난이도가 높아서 나에게는 큰 도전들이 있어서 어렵고 지치는 순간들도 있었지만 그런 어려움들을 솔직하게 동료에게 표현하고 또 따라가기 위해 노력하는 과정에서 도움도 많이 받고 많이 성장한 것 같아서 좋게 평가하고 싶다
    - 물론 아쉬운 점도 많지만 이렇게 정리를 하면서 그런 아쉬운점들을 새로운 목표로하여 다른 프로젝트를 준비하는 시작으로 삼을 수 있어서 이 기분이 좋다 => 굿!

공부하면서 느낀점

  • 공부하다가 막히고 이해가 잘되지 않으면 굉장히 초조해진다.. 그래서 긴장감 해소하기 위해서 무의식적으로 폰보고 다른 일로 관심을 돌리는 것일 수 도있다
    • 모르는 부분을 만나 깊게 탐구할 수록 학습효과는 올라가지만 긴장감 또한 증가하는 현상인 것 같다
    • 앞으로 점점 더 공부가 어려워 질 텐데 이런 긴장감을 어떻게 해소하면서 공부할지 생각해보면 좋을 것 같다
  • 금요일인데다가 프로젝트까지 끝나서 대부분 사람들이 집에 일찍 돌아가고 혼자서 남아서 공부를 했다. 나도 조금 일찍 갈수도 있겠지만 다른 것보다 일찍 집에 가는게 하나의옵션이되서 저녁마다 내의지력을 시험하는 상황을 만들고 싶지가 않다
    • 시작은 목표와 의지가 중요하지만 지속은 습관적으로 하는 것이라는 책 'Habbit'에 내용처럼 크게 고민하지 않고 하던데로 공부를 지속하는 것이 이시간을 최대한 편안하고 성공적으로 보내는 비결이 될 것 같다

내일 공부할 내용

  • 프로젝트 정리 (코드 리뷰) 코드업로드,
  • DB 복습
  • 스프링 온라인 강의 완강하기
  • TiL 정리 및 블로그 업데이트
profile
배우는 개발 일기

0개의 댓글