해당 회고는 박우빈님의 'Readable Code : 읽기 좋은 코드를 작성하는 사고법' 강의를 참조하여 작성했습니다.

2주차 회고인데 까먹고 이제야 씁니다 . . . 남은 기간에는 좀 더 열심히 참여해서 많이 얻어 가겠습니다!

기억하면 좋은 조언들

• 능동적 읽기

학습 내용을 빠르게 체득할 수 있는 방법은 직접 적용해 보는 것이다. 실습을 통해 이론으로 얻은 지식만의 부족함을 채울 수 있으며 결과를 직접 확인 가능하여 크게 와닿는다. 이처럼 클린 코드에 대한 견문과 견해도 직접 적용해 봐야 시야를 기를 수 있다.

1. 모든 것을 한 번에 보기는 어려우니 직접 하나하나 리팩토링 하면서 이해하기

2. 리팩토링을 통해 도메인 지식을 늘리고 작성자의 의도를 파악하도록 노력하기

리팩토링을 무서워할 필요가 없다. git reset을 통해 언제든지 복구 가능하니 잘못된 코드를 작성하더라도 괜찮다. 결국 직접 시도해야지만 성장할 수 있다.

• 오버 엔지니어링

모든 것에는 오버 엔지니어링이 생길 수 있다. 보여준 예시처럼 체스 게임을 구현했을 때, 너무 매달리지 않아도 된다. 체스란 게임은 몇 백년 간 변하지 않았다. 체스란 게임만 봤을 때, 끝없는 리팩토링과 효율성을 고려하는 것이 옳을까?

보통 서비스는 발전하기에 우리는 추후 수월한 유지보수를 하기 위해 클린 코드를 고려해야 한다. 만약 단발성이나 지속 가능성이 없다면 적절한 타협점을 찾으면 된다.

1. 구현체가 하나인 인터페이스

   1. 인터페이스 형태가 아키텍처 이해에 도움을 주거나, 근시일 내에 구현체가 추가될 가능성이 높다면 인터페이스를 적용할 의미가 있다.

   2. 하지만 구현체를 수정할 때마다 인터페이스도 수정해야 한다.

   3. 인터페이스이므로 코드 탐색에 영향을 주고 필요 이상으로 애플리케이션이 비대해질 수 있다.

2. 너무 이른 추상화

   1. 정보가 숨겨지기 때문에 복잡도가 높아진다.

   2. 후대 개발자들이 선대의 의도를 파악하기 어렵다.

이처럼 클린 코드는 절대적인 법칙이 아니다. 우리는 필요에 의해 적용해야 한다. 이러한 견문은 경험에 따라 달라지니 부족하다면 열심히 적용해보자.

• 은탄환은 없다

   

클린 코드는 은탄환이 아니다. 실무 상황에서는 금전적 이익이 필수적이다. 그렇기에 고민에 빠진다.

1. 지속 가능한 소프트웨어 품질 VS 기술 부채를 안고 가는 빠른 결과물

2. 대부분의 회사는 돈을 벌고 성장해야 하고, 시장에서 빠르게 살아남는 것이 목표이다.

3. 이런 경우에도, 클린 코드를 추구하지 말라는 것이 아니라, 미래 시점에 잘 고치도록 할 수 있는 코드 센스가 필요하다. 결국은 클린 코드의 사고법을 기반으로 결정된다.

이처럼 우리는 적정선을 찾을 수 있는 능력이 필요하다. 급하게 만들어 품질이 낮은 결과물에 대해서는 주석을 통해 추후 개선사항을 남기듯 상황에 맞는 합의점을 찾아야 한다.

하지만 이는 클린 코드에 대한 이해와 경험이 충분해야 찾기 쉽다. 적정 수준을 알기 위해 극단적으로 사용해보는 것이 도움이 될 것이다.

예시로 망치만 쓰는 초보 목수는 모든 작업에 망치만 사용할 것이다. 망치밖에 쓸 줄 모르기 때문이다.

망치와 톱을 다룰 줄 아는 숙력자 목수는 상황에 적절한 도구를 사용할 것이다. 나무를 자르는데 당연히 톱을 사용한다. 클린 코드도 마찬가지이다.

상황에 대한 판단이 가능한 숙력자가 되기 위해 극단적으로 숙력될 때까지 사용하자.

개선할 점

실제로 리팩토링한 것과 강사님이 리팩토링한 부분과 차이를 보면서 보는 관점이 다르다는 것을 체감할 수 있었습니다. 제가 리팩토링하면서 익숙치 않아 옳은 리팩토링인가에 대한 의문은 있었습니다. 그래도 리팩토링에 대한 이유를 계속 생각하면서 하니 비교했을 때, 다시 개선해야 할 부분에 대해 인지할 수 있어 좋았습니다.

다른 말로는 오늘 리팩토링한 것을 내일 보라는 얘기를 해주셨는데 확실히 다음날 보니 생각치 못했던 부분에 대한 새로운 시야가 보여 마음에 와닿았습니다.

많이 부족하지만 계속 연습해서 저만의 견해가 담긴 클린 코드를 작성할 수 있도록 노력하겠습니다.