코드 분량 줄이기
더스틴 보즈웰, 트레버 파우커
느낌표 ! (인상 깊은 문장 | 문맥)
그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다
새로운 프로젝트를 시작하면 공연히 흥분해서 뭔가 멋진 기능을 구현하려고 궁리한다. 하지만 프로그래머는 대개 프로젝트에 정말로 필요한 기능이 얼마나 있는지 과대평가하는 경향이 있다. 한편 프로그래머는 어떤 기능을 구현하는 데 필요한 노력을 과소평가하는 경향도 있다.
p.192
인용구는 완전히 나의 모습이다. 새로운 프로젝트를 시작하면 확장성을 엄청나게 고려해서 코드를 작성하는데 이게 독이 될 때가 매우 많았다. 확장성을 고려한 고민의 결과가 정답에 가까웠다면 문제가 안 되었을텐데 그 코드 또한 수정해야하니 추후 코드 수정에 대한 사이드 이펙트만 더욱 커졌기 때문이다. 물론 확장성을 고려한 결과물이 좋았던 경험도 있다. 몇 년 뒤에 생각은 달라질 수 있겠지만 현재로써는 일단 기능을 만들고 코드를 다듬는 것이 좋은 방법 같다. 이유는 여러가지를 들 수 있겠으나 그 중 가장 큰 것은 눈에 보이는 결과물이 있어야한다는 것이다. 눈에 보이는 결과물이 있어야 개발할 때 더욱 신나고 몰입할 수 있었다. 당연히 이것은 필자의 개인적인 경험이다. 그러므로 그저 경험이지 결코 정답이 아니다.
여하튼 조그마한 기능 개발 -> 눈에 보이는 아웃풋 -> 뿌듯함 & 성취감 -> 리펙토링 -> 조그마한 기능 개발 ->… 이 방법이 개인적으로는 좋은 것 같다. 조그만한 기능들을 잘 만들었을 때 결합해서 더 큰 범위의 기능을 만들 수 있다. 이럴 때 더 정확한 기능 구현이 된다. 처음부터 큰 그림을 그리면 추상적이기 때문에 현실과 다른 경우가 발생하기 때문이다. 물론 아예 큰 그림을 생각하지 않는 것도 문제이다.
자기 주변에 있는 라이브러리에 친숙해져라
라이브러리가 할 수 있는 일을 알고 활용하는 것은 대단히 중요하다. 다음은 실제로 도움을 주는 조언이다. 매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라.
…
라이브러리 전체를 암기하라는 게 아니다. 그냥 그 안에 무엇이 있는지 감을 잡아놓고, 나중에 새로운 코드를 작성할 때 “잠깐만, 이건 전에 API에서 보았던 것과 뭔가 비슷한데..” 라고 생각할 수 있기를 바라는 것이다.
p.196-197
필자는 인용구 연장선 상에서 비슷한 생각을 가지고 있다. 그것은 책 끝까지 읽기이다. 끝까지 읽었을 때 고차원?!적인 정보가 나올 확률이 높기 때문이다.
초반에는 이해가 되지 않아 도움이 안 되는 것 같아 덮고 싶은 마음이 들지만 그럼에도 끝까지 읽으면 이걸 왜 쓰는지 감은 온다. 또한 지금 나에게 필요한 정보를 소개하기도 한다.
이런 경험들을 하다보니 억지로라도 책을 끝까지 읽으려한다. 또한 특정 오픈소스를 사용할 때 인터페이스는 보는 습관이 있다.
요즘은 typescript 를 많이 사용하다보니 인자 type, 리턴 type 과 설명과 예제도 잘 되어있기 때문에 언제나 도움이 된다.
인용구에서 저자가 언급했듯 인터페이스를 보다보면 필요한 기능이 이미 구현되어있기도 하다.
예를 들어 이미지 슬라이딩을 구현하려고 우선 생각을 하니 FlatList 에서 사용자 Gesture 를 가지고 현재 x 좌표를 계산하는 코드가 필요하겠다고 생각했다.
그렇지만 FlatList 인터페이스를 보니 pagingEnabled 가 있었고 pagingEnabled={true} 를 사용하니 그냥 구현이 끝났다.
이를 몰랐으면 아마.. 꽤 고생을 했거나 외부 라이브러리를 사용했을 것이다.
가급적이면 적은 분량의 코드로 작성하는 방법을 배웠다. 새로 작성하는 코드를 모두 테스트하고, 문서화하고, 유지보수해야 한다. 더욱이 코드베이스에 더 많은 코드가 있으면 더 ‘무거워’져서 새로운 개발이 더 어렵게 된다.
p.196
Chapter 13 느낌
Chapter 13 에서는 코드를 최대한 분량을 줄이는 것이 좋은 테크닉이라고 말하고 있다. 즉 불필요한 코드를 줄이라는 것이다.