본 회고는 인프런 박우빈 지식공유자님의 Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의를 듣고 작성된 내용입니다.

총평

예상했던 것 보다 하루에 들어야하는 강의 분량이 많아서 힘들었다. 하지만 실무를 하면서 고민했던 부분들이 조금이나마 해결이 된 것에 보람을 느꼈다.

그리고 영어 공부를 할 필요성을 느꼈다. Readable하기 위해서 중요한 것은 네이밍이라고 생각한다. 아무리 열심히 추상화를 하고 결합도를 낮춰도 변수와 메서드 이름이 의도를 담지 못한다면 의미가 없는 것 이라고 생각한다.
이 생각을 한 이유는 강의를 보면서 지식 공유자님의 네이밍에 무릎을 탁 쳤기 때문이다. 나였다면 어떻게 했을까를 생각해보니 너무 초라했다.

KPT 회고

Keep

• 강의를 들으면서 나에게 필요했던, 내가 고민 했던 부분들을 위주로 정리해 나갔다.

• 코드를 따라가면서 나라면 어떻게 수정 했을 지 고민하고 비교해보았다.

Problem

• 미션을 위한 정도까지만 강의를 듣고 DAY 5의 분량을 수강하지 못하였다. 한번 미루니 분량이 걷잡을 수 없이 늘어나버렸다.

   

Try

• 강의를 미리 들어놔야겠다.

학습 내용 요약

읽기 좋은, 가독성이 좋은 코드를 짜야하는 이유는 무엇일까? 나는 코드를 읽을 때 생각없이 읽혀야한다고 생각한다. 문제 해결을 위해서 혹은 기능 수정을 위해서 기존 코드를 읽을 때 코드를 잘못 이해하게 된다면 잘 동작하던 부분에도 문제가 생길 수 있다. 그리고 우리의 개발 기간이 배로 늘어날 것이다. 어찌되었던 개발자는 회사의 제품을 잘 만들어서 그로 인해 회사에 수익을 가져다줘야하는 역할을 맡고 있기 때문이다. 개발 기간이 줄어들면 그만큼 투입되는 인건비가 줄어드는 것 일 테니까 말이다.

읽기 좋은 코드를 짜기 위해서는 아래 항목들에 신경을 써야한다.

1. 네이밍

2. 추상화

3. Depth 그리고 공백

    

   즉 비즈니스가 담고있는 내용을 쉽게 읽히게 해야한다.

객체 지향 코드가 무조건 가독성이 좋고 어느 상황에서든 적용되어야하는 패러다임은 아니다. 상황에 따라서 절차 지향 코드가 더 적절할 때도 있을테니까.

그렇지만 알고서 안쓰는거랑 모르고 안쓰는 것, 잘못알고 잘못 쓰는 것은 다르다. 강의에서는 객체 지향 패러다임에 대해서 여러 세션을 할당해서 설명하고 있다.

흔히들 객체지향에서 이야기하는 SOLID, 캡추상다 같은 특징들은 구글 검색만 해도 나오니까 넘어가도록 하겠다.

미션 회고

이번 주차의 미션은 실생활의 행동을 추상화, 코드를 리팩토링하고 SOLID를 정의하기 였다.

정의와 추상화는 어렵지 않았지만 코드 리팩토링은 약간의 고민이 필요했다.

이유는 유효성 검증을 ealry return할 때, Order의 사용자가 유효한지를 Order가 검사하는 것이 맞을까? 라는 고민을 했었다.
나의 결론은 Order도 User의 정보를 갖고있기 때문에 Order 레벨에서 User에 대한 검사정도는 필요하다고 판단했다. User가 null일 수도 있으니까 말이다.

다음 미션은 리팩토링해보기인데 정말 기대된다. 아자아자