해당 회고는 'Readable Code : 읽기 좋은 코드를 작성하는 사고법' 강의에 대한 회고입니다.

시작

팀프로젝트를 진행하면서 완성도 있는 코드를 짜고 싶다는 생각과 함께 여기저기서 들었던 코드 잘 짜는 방법에 대한 정리가 필요했습니다. 이런 모호한 생각들을 정리해보았고 결론적으로 이 강의를 듣게 되었습니다.

제가 이 강의를 찾은 이유는 다음 3가지 이유에서였는데요,

• 지금까지 프로젝트를 진행하면서 기능구현을 위한 개발은 했지만 같이 개발하는 팀원들을 위한 개발은 하지 못한 것 같다

• 팀원들과 코드 컨벤션을 정하면서 서로 알고 있는 리소스 자체가 적어 방향성을 잡기 힘들었다

• 팀원들에게서 괜찮았던 구현방식을 배우면서 나도 나만의 좋은 코드짜는법을 익혀 주변 사람들에게 공유하고 싶은 마음

읽기 좋은 코드라는 의미를 작은 수준에서부터 자연스럽게 확장시켜가는 강의라고 느껴져 작은 부분에서부터 빠른 적용을 하고 싶은 저에게 좋은 선택이었다고 생각합니다.

배운 것들

1주차에서 학습한 것은 추상에 관한 것들과 코드를 읽을 때의 생각을 배우고 이들을 기반한 객체 지향을 학습했습니다.

읽기 좋은 코드를 쓰기에 앞서 시작을 추상으로 한 것이 좋았습니다. 구체적인 코드 작성법을 배우기 전 모든 것의 기반은 적절한 추상화라는 것을 느꼈습니다.

다음은 코드를 읽을 때 어떤 사고가 이루어지는지와 이를 기반한 코드적 습관(?)을 배웠습니다. 뭔가 코드를 짤 때하는 행동들에 생명력을 주는 듯한 느낌이었습니다.

배운 것은 다음과 같습니다.

추상

추상은 중요한 정보를 가려내고 덜 중요한 정보는 버리는 것

반대로 추상에서 구체적인 것을 유연하게 찾을 수 있어야 한다!

다음과 같은 이유로 추상에서 구체로 돌아가지 못할 수 있다..

1. 추상화 과정에서 중요한 정보를 부각시키지 못함

2. 해석자가 동일하게 공유하는 컨텍스트가 없음

잘못된 추상화는 후폭풍이 매우 심하기 때문에 잘 고려해서 해야 한다.

이름 짓기

이름 짓기는 추상화의 대표적인 예라고 할 수 있다.

중요한 점은 표현하고자 하는 구체에서 중요한 개념만 추출해서 드러내고 우리 도메인 컨텍스트 안에서 이해되어야 한다는 것이다.

다음과 같은 tip이 있다.

• 단수와 복수를 비교하기

  • 만약 리스트나 컬렉션 타입이라면 복수형태로 표현해서 이해를 도울 수 있다

• 이름 줄이지 않기

  • 줄임말은 얻는 것보다 잃는 것이 많다(가독성 > 효율성?)

  • 관용어처럼 사용되는 것 제외 (col, lat, lon, cnt는 비추천)

  • 줄임말이 이해되는 것은 컨텍스트 때문인 것을 늘 상기

• 은어/방언 사용하지 않기

  • 농담, 일부 팀원만 아는 용어 금지

  • 도메인 용어 사용하기 (도메인 용어 사전을 먼저 구축해야 할 수도, 방대하거나 필요하다면)

• 좋은 코드를 보고 습득하기

  • 비슷한 상황에서 자주 사용되는 단어나 개념 습득하기

  • pool(한정된 자원을 가지는 것), candidate(후보), threshold(문지방, 한계점, 임계값) 등

메서드 추상화

잘 짜여진 메서드는 메서드 안에 주제(하는 일)가 하나만 존재한다.

메서드명을 생각해보면 메서드명은 내부의 구체적인 동작을 유추할 수 있어야 한다. 반대로 생각해보면 하나의 메서드명이 나오기 힘든 로직을 가진다면 2개 이상의 동작이 있을 확률이 크다.

메서드명, 파라미터, 반환타입은 추상화된 구체를 쉽게 유추할 수 있거나 실행할 때 필요한 변수들을 쉽게 캐치할 수 있도록 하는 것이 좋다. 반환 타입은 필요한 의미를 충분히 가지도록 하고 void 대신 반환할만 한 값이 있는지 고민해보자.

추상화 레벨

메서드 안과 밖은 서로 추상화 레벨이 다르다.

밖은 상대적으로 추상화 레벨이 높고 안은 낮다고 할 수 있다. 메서드 안팎은 서로 파라미터와 반환타입으로 교류한다.

하나의 메서드 안에서 추상화 레벨을 맞춰주기 위해 구체적인 레벨의 것이 있는지 확인하고 있다면 메서드화하는 등의 방법으로 바꿔주면 좋다.

매직 넘버, 매직 스트링

상수로 추출하는 것은 이름을 주어 추상화하는 것이라고 볼 수 있다.

특정한 의미를 가지는 (보드의 가로, 세로 길이 등) 숫자나 문자열같은 경우에 상수로 추출해준다면 가독성과 유지보수성이 올라간다.

또한 중요한 숫자나 문자를 강조하면서 읽는 사람이 더 주의깊게 볼 수 있도록 해준다.

사고의 depth 줄이기

사고 과정의 depth를 줄이기 위한 메서드 추출을 고려하자.

사용할 변수는 가깝게 선언하는 것이 좋다.

공백 라인, 부정어, 예외처리

의미 단위로 적절하게 공백 라인을 사용하는 것이 좋다.

연산자로 부정하기 보다는 메서드명으로 구성하는 것이 더 나을지 고민하자.

해피 케이스 외의 예외들이 생길 부분을 고려하고 의도한 예외(사용자에게 보여줄 예외)와 그렇지 않은 예외(개발자가 보고 처리해야 할 예외)를 구분하자.

Null

null반환은 웬만하면 하지 않는다. Optional도 처리할 분기가 3개나 되기 때문에 꼭 필요한지 생각해본다.

stream API를 적용하자. orElse(), orElseGet(), orElseThrow()의 차이를 알고 적절하게 사용하자.

마무리 회고

어렴풋이 아는 것들을 확실하게 체득할 수 있었던 한 주였습니다.

새롭게 기록되는 학습들을 보니까 기분이 좋습니다. 이번주에는 불규칙하게 들었지만 다음주에는 정해진 시간에 정해진 양만큼 들어야겠습니다. 다음주도 화이팅!