총 4개의 미션을 완료하고나서, 프리코스를 하면서 좋았던 점들과 성장했던 부분에 대해 정리해보려고 합니다.😀

---

목차

1. Pure Java: 프리코스에서는 순수 자바만을 사용했다.
2. Clean Code: 다양한 요구사항으로 코드를 정리해야 했다.
3. Code Review: 서로 리뷰를 하며 성장했다.
4. Community: 다양한 의견을 주고받았다.

1. Pure Java

프리코스에서는 순수 자바만을 사용했고, 이번 7기에서는 JDK21을 사용했습니다. 지금까지 Spring Boot 외에는 java를 사용할 일이 없었습니다. 때문에 framework가 없이 java를 다뤘던 경험은, java라는 언어를 처음 사용할 때 말고는 없었죠.

프리코스 덕분에 framework가 없는 환경에서 미션을 진행하면 불편했던 점들이 정말 많았으며, spring boot 혹은 각종 도구가 어떤 도움을 주었는지 확실하게 깨닫게 되었던 경험을 했습니다. 지금까지 논리없이 작성했던 코드들이 부끄럽게만 느껴졌습니다. 순수 자바를 사용하면서 불편했던 점들을 정리해보려고 합니다.

Spring의 부재

spring의 부재는 많은 것들을 바꾸었습니다.

Spring Core

객체의 생성 및 생명주기 관리를 직접 해주어야 하며 객체간 의존성을 직접 주입해주어야 했습니다.

Spring의 @Component와 @Autowired를 통해 DI를 간단히 처리하고, IoC를 Spring 컨테이너가 대신 관리한다는 점에서 코드 가독성과 유지보수가 훨씬 쉬워진다는 것을 체감했습니다.

다음 코드는 4주차 미션에서 사용된, StoreController 에 의존성을 주입하는 메소드입니다. 뿐만아니라, 의존성 주입을 받는 각 클래스에는 생성자를 만들어야 했습니다.

고민해야 할 것은 한 두가지가 아니었습니다. 객체의 생명주기를 관리해야 했고 singleton을 보장하기 위해선 더 많은 코드가 필요했습니다. 또, 새로운 클래스를 만들었을 때 의존성 주입을 위해 다시 configureDependencies 의 코드를 수정해야 했으며 이는 OCP를 위반하게 되었습니다. Spring의 IoC 지원에 대해 개념만 이해하고 있었지만, 직접 이를 경험해보니 상당히 큰 부분을 담당하고 있다는 것을 이해하였습니다.

Spring Data (JPA)

JPA는 자바에서 객체와 관계형 데이터베이스 간의 Persistence를 표준화한 API입니다. 우테코에서는 데이터베이스가 존재하지 않았고, JPA또한 사용이 불가했습니다. 그래서 프로그램에서 다루는 데이터들을 모두 메모리에서 관리해야 했고, 적합한 자료구조를 고민해야 했습니다.

예를 들어서 '상품'과 특정 상품에 '프로모션'이 적용 가능하다면, 일반적으로 Database에는 상품 테이블, 프로모션 테이블, 상품과 프로모션 join 테이블, 수량관리 테이블이 존재할 것 같다.

그러나 데이터를 관리해줄 DB가 없었고, 메모리에 데이터를 관리한다고 해도 데이터를 검색, 조회, 삭제로직 모두 SQL없이 모두 직접 처리해야 했기에 불편했던 점들이 많았습니다. 또한 join을 해야하는 경우 처리해야 할 내용들이 많아지면서 관리해야 할 코드 또한 많아졌습니다.

예를 들어, 상품과 프로모션 간의 관계를 처리하기 위해 join 로직을 수동으로 구현해야 했습니다. 데이터가 복잡해질수록 join 및 검색 로직의 반복이 늘어났고, 유지보수가 어려워졌습니다. JPA의 @ManyToOne, @OneToMany 같은 어노테이션의 장점이 더욱 절실하게 느껴졌습니다.

DB없이 개발한다는 것이 얼마나 끔찍한 것인지 이해했고 JPA 뿐만아니라 SQL이 참 직관적인 언어라는 것을 이해할 수 있었습니다.

각종 도구의 부재

Lombok

Spring Boot로 개발을 할 때 Lombok 을 정말 유용하게 사용 했던 것 같습니다.

1. @Data
2. @Getter
3. @Builder
4. @NoArgsConstructor
5. @RequiredArgsConstructor
6. @NonNull
7. ...

개발을 편리하게 해주는 툴들이 없다보니 상당히 코드가 길어지고 관리하기 어려워졌습니다. 특히 @Builder 와 @NonNull 이 많이 그리웠습니다.

Framework가 없어서 필요했던 것들

그래서 framework의 도움 없이 개발을 해야했기에 각종 아키텍처 및 디자인 패턴을 이해해야 했으며 설계 원칙을 준수해야 그나마 읽을 수 있는 코드가 되었다😭.

각종 아키텍처 패턴

MVC패턴
프로젝트의 구조를 깔끔하게 분리하기 위해 프로젝트에 MVC패턴을 적용하였습니다. 수없이 경험했던 MVC에 대해 잘 알고 있다 생각하고 프로젝트에 임했지만 framework의 도움 없이 작성하려고 하니 감이 잘 안잡혔습니다. 그래서 MVC패턴에 대해 더욱 고민했고, MVC패턴의 주요 개념에 대해 더 확실히 이해할 수 있었습니다.

각종 디자인 패턴

각종 디자인 패턴들의 개념을 명확하게 이해하고 프로젝트의 적절한 위치에 적용할 수 있어야 했습니다. Builder, Static-factory-method, DI, Singleton, Observer, Command 등 여러 패턴들을 학습하였습니다. 그리고 프로젝트의 전체적인 가독성 및 응집도를 고려하여 정확히 필요한 부분만 적용하는 연습을 진행하였습니다.

각종 설계 원칙

SOLID, DRY, KISS, IOC 설계 원칙들을 기반으로 프로젝트에 임했습니다. 정말 고려할 것들이 정말 많았기에 쉽지 않았습니다.

---

2. Clean Code

우테코에서 미션에서 요구한 '요구사항'들입니다.

1. Indent depth < 3
2. 삼항연산자 사용 금지
3. SRP 준수 (method/class)
4. else 키워드 사용 금지, switch/case 사용 금지
5. 상수 처리하기
6. 메서드 길이 10줄 제한
7. 디미터 법칙 적용
8. 일급 콜렉션 적용
9. 원시값/문자열 wrapping 하기
10. 메서드 인자 수 제한
11. 클래스를 작게 유지 (결국 SRP)
12. 최소한의 멤버 변수

요구사항들은 'Clean Code'에서 강조하는 내용을 잘 반영하고 있습니다. 특히 디미터 법칙 적용이나 메서드 인자 수 제한은 처음에는 억지로 따르는 듯했지만, 프로젝트를 진행하며 코드의 응집도와 가독성이 높아진 것을 느낄 수 있었습니다. 다만, 모든 요구사항을 준수하다 보면 코드가 지나치게 분리되어 오히려 가독성이 떨어지는 경우도 있어 균형 잡힌 적용이 중요하다고 생각합니다.

---

3. Code Review

제 PR에만 300개가 넘는 대화가 이루어졌고, 제가 리뷰한 내용까지 합치면 더 많은 것 같습니다. 짧은 시간동안 이렇게 많이 리뷰한 적은 없었던 것 같습니다.

리뷰 중 한 가지 인상적이었던 점은 컨트롤러의 역할에 대한 논의였습니다. "컨트롤러는 단순해야 하며 흐름만 보여야 한다"는 리뷰를 받고, 비즈니스 로직과 도메인 로직을 분리하는 연습을 했습니다. 이를 통해 코드의 역할 분담이 명확해지고 유지보수가 쉬워졌습니다.

1. 혼자만 보는 코드가 아니라는 생각

매주 코드 리뷰가 이루어지기 때문에 개발을 하면서도 "나 혼자만 보는 코드가 아니다" 라는 생각을 수시로 가지게 되었습니다. "이렇게 구성해도 이해가 바로 될까?"" 라는 질문을 계속해서 던지며 수정을 반복했습니다. 이는 곧 가독성있는 코드 작성의 촉진제가 되었고 가독성에 대해 깊은 생각을 할 수 있는 기회가 되었습니다.

2. 사람마다 다른 코드 작성

리뷰를 하면서 사람마다 정말 다양한 코드가 될 수 있음을 알게되었습니다. 리뷰를 하면서 "이렇게도 할 수 있구나" 라는 생각을 여러번 한 것 같습니다. 덕분에 시야가 넓어질 수 있는 기회가 되었습니다.

3. 많은 양의 코드 리뷰

정말 많은 코드를 리뷰했던 것 같습니다. 어림잡아서 40개의 리뷰를 한 것 같습니다(리뷰 1개당 30분 정도 사용한 것 같습니다). 많은 리뷰를 하면서 코드 분석 능력이 향상된 것 같습니다.

4. 가독성이 낮은/높은 코드를 비교

리뷰를 하면서 직관적으로 코드가 이해되는 코드가 있는 반면, 구조부터 이해가 되지 않는 코드도 있었습니다. 저는 오히려 가독성이 낮은 코드를 더 면밀히 분석했고, 정확히 어떤 점이 가독성을 해치는지를 분석했습니다.

예를 들어서 다음과 같습니다. 컨트롤러는 단순해야 하며 흐름이 보여야 한다, 비즈니스로직과 도메인 로직이 명확하게 분리되어야 한다, 코드의 일관성이 있어야 한다, 메서드에 side effect가 없어야 한다 등 결국엔 근본을 살펴보면 clean code의 내용이 되지만, 직접 분석하면서 얻은 내용은 깊은 무의식을 자극시킬 수 있었습니다.

덕분에, 제 코드를 작성하면서도 가독성을 해칠 수 있는 부분에 대해 인지할 수 있었습니다. 가독성 있는 코드를 작성하는 방법에 집중하기 보다 가독성을 해칠 수 있는 방법에 대해 집중한 것 같습니다.

5. 말하면서도 모호한 개념들

리뷰를 하면서, "아 이거 ~게 하는게 좋겠는데?" 라는 생각이 들어서 피드백을 작성했습니다. 그러나 정확히 왜 그렇게 하는게 좋은지를 설명하려고하니 쉽게 떠오르지 않았습니다. 그래서 리뷰를 하면서 매번 머리속에 모호했던 개념들을 다시 학습하고 설명하는 것을 반복하다보니 더욱 확실하게 이해할 수 있었습니다.

4. Community

토론채널

저는 무엇보다 토론채널이 굉장히 만족스러웠습니다. 열정있는 사람들이 많아서 어떤 주제를 해도 모두 성실히 답변해주고 더 깊은 대화를 나눌 수 있었습니다. 덕분에 고민했던 내용들에 대해 사람들과 의견을 주고받으면서 많은 것들을 배울 수 있었습니다.

---

마무리하며

프리코스를 통해 순수 자바로 개발하며 많은 불편함과 어려움을 경험했지만, 이는 오히려 Spring과 같은 도구의 역할을 깊이 이해하는 계기가 되었습니다. 또한, Clean Code를 준수하려는 노력과 커뮤니티의 피드백을 통해 개발자로서 한 단계 성장했다고 느낍니다. 앞으로도 이러한 과정을 통해 성장하는 개발자가 되고 싶습니다😀