[TIL] 2023-1123

Facts

- 기록을 멈춘지 또 한달이 금세 지나버렸다.

- api 연동 및 에러핸들링 로직 작성중.

- five lines of code 스터디 시작.

 

Feelings

- 성장의 동력을 잃은 느낌... 나는 왜 일을하고 공부를 하고 발전해야 하는가... 인스턴스 즐거움 >> 깊이를 요하는 즐거움이 되어버린 요즘.

- 하지만 성장의 즐거움과 기쁨을 이미 조금이나마 맛보았으므로, 다시 잃기 전에 빨리 돌아와야겠다. ~.~

 

Findings

 

[Five lines of code]

- 회사에서 기존 코드 리팩터링할 일이 많은데, 효과적으로 하고자 구매하게 됨.

 

- 리팩터링에 있어서.. 메서드를 추출하는 까닭은 긴 코드 << 짧은 코드이고, 역할과 책임의 범위를 분명하게 해 가독성을 개선하기 위함. 그런데 그렇다고 너무 깔끔하고 세련된 코드를 작성하면... 그 코드의 정상 동작이 보장되지 않을 수도 있다. 실제로 각종 조건문 등... 깔끔하게 개선한다고 건드렸다가 피를 본 적이 있어서 격하게 공감이 되었다.

- 따라서 그저 코드를 그룹화하고 옮기기만 할 뿐인.. 조금 더러운 형태로 메서드가 추출되어도 안정성이 보장된다는 측면에서 더 가치가 있다.

 

- 함수 내에서 객체는 메서드를 호출하거나, 전달하거나 둘 중 하나만 해야한다. 이는 함수 책임의 범위를 좁히고, 추상화 수준을 고르게 해서 가독성을 높이기 위함임. 메서드에 접근해서 호출하는게 어떻게보면 지나치게 직접적인 일이기도 하기 때문... 

- 한 가지 함수가 하나의 역할만 해야한다는 것은 클린 코드의 기본인데, 하나의 역할이라는 범위가 어디까지냐-의 기준으로 볼 수도 있을듯. 

- 근데 이런식으로 함수를 쪼개고 추상화의 단계가 깊어지면... 복잡한 메서드는 마치 마트료시카처럼 느껴질 것 같기도 하다.

 

Feedback

- 코드 짜기 전에 만들거에 대한 수도 코드 작성하고 작업하기..~~~