마코

오전에는 페어프로그래밍으로 진행했던 자동차경주미션을 주제로한 강의를 들었다. 코치가 driver, 다른 크루들은 navigator 역할로 자동차 경주미션을 구현했다. unmodifiable 컬렉션에 대한 내용이 나왔었다. 자바에서는 Collections.unmodifiableList 로 컬렉션의 요소에 대한 추가, 제거를 제한할 수 있다. 하지만 이는 요소의 상태나 값을 수정하는 것을 제한할수는없으므로 이를 주의하자.

오후에는 온보딩 조의 크루들과 자동차경주미션에 대한 피드백을 받고 궁금한점, 알면 좋은 지식등을 공유하고 토론했다.
- 예외 처리할 때 뷰와 도메인 둘다 하는 것이 좋다.
- 뷰와 도메인 둘다 해야하기 때문에 예외를 검증하는 Validation 클래스와 Exception클래스를 따로 선언하고 가져다 사용한다.
- unmodifiable에 대한 이야기.
- 파일의 끝에는 개행 한줄이 있어야 함. 없으면 한 줄이 끝나지 않은 것으로 인식해 정상적으로 동작하지 않는 문제가 발생할 수 있다. Github에서는 이러한 잠재적인 오류를 예방하고자 warning을 발생시킴.
- 클래스 이름을 Repository로 짓는 것은 Spring의 Repository와 혼동될 수 있기 때문에 다시 생각해 보아야 함.
각종 내용에 대해 토론하면서 적절한 근거를 대고 결론에 도달하는 것이 매우 재미있었다. 이렇게 얻은 지식은 금방 잊지 않고 오래 남을것 이라고 생각한다.

18시까지 온보딩미션 연극을 준비했는데 하염없이 준비를 하는것보다 끝나는 시간을 딱 정해놓고 준비를 하니 늘어지지않고 효율적이였다.

연극준비가 끝나고는 자동차경주미션의 피드백을 바탕으로 리팩토링에 돌입했다. 주로 객체의 책임명확하게 하는데에 집중했던것 같다. 아직 리팩토링할 부분이 조금 남았으니 내일 아침에 완성해야겠다. 미션을 진행하면서 시간이 부족해서 테스트가 빈약했던 부분이 있는데 이에 대한 피드백은 없었다. 테스트 코드도 다시 생각해보고 리팩토링 해야겠다.

9시~10시
객체지향의 사실과 오해"를 읽었다. 수학을 공부하면 집합이 가장 쉽듯이 이 책도 가장 앞의 커피 예제(손님, 캐시어, 바리스타가 협력하는 과정)가 가장 먼저 기억이 난다. 역할, 책임, 협력은 글을 읽을 때는 이해를 하지만 역시 많은 설계들을 보고, 해 보아야 완벽한 이해를 할 수 있을 것 같다.

10시~10시 30분
온보딩 조원들과 데일리 미팅을 진행했다. 미션과 관련된 이야기뿐만 아니라 가벼운 일상적인 이야기도 나누니 바쁜 일상속 즐거움을 찾을 수 있었다.

10시30분 ~ 18시
페어 미션의 pr제출 기한이 18시였고, 어제 기능 자체는 완성을 했던 터라 나름 여유가 있었다. 리팩토링 위주로 진행했는데 설계를 많이 변경했다. 설계를 변경하는 과정에서 나는 아직 스프링을 모르는데 비버는 스프링mvc의 구조를 생각해서 이를 이해하는 것이 어려웠다. 이해가 잘 되지 않아 내 머릿속의 설계를 다 지워버리고 하나씩 이해를하니 이해를 할 수 있었다. 비버가 인터페이스 이야기를 꺼내서 인터페이스도 사용하여 더 깔끔한 코드를 작성할 수 있었다. 인터페이스를 사용하면 장점이 ~~~ 있었는데 생각이 잘 나지 않아 다시 정리를 해야겠다.
설계를 변경하다보니 갑자기 시간이 촉박해져 테스트 코드를 리팩토링하지 못해 아쉬웠다.
리팩토링을 끝내고 pr을 제출해야 하는데 비버의 repo에서 내 repo로 코드를 가져와서 pr을 제출해야 하는데 여기서 많이 헤멨다. 이 방법도 다시 정리를 해야겠다.

오전에는 세 가지 내용의 강의를 들었다.
1. 우테코에 임하는 자세
우테코는 물고기를 잡을 수 있는 환경을 만들어 준다.
2. 단위 테스트
main method를 테스트 했을 때의 문제점, JUnit, assertion

• 내가 단위 테스트를 작성하는 이유는 무엇인가?

->모든 기능이 잘 작동하는지 테스트하기 위해

• 내가 작성한 좋은 단위 테스트는 어떠한 부분에서 좋은 단위 테스트라 느꼈는가?

-> 예외를 발생시킬 수 있는 값을 예상하여 테스트함

• 위와 같은 좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가?

-> 경계값 검증


3. 코드 품질

• 코드 품질이 중요한 이유 중 가장 와닿는 이유는 무엇인가?

-> 보기 좋은 코드. 보기 싫은 코드를 봤을 때 이해를 하기 싫은 경험이 있다. 따라서 보기 좋은 코드가 가장 와닿았다.

• 위 이유를 만족하기 위한 코드를 작성하기 위해 어떠한 노력을 해봤는가? 혹은 할 예정인가?

-> 다른 개발자가 내 코드를 본다는 관점에서 코드를 작성한다.

• 코드 품질을 높은 코드를 작성하는 프로그래머가 훌륭한 프로그래머인가? 그렇게 생각한 이유는 무엇인가?

-> 훌륭한 프로그래머이다. 프로그램의 완성은 런칭이다. 즉, 이제 시작이기 때문에 앞으로 많은 유지보수 작업을 해야함. 앞으로의 작업을 하기 위해 좋은 품질의 코드에서 시작해야 다른 사람이 코드를 이해하고, 수정할 수 있고, 비용도 적어지기 때문


오후에는 페어프로그래밍을 시작했다. 요구사항을 먼저 정리하고 설계는 따로 하지 않고 프로그램의 실행의 흐름대로 프로그래밍하기 시작했다. 오랜만에 코딩을 하니 설계에 너무 무심했다는 생각이 들었다. "객체지향의 사실과 오해"를 다시 읽어보며 객체지향에 대해 다시 고민하는 시간을 가져야겠다.
테스트를 작성하는 과정에서 페어에게 @DisplayName과 @Nested의 사용법에 대해 알려줬다. 코딩을 오랜만에 해서 기억이 잘 나지 않았는데 알려주면서 나도 공부가 되었다.
내가 여러 String을 ,를 구분자로 연결하는 ( ex) a, b, c, d ) 메서드를 작성할 때 StringBuilder 를 사용해서 구구절절 코드를 작성하고 있을 때 페어가 String.join을 사용하는 것을 제안했다. 코드가 한줄로 줄어드는 것을 보고 매우 기분이 좋았다.
로직 오류가 발생했을 때 서로 고민하고 해결하는 과정이 재미있었다.
테스트를 작성할 때 private으로 사용하는 아주 작은 기능에 대한 테스트를 할 것인지, 랜덤 테스트는 어떻게 할 것인지 결정하는데에 어려움을 겪었다.
코딩에 대한 생각이 서로 다를 수 밖에 없으므로 상대에게 나의 생각을 타당한 근거를 기반으로 설득해야한다. 그 과정에서 내가 코딩하는 근거를 확실하게 함으로서 근거가 적절하면 확신이 들고, 그렇지 않으면 적절하지 않을 수 있다는 생각이 들었다.

[많은 시간을 투자한 부분]

피어 리뷰

이번 프리코스를 진행하면서 현업에서 프로젝트를 진행한다는 마인드로 프리코스에 임했습니다. 그 중 실천하고자 했던 것이 “주 1회 피어 리뷰 실천하기” 이었습니다. 매 주 저의 PR링크를 올렸으나 3주 차 과제를 올렸을 때 처음으로 리뷰를 받았습니다. 리뷰의 내용과 공통 피드백을 비교하면서 공통 피드백의 내용도 실제로 어떻게 적용할 수 있을지 이해가 되기 시작했습니다. 리뷰를 바탕으로 리팩터링을 하는 과정에서 getter를 어떻게 줄일 것 인지, 객체의 책임 분배를 어떻게 할 것인지, 테스트 코드 리팩터링 등 많은 깨달음을 얻었습니다.

2. 컨트롤러 분리

처음 설계에서는 메인 컨트롤러 1개가 모든 control flow를 담당하고 있었습니다. 구현을 하는 과정에서 요구사항인 메서드 10 라인을 넘기지 않기가 매우 어려웠습니다. 컨트롤러 또한 분리가 필요하다고 생각해서 초기 설정을 담당하는 SettingController와 게임 플레이를 담당하는 PlayingController로 분리하고 이 두 가지를 제어하는 BridgeController 로 설계를 변경하니 컨트롤러의 책임이 더 명확해졌습니다.

3. 리팩터링

이번 과제는 완벽한 설계를 하려고 너무 많은 시간을 쏟지 않으며 구현을 하고, 리팩터링을 하는 방식으로 진행했습니다. 구현한 기능 중에서 “이동한 칸을 선택해서 정답이고 다리의 끝에 도착하면~” 또는 “이동한 칸이 오답이고 재시도 입력을 받으면~” 와 같은 기능을 의식의 흐름대로 중첩 if문과 반복문으로 작성했습니다. 완성된 코드를 보고 if문 줄이기, Enum 사용, 메서드 분리 등 하나씩 개선하면서 훨씬 가독성이 좋은 코드로 리팩터링에 성공했습니다.

[배운점]

1. 객체답게 사용하기

이전에는 필요한 값들에 대해 인스턴스 변수를 선언하고 이에 대해 get해서 사용하는 방식으로 구현을 했습니다. 피어 리뷰와 공통 피드백을 수용하여 값을 get해서 외부에서 계산하지 않고, 필요할 때 객체 내부에서 계산해서 결과만 돌려주는 형태로 구현했습니다. 이러한 과정에서 인스턴스 변수도 줄고, getter도 없어져서 더 깨끗한 코드를 작성할 수 있었습니다.

2. 명확한 예외 처리

예외처리를 할 때 단순히 Exception e; e.printStackTrace; 로 구현을 하곤 했습니다. 이렇게 구현하니 다른 사람은 나의 코드를 보고 어떤 예외가 발생할지 예측이 어려웠습니다. 이번 과제를 진행하면서 잘못된 입력에 대하여 예외를 명확하게 지정함으로써 처리한 예외의 범위가 확실해지고 가독성이 높아지는 것을 느낄 수 있었습니다.

[느낀점]

기능 목록 분리, 클래스 분리, 테스트, 리팩터링 등 처음에는 매우 어렵고 고민도 많이 했지만 조금씩 익숙해 지는 것을 느꼈습니다. “첫 술에 배부를 수 없다.” 라는 말처럼 꾸준히 적용하고, 피드백을 수용하며 학습을 하다 보면 저도 좋은 개발자가 될 수 있을 것 이라고 생각했습니다.

이번 프리코스를 진행하며 1주 마다 제출했던 과제를 보면서 1주일 마다 크게 성장한 것을 확인할 수 있었습니다. 이 과정을 모두 마치고 많은 것을 배우고 경험하며 성장했음에 매우 뿌듯합니다.

[많은 시간을 투자한 부분]

1) 클래스(객체) 분리

첫 단추가 잘 꿰어져야 그 이후가 순조롭게 진행된다고 생각하여 객체를 설계하는 데 시간을 많이 투자했습니다. 2주 차 미션까지는 단순히 기능을 먼저 정리하고 기능에 따라서 클래스를 분리했습니다. 이러한 과정에서 무언가 체계적이지 않고 확실한 기준 없이 내 마음대로 객체를 설계한다는 생각이 들었습니다. 따라서 3주 차 미션에서는 객체 설계 방법에 대해 학습했으며 그 중 도메인 모델을 사용해 설계하였습니다. 그림으로 직접 도메인 모델을 설계한 결과, 구현하기 위해 필요한 객체들과 그 책임이 명확해지고, 협력 또한 한 눈에 파악할 수 있었습니다.

역시 과제를 하면서도 모호했던 것이 데이터를 꺼내서 사용하는 getter 였습니다. 꼭 필요했다고 생각했었지만 

2) 예외 처리

기본으로 제공된 ApplicationTest의 예외_테스트() 부분에서 어려움을 겪었습니다. 예외_테스트() 에서는 assertThatThrownBy() 으로 예외를 체크하는 것이 아니라 assertThat(output()).contains(ERROR_MESSAGE) 로 출력 메시지만 체크를 했기 때문에 단순히 throw new IllegalArgumentException 으로 구현하면 테스트에 실패했습니다. 제공된 기능 요구 사항에는 “사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 종료한다.” 라고 되어 있었기 때문에 예외 처리를 하지 않고 메시지만 출력할 수도 없었습니다. 여러 가지 방법을 고민했고, 예외가 발생하는 부분을 throw하고, 구현된 기능들을 사용하여 전체 로직을 구성하는 매니저에서 catch하여 전체 로직을 멈추고 예외와 메시지를 출력, 종료하도록 구현했습니다.

3) 도메인 로직과 UI 분리

도메인 로직과 UI를 분리하기 위해 가장 널리 알려진 MVC 패턴에 대해 학습했습니다. 학습하는 과정에서 모델, 뷰, 컨트롤러로 분리한다는 것은 알겠는데, 내 코드를 실제로 어떻게 분리할 수 있을지에 대해 고민을 했습니다. 처음에 설계한 도메인 모델에 객체들을 사용하는 매니저 단을 추가하여 해결할 수 있었습니다. 매니저에서 전체 로직을 수행하며 필요한 UI 클래스와 도메인 클래스를 사용하는 방식으로 프로그램을 완성해 도메인 로직과 UI를 분리할 수 있었습니다.

[느낀 점]

추가된 요구 사항 중에서 함수의 길이를 15라인으로 제한하는 점이 좋았습니다. 길이가 긴 함수는 두 가지 이상의 기능을 할 가능성이 높기 때문에 분리되지 않은 기능을 더 세분화하여 분리할 수 있었습니다.

if-else 문을 사용하지 않음으로써 가독성이 매우 향상된 것을 느꼈습니다.

2주 차 미션에서는 도메인 로직과 UI 로직을 분리하지 않아서 테스트를 진행할 때 중복이 존재하는 등 애매한 부분이 있었습니다. 3주 차 미션을 진행하면서 도메인 로직과 UI을 분리하고 테스트를 진행해 보니 명확한 테스트를 진행할 수 있었습니다.

[배운 점]

[Enum]

enum은 다른 언어에서도 사용해본 적이 있지만 단순히 가독성만 늘려주는 정도였습니다. 하지만 JAVA에서의 enum은 훨씬 더 강력했습니다. 특히 enum클래스에 메서드를 구현할 수 있는 점이 인상 깊었습니다. 직접 예제를 만들어 보며 enum에 대해 학습하고 블로그에 글을 작성했는데, 그 과정이 매우 재미있었습니다.

작성한 블로그 : https://matouslescotousles.tistory.com/6

[SOLID]

클래스를 분리하기 위해 객체 설계에 대해 학습하던 중 SOLID에 대해 알게 되었습니다. Single Responsibility Principle 는 우테코 프리코스 1주 차 부터 강조했던 부분이여서 매우 반가웠습니다. 특히 Open/Closed Principle 원칙의 인터페이스에 의존하는 코드의 장점을 자주 사용하는 Collection 클래스를 통해 느꼈습니다.

작성한 블로그 : https://matouslescotousles.tistory.com/7

[immutable vs mutable]

테스트를 작성하던 중 에러가 생겨서 디버깅을 진행했습니다. List에 retainAll() 연산을 수행하는 부분이 있었는데, 테스트 코드에서는 List를 List.of()를 통해 immutable한 list로 초기화하고 있었습니다. 따라서 retainAll() 연산을 진행할 새로운 mutable list를 생성하여 리턴하도록 구현했습니다. mutable list와 immutable list가 나뉘어져 있다는 것을 처음 알았으며, 안정성을 위해 가능한 immutable을 사용해야 한다는 생각을 했습니다.

[도메인 로직과 UI 분리의 중요성]

도메인 로직과 UI를 분리하는 방법에 대해 학습하던 중 한 동영상에서 설명한 내용이 있었습니다. 우리가 지금 작성하는 프로그램의 입출력은 콘솔이지만 입출력을 윈도우, 웹, 모바일로 변경했을 때를 생각해 보라는 내용 이었습니다. 도메인 로직과 UI 코드를 섞어서 구현할 경우 이를 전부 새로 구현해야 된다는 생각에 도메인 로직과 UI 분리의 중요성에 대해 깨달았습니다.

시청한 영상 : https://www.youtube.com/watch?v=efMRwQwxmJM

[많은 시간을 투자한 부분]

2주차 야구 게임 미션의 목표는 함수를 분리하고 각 함수별로 테스트를 작성하는 것에 익숙해지는 것 이었습니다. 작은 단위의 테스트를 잘 하기 위해서는 함수를 기능별로 가장 작게 분리하는 것이 중요하고, 이를 달성하기 위해서는 객체지향 설계가 가장 중요하다고 생각했습니다. 따라서 책 “객체지향의 사실과 오해”에서의 설계 방법을 직접 적용해보았습니다. 가장 먼저 도메인 모델을 설정하고, 객체들이 해야 할 “행동”과 “책임”을 기준으로 객체를 설정했고, 객체가 하나의 책임만 담당하도록 하였습니다. 결과를 출력하는 객체는 결과를 검증하는 객체로부터 결과 값을 받아오는 “협력”을 하도록 설계했습니다. 객체들이 해야 할 행동들을 정했더니 객체별로 구현해야 할 함수들의 목록이 구체화되었습니다. 이에 따라 구현해야 할 기능 목록들을 정하고 구현했습니다.

과제에 구현되어 있는 테스트는 통합 테스트였습니다. 처음에는 구현되어 있는 테스트 코드에 테스트 케이스를 추가하는 방식으로 테스트 코드를 짰습니다. 테스트 케이스 추가를 ApplicationTest 파일에 했는데, 이렇게 하니 과제 제출의 예제 테스트에서 “예기치 못한 오류로 인하여 실행에 실패하였습니다.”가 발생했습니다. 로컬 환경에서는 테스트가 잘 되었기 때문에 결과에 많은 의문을 품고 고민했습니다. 웹에서의 예제 테스트가 ApplicationTest를 기반으로 테스트한다고 예상했고, ApplicationTest 파일을 처음 상태로 복구하고, 테스트 파일을 따로 만들어서 테스트했습니다. 테스트 코드를 다시 분석을 해보니 추가한 테스트 케이스를 잘못 구현했을 수 있다는 생각을 했습니다.

[느낀 점]

과제를 완성하기 위해 학습을 진행하며 많은 내용들을 습득했습니다. 코드를 분석하는 과정, 새로운 지식들을 학습하면서 학습한 내용들을 정리해야겠다는 생각이 들었습니다. 어떻게 정리를 할지 고민하던 중 “리처드 파인만 공부법”에 대해 알게 되었습니다. “리처드 파인만 공부법”은 자신이 학습한 내용을 다른 사람에게 가르침으로써 자신의 이해를 증명하는 공부법입니다. 따라서 제가 학습한 내용들을 다른 사람에게 가르침으로써 저의 확실한 학습을 하기 위한 블로그를 개설하였습니다.

블로그 주소 : https://matouslescotousles.tistory.com/

[배운 점]

이번 프로젝트를 진행하면서 테스트 코드의 중요성을 깨달았습니다. 이전에는 단순히 프로그램을 실행시켜서 값을 입력하고, 출력되는 결과를 보고 테스트를 손수 진행했습니다. 작은 프로그램이였기 때문에 그동안 문제가 없었지만, 프로젝트가 커지면 이러한 방식으로 테스트를 하기 어렵겠다는 생각이 들었습니다. 이번 과제를 진행하면서 함수를 작은 기능으로 나누고, 이에 따라 테스트를 진행하면서 각 기능에 대한 테스트를 명확하게 할 수 있었습니다.

[JUnit5와 AssertJ]

구현되어있는 테스트 코드를 분석하며 JUnit5와 AssertJ의 사용법을 학습했습니다. 코드를 분석하다 보니 mock 객체가 있었습니다. 실제 객체를 만들어 테스트를 하기에는 불필요한 요소들이 많기 때문에 mock 객체에 필요한 데이터만 담아 테스트를 하는 것이 흥미로웠습니다. 테스트를 진행하며 JUnit5와 AssertJ의 기능이 막강하고 가독성이 뛰어남을 직접 느꼈기 때문에 애용해야겠다는 생각을 했습니다.

[나의 고민]

프리코스 1주차 과제를 보자마자 든 생각은 '쉽다' 라는 것 이었습니다.

과거에는 과제를 보자마자 손부터 움직였겠지만, 이번 프리코스는 합격보다는 나를 성장시키는데 의의를 두었고, "남이 보기 좋은 코드", "클린 코드"를 작성하는 실력을 키우기 위해 노력했습니다. 이에 따라 여러가지 고민에 빠지기 시작했으며 다시 과제가 '어렵다' 라는 생각이 들었습니다.

처음에는 기능 목록에 대한 고민이었습니다. 기능 목록을 만들고, 기능 단위로 커밋을 하라고 했는데 하나의 기능의 범위가 어디까지인지를 정하는 것이 너무 어려웠습니다. 전체 기능을 하나의 기능으로 볼 수도 있고, 계산, 행위 하나하나를 모두 기능으로 볼 수도 있기 때문입니다. 고민을 하다 보니 코드를 한 줄도 쓸 수 없었고, 계속 생각만 했습니다. 오랫동안 고민한 결과 저는 한 가지에만 집중하기로 했습니다. 바로 "남이 보기 좋은 코드를 작성하자“ 이었습니다. 기능의 단위를 어떻게 나누는 것이 정답인지 고민을 하기 보다는 다른 사람이 봤을 때 더 간결하고 보기 좋으면 된다고 생각했습니다. 그에 맞게 기능을 나누고, 코드를 작성했습니다.

다른 고민은 객체지향에 대한 고민이었습니다. 간단한 알고리즘 문제이더라도 자바로 푸는 문제이기 때문에 최대한 자바스럽게, 객체 지향을 연습한다는 생각으로 코드를 작성했습니다. 그래서 새로운 클래스도 생성하고, 게터와 세터를 열심히 만들며 문제를 풀었습니다.

문제를 풀다 보니 문득 내가 풀고 있는 방식이 맞나? 라는 생각이 들었습니다. 구글 자바 컨벤션을 찾아보다가 알게 된 사실이 소스 파일마다 각자 최상위 클래스 1개만 사용하도록 권고하는 것 이였습니다. 하나의 파일에 다른 클래스들을 생성하던 저는 부끄럽다는 듯이 클래스를 지워버렸습니다.

객체지향이란 뭘까 라는 고민을 하며 "객체지향의 사실과 오해" 라는 책을 읽었습니다. 책의 내용 중 "클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하라. " 라는 구절을 읽고 세게 맞은 기분이 들었습니다. 나는 여태껏 클래스와 메서드에만 집중했고 그것이 객체지향이라고 생각했었기 때문입니다.

코드를 지우고 쓰기를 반복하며 저는 제가 처음 작성했던 코드가 못생겼다는 것을 깨달았습니다. 이를 개선하기 위해 각종 조사와 검색을 통해 코드를 리팩토링하며 코드가 조금씩 나아지는 것을 느꼈습니다. 여전히 부족하다고 생각하지만 프리코스 1주차 만에 성장했음을 느껴 행복합니다.

[깃 커밋 컨벤션]

깃을 사용해 본적은 있지만, 그렇다고 능숙하거나 잘 사용하지는 않았습니다. 이전에는 커밋의 단위와 메시지를 마음대로 하며 코드를 저장하는 용도로만 사용했습니다.

깃 커밋 컨벤션을 보면서 커밋의 단위를 기능 단위로 나누고, 메시지 또한 컨벤션에 맞게 작성하기 시작했습니다. 컨벤션에 맞게 작성을 하다 보니 커밋은 단순히 코드를 저장하기만 하는 것이 아니라 코드를 유지보수 하기 위해서 어떤 시점에 어느 코드가 추가되었는지 명확하게 알 수 있어야 한다는 생각이 들었습니다. 따라서 커밋의 중요성에 대해 깨닫게 되었으며, 좋은 커밋에 대해 고민하게 되었습니다.

[람다식]

Collection의 Comparator를 구현하는 과정에서 코드가 길고 불편한 것을 느꼈습니다.

이전에는 신경쓰지 않고 문제를 해결하는 것에만 집중했겠지만 조금 더 보기 편한 코드를 작성하기 위해 람다식을 처음으로 사용했습니다. 람다식을 사용하니 코드가 간결해지는 것을 느꼈고, 앞으로도 람다식을 사용하는 것을 연습해야겠다고 생각했습니다.

[기능 목록 작성 및 기능 단위 커밋]

무작정 손부터 움직이며 코드를 작성해왔던 저는 방식의 잘못됨을 깨달았습니다. 이전 방식은 개발시간을 단축시킬 순 있지만, 프로그램이 조금만 복잡해지면 구조가 잘못되어 효율성이 극히 떨어진다는 것이었습니다. 기능 목록을 작성하고 기능 단위의 구현을 하며, 필요한 것이 무엇인지 정리가 되고 짜임새가 있는 구조를 볼 수 있었습니다. 깔끔해진 코드를 보며, 아직은 어색하지만 기능 단위 개발의 중요성을 깨달았습니다.