[인프런 워밍업 스터디 클럽 2기_BE] 2주차 회고록 정리

주석은 죄악이다? vs 주석은 필요하다

주석이 많다는 것은 요구사항을 코드에 잘못 녹여냈다는 이야기..!! 좋지 않다.

코드를 설명하는 주석을 쓰면 코드가 아니라 주석에 의존한다.

주석에 의존하여 코드를 작성하면 적절하지 않은 추상화 레벨을 갖게 되어 낮은 품질의 코드가 만들어진다.

근데 주석은 언제쓰나요?

좋은 주석

✅ 우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석

리팩토링을할때, 조상님들이 남긴 히스토리에 대해 알수없을때 코드를 작성할때 의사소통이나 코드로 표현할수 없을때 주석을 상세하게 설명
A안과 B안을 통해 ~~~ 테스트를 결정된 사항에 대해 문서는 이런식으로 작성한다.
주석을 작성할 때, 자주 변하는 정보는 최대한 지양해서 작성
만약 관련 정책이 변경되었다면, 주석도 잊지 않고 함께 넣는다.

1 , -1 , 0 이런거는 매직넘버로 생각할수있다. 그래서 Enum으로 가독성을 올려 추상화 레벨도 맞출수있는 효과가 있다!

 gameStatus == GameStatus.IN_PROGRESS;

강의중에 이런 내용도 추상화 레벨을 맞추기위해 메서드로 뺀것보고 정말 추상화레벨 이해가 정말 중요한거같다.

checkIfGameIsOver();

Open을하고 종료 체크를 하는것이 추상화 레벨이 동일하다 판단해서

Enum을 받아서 처리하면 좀 더 직관적으로 사용하기 좋다

다양한 기법을 활용하면 새로운 도메인 지식을 얻을 수 있고 더 많은 생각을 할수있다.

변수와 메서드의 나열순서

변수는 사용하는 순서대로 나열한다.
메서드의 순서도 고려해야하는데 객체의 입장을 항상 들어보자

run이라는 메서드의 출현한 순서대로 배치

actOnCell이라는 메서드의 순서에 대해 배치

공개 메서드는 상단에 배치하는 것을 선호

또 나눈 공개 메서드의 기준

상태 변경 >> 판별 메서드 ≥ 조회 메서드 순서로 하는게 좋다.

비공개 메서드는

공개 메서드의 출현한 순서대로

public 1

private 1

private 2

이런식으로 배치하면 좋을꺼같다.

나열 순서로도 의도와 정보를 전달할 수 있다는 것.

메서드와 변수를 만들때 어디다 배치하지?

이게 공개 메서드에서 내부 메서드로 의심을 해본다.

변경 메서드여도 private면 우선순위가 낮아진다.

내부에서 돌면 private로 바꿔준다.

패키지 나누기

패키지는 문맥으로써 정보를 제공할 수 있다.

패키지는 쪼개지 않으면 관리가 어렵다.

반대로 너무 잘개 쪼개면 관리가 어렵다.

대규모 패키지 변경은 팀원과의 합의를 이룬시점에 하자.

commit이 끝난후 작업을 하던 해야지 아니면 머지할때 고생한다..

문과적으로 생각해서 보드는 셀과 포지션의 부모와 같은 상위 개념이라 옮겨도 된다.

인터페이스와 구현부랑 나눠서 패키지구조를 잡는방법을 진행했다.

기능 유지보수하기

1. 버그잡기

기능을 추가하거나 수정할때 좋은 방법

깃발을 다꽂으면 게임이 승리조건으로 끝난다. → 버그케이스

왜 이렇게 될까?

로직적으로 코드가 문제가 되는곳이 있었으며, 이를 개선하기 위해 코드한줄한줄을 읽고 문제점을 파악하여 변경해나갔다. 코드를 읽으며 코드의 흐름 즉 추상화레벨을 잘 파악하는 것이 버그를 잡는 포인트다.

2. 추상화 레벨을 맞추기

생각해낸 방법

추상화 레벨을 맞추기 위해서 한줄 한줄 코드를 읽고 분류를 진행한다.

중복으로 뽑아낼수 있는 부분을 뽑아낸다.
이미 타입을 선택했기때문에 타입으로 필터링으로 추출해도된다.

중복된 로직에 대한 범위를 잡기

부가적인 요소에 대한 내용을 메서드로 추출하기

같은 메서드 동작임을 판단해서 생각하는것도 필요하다.

null 객체 반환은 좋지 않아 Optional로 관리를 진행할 예정이다.

파라미터에 Optional을 받으면 좋지 않은 안티패턴이다.

한단위가 끝날때 , 조각조각 나눠서 커밋을 하는게 중요하다.

객체의 책임과 응집도

IO 통합
일급 컬렉션
display()의 책임
Order 객체

IO의 통합

IO를 통합하여 같은 일련의 과정으로 묶여서 통합 객체를 만들어서 사용자의 객체하나로 한다. 왜 근데 그렇게 할까?

일급 컬렉션

일급 컬렉션을 활용하면 장점이 컬렉션의 가공이 일급 컬렉션에서 사용된다. 추상화되어

일급 컬렉션을 활용하면 테스트 코드도 짜기 편하다. 매우

null을 반환하는건 좋지 않다. 그러니까 Optional을 활용하여 null 객체를 처리를 꼭하자.

display의 책임

코드를 옮기고 둘이 동일한 로직을 타는것을 알수있다. 다른것은 파라미터뿐!
이용권에 대한 인터페이스를 만들어서 관리하면 어떨까?
필드가 공통적이라면 인터페이스를 만들어서 관리하는게 훨씬 좋다 상속은 별로다!!
인터페이스를 만든다.
해당 인터페이스를 가져온다.

출력을 담당하는로직에서 이용권 계산은 도메인과 맞지 않고 올바르지 않다. 그렇기 때문에 분리하자.

관점의 차이로 달라지는 추상화

FineHandler를 바라보는 관점

파일을 읽어오는 모든 행위에 대해서 가져오기때문에 무거워지기때문이다.

구글시트나 다른 내용에 대해 유연성이 떨어진다. 그렇기 때문에 인터페이스에 대한 응집도가 올바르지 않다.

제공을 해주는 접근, 읽는 접근으로해서

io와 provider를 분리하는 이유는? 되게 중요하다.

읽는다는 개념은 구현의 추상화 레벨이 낮고 , 제공해주는 개념이기때문에 따로 패키지에 스펙을 둔것이다.

→ 헥사고날 아키텍처 - 포트와 어댑터의 기본이 되는 개념

Provider과 다양한 역할을 보면서 클래스 작성에도 큰 책임 따른다 생각을 했다.

능동적 읽기

복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링하면서 읽기
- 공백으로 단락 구분
- 메서드와 객체로 추상화
- 주석으로 이해한 내용 표기하며 읽기
우리에게는 언제든 돌아갈 수 있는 git reset —hard 가있다.
핵심 목표는 우리의 도메인 지식을 늘리는 것. 그리고 이전 작성자의 의도를 파악하는것

오버 엔지니어링

필요한 적정 수준보다 더 높은 수준의 엔지니어링

가능성이 낮아보이는 요구사항에 대해 리소스를 투자하는 행위

은탄환은 없다.

클린 코드도 은탄환이 아니다.

실무 : 2가지 사이의 줄다리기

지속 가능한 소프트웨어의 품질 vs 기술 부채를 안고 가는 빠른 결과물
클린 코드를 추구하지만 코드 센스가 아주 중요하다. 클린 코드의 사고법을 기반으로 결정

회사에서 많은 기법을 넣으려고 노력을 많이했지만 해당 강의를 들으니 많은 반성을 하게되었다. 꼭 좋은 기술 스택이여도 오히려 나에게 독이 될수 있다는 것을 느꼈다. 기술 스택을 넓히기보단 왜? 라는 중점을 두고 깊게 파고드는 개발 방향성을 잡아야겠다.

2주차에 있는 day7의 과제중 객체지향적으로 코드를 설계하고 구현을 하는 내용이 있었다. 회사에서 어느정도 리팩토링을 진행해봤고 자신도 있었지만 코드를보니 머리가 하얘졌다. 첫번째로 실수한건 요구사항을 읽지않고 코드만 읽어 도메인 개념을 이해하고 개발을 진행하려했던것 코드한줄한줄을 분리하기 어려웠던 것 다양한것도 있었지만 요구사항을 파악하지 못했던 점이 가장 큰 페인이 되었던거같다. 요구사항을 재대로 보았으면 오래걸리지않고 코드를 더 빨리 구조화했을텐데 그러지못해서 많이 아쉬웠다. 다음번에는 요구사항에 대해 꼼꼼히 찾아봐야겠다

또한 이번 중간평가에서 피드백을 받고 너무 많은 오버엔지니어링을 했다는 점에 반성을 했고 다른 사람들의 피드백을보며 나도 더 열심히해야겠다는 생각이 들었다 나보다 개발을 잘하는 사람은 널렸다. 겸손해야겠다.

다음 강의에 대해 테스트 코드를 배우는 시간인데 너무 설렌다. 적용을 하고싶어도 구체적인 범위에 대해 어려움이 많았는데, 이번 강의에 대해 크게 얻어가는게 있었으면 좋겠다