회고록

2주차로 넘어가면서 벌써 한 강의가 끝났다. 개발을 업으로 하면서 항상 깔끔한 코드에 대한 갈증 있는데 이번에 완료한 강의로 그 갈증을 모두 채우기에는 역시나 아쉬움이 있었다. 이것은 아마도 강의의 문제가 아닌 클린코드 라는 작업 자체에 대한 어려움일 것이다. 그리고 나 자신의 작문 실력의 부족함 때문일것이다.

1. 무엇을 배웠나?

이번 주에는 다음과 같은 내용을 학습했다.

섹션 5 객체 지향 적용하기

상속과 조합 : 상속보다는 조합을 사용하여 유연한 구조를 설계하는 것이 좋다.
- 내 경험에선 상속을 사용한 클래스를 보기 힘들었다. (사실 본적이 없다.) 아마도 숨겨진 변수에 찾기에 대한 어려움 때문일것이라 생각한다.
Value Object (VO) :
도메인 개념을 값으로 표현하는 객체로, 불변성과 동등성을 보장해야 한다.
- 개인적으로는 VO객체를 많이 사용하려고 노력한다. 값이 스스로 검증 할 수 있다는 것이 매력적이기 때문일까?
- DTO 내부에 들어가게 될 경우 어떻게 써야할지 좀 막막하기는 하다. 해당 내용도 있었으면 좋았을텐데
일급 컬렉션 :
컬렉션을 객체로 감싸서 의미를 부여하고, 가공 로직을 포함할 수 있도록 한다.
- 잘 사용하지 않는 패턴이긴하다. 이건 새로 도입할지 여부를 결정해봐도 좋을것 같다.
Enum의 특성과 활용 :
상수의 집합이며, 관련된 로직을 포함할 수 있는 추상화된 객체로 활용된다.
- 개인적으로 Enum을 사랑하는 사람이다. 한글로 명확히 표현 할 수 있는건 매력적이다.
- interface를 적용하는 방법은 적절히 사용하면 좋은 패턴인것 같다.
다형성 활용하기 :
반복적인 if 문을 제거하고, 변화하는 부분을 분리하여 OCP(Open-Closed Principle)를 지킨다.
- 사실 코드 depth를 줄이기 위해 자주 애용하는 패턴이다.
숨겨져 있는 도메인 개념 도출하기 :
도메인 개념을 발견하여 설계에 반영하고, 완벽한 설계가 아닌 최선의 설계를 지향해야 한다.
- 자세한 내용은 아래에서

섹션 6 코드 다듬기

주석의 양면성 :
주석은 코드의 가독성을 높일 수도 있지만, 코드 품질이 낮다는 신호가 될 수도 있으며, 꼭 필요한 경우에만 작성해야 한다.
- 자세한 내용은 아래에서
변수와 메서드의 나열 순서 :
변수와 메서드는 사용 순서대로 배치하며, 공개 메서드를 상단에 배치해 객체의 협력을 더 쉽게 이해할 수 있도록 해야 한다.
- 사실 배열 순서가 꽤나 개발자 취향을 타는 문제라 내 배열 순서랑 한번 비교해 보는 시간이라 좋았다. (나는 목록,상세,생성,수정,삭제, 기능으로 자주 호출되는 순서로 정리한다.)
패키지 나누기 :
패키지는 문맥을 제공하므로 적절한 크기로 분리하되, 과도한 세분화나 무분별한 변경은 피해야 한다.
- 패키지 나누기는 어려운 문제다. 대부분은 사내 컨벤션이 있기때문에 마음대로 조정하기 어렵다.
기능 유지보수하기 (1) - 버그 잡기 :
기존 기능의 오류를 찾아 수정할 때는 코드의 변경이 최소화되도록 해야 한다.
기능 유지보수하기 (2) - 알고리즘 교체하기 :
알고리즘을 변경할 때는 성능과 메모리 사용을 고려하여 적절한 방법을 선택해야 한다.
- 사실 리펙토링의 핵심은 이런 부분 때문이 아닐까 싶다. 리팩토링 잘된 코드는 추가 요구사항을 적용할때 때로는 코드 한줄 만으로 처리 가능하게 한다. 개발자라면 그럴때 느끼는 감정은 따로 말하지 않아도 잘 알지 않을까 싶다.(물론 항상 그렇지는 않다.)
IDE의 도움 받기 :
코드 정렬, linting, 스타일 가이드를 활용하여 가독성과 유지보수성을 높인다.
- 개인적으로 코드 스타일 같은 경우는 툴에 의존되야 되는것이 맞다고 생각한다. (
  코드 컨벤션은 사람이 지키기에는 정말 어렵다.)
섹션 7 리팩토링 연습
리팩토링 (1) - 추상화 레벨 :
중복 코드를 제거하고, 메서드를 추출하여 적절한 추상화 레벨을 맞춘다.
리팩토링 (2) - 객체의 책임과 응집도 :
IO 처리와 화면 출력(display) 기능을 분리하고, 일급 컬렉션과 Order 객체를 도입하여 책임을 명확히 한다.
리팩토링 (3) - 관점의 차이로 달라지는 추상화 :
같은 기능이라도 구현 중심과 도메인 개념 중심으로 접근하는 방식에 따라 추상화가 달라질 수 있다.
- 강의를 따라하면서 의문이 들었던 부분은 MVC, MVVC 와 같은 아키텍처 부분이 나올줄 알았는데 안나왔다는 것이다. 강의 분량 때문에 안 나온건지 아니면 일부러 포함을 안 시킨 건지 잘 모르겠지만 중간에 "Controller"라는 표현을 한것 을 보면 후자에 가까운 것으로 보인다.

섹션 8 기억하면 좋은 조언들

능동적 읽기 : 핵심 목표는 도메인 지식을 늘리는 것
- 이게 정답이다. 중요한 건 도메인이지 기술이 아니다.
오버 엔지니어링 : 적정 수준보다 더 높은 수준의 엔지니어링
- 자세한 내용은 아래에서
은탄환은 없다 : 클린 코드도 은탄환이 아니다.
- 자세한 내용은 아래에서

2. 무엇이 인상적이었나?

이번 주 학습 중 가장 인상 깊었던 내용은 숨겨져 있는 도메인 개념 도출하기, 주석의 양면성, 오버엔지니어링, 은탄환은 없다. 이었다.

숨겨져 있는 도메인 개념 도출하기
- 업무를 하면서 도메인의 관점에서 생각을 해보지 않아서 새로웠다.
주석의 양면성
- 주석이 참 업무를 하다보면 매력적으로 다가올때가 많다. 하지만 레거시에서는 그렇게 보기 싫더라... 히스토리 용으로만 쓰면 좋다는 내용은 동의하지만 고객에게 전달할때 어떻게 코드만으로 전달 수있을지는 여전히 잘 모르겠다.
오버엔지니어링
- 사실 개발하면서 신규 요구사항을 한방에 해결하기 위해 오버엔지니어링을 많이 하게되는것 같다. "필요하기전에 만들지 마라"라는 말이 있듯이 참 지키기 어려운 부분인것 같다.
은탄환은 없다.
- "머리는 애자일, 몸은 워터풀" 인 상황이 많았다. 사실 강의에서는 "지속 가능한 소프트웨어의 품질 VS. 기술 부채를 안고 가는 빠른 결과물" 이지만 클라이언트의 요구사항은 거의 대부분 "지속 가능한 소프트웨어의 품질을 가진 빠른 결과물" 인 경우가 많다. 그래서 아마 대부분의 개발자가 품질을 높이기 위해 작업 공수를 실 공수보다 높게 부르는 것이라 생각한다. 이게 보통 성과에 직결되는 부분이라 참 어렵다.

3. 이번 주 학습을 통해 얻은 것

이번 주 학습을 통해 나는 Enum 활용법에 대해 배웠고 도메인에 대한 생각을 더 깊게 해야겠다고 생각했다.
특히, 도메인에 대한 생각을 깊게 하는 연습을 게을리 하면 안될것이라 생각한다.

4. 다음 주 목표

다음 주에는 테스트 코드 방법론 적용을 달성하고 싶다.
항상 로직을 먼저 작업하고 테스트 코드를 작성하는 버릇이 있는데 차주에는 그런 버릇을 의식적으로 수정해 보리라..

워밍업 클럽 3기 BE 클린코드&테스트 - 2주차 발자국

회고록