[SQL 리팩터링을 공부하고 있습니다] - 데 | 커리어리

[SQL 리팩터링을 공부하고 있습니다] - 데이터분석을 하며 가장 많이 하는 일 중 하나가 SQL을 활용해 데이터를 추출하고 대쉬보드를 만드는 일인데요. - 저도 처음에는 일단 데이터를 원하는 대로 뽑아내는 것에 집중하다가, 이제 충분히 능숙해지고 나니 리팩터링과 성능 최적화에 관심을 갖게 되었습니다. - 그래서 도움을 얻고자 프로그래머에게 리팩터링의 교본이라 불리는 마틴 파울러의 '리팩터링 2판'을 읽고 있는데요. (아래에 인상적인 부분 정리) - 굳이 개발도서를 읽는 이유는: 1. 사실 이미 가지고 있어서가 가장 크고, 2. 리팩터링을 가장 본격으로 고민하는 주체는 개발자라고 생각했으며, 3. 따라서 교본이라 불리는 책을 읽으면 가장 기본적인 / 중요한 것이 무엇인지'알 수 있을 거라 생각했습니다. 4. SQL과 직접 관련된 책을 잘 모른다는 것도 한 몫... - 참고로 저는 개발을 위한 언어를 각잡고 공부한 것은 아니라서 코드 보다 개념 + 필요한 부분 위주로, 알고 있는 것과 대입해가며 읽는데요. 그것이, 꽤 도움이 됩니다! - 한편 백엔드 개발지식이 있으면 좋겠다는 생각이 들면서도, 무엇을 어디까지 알아야 하는 건지 고민입니다. 예를들어 Hiveql을 쓴다고 했을 때, 쿼리의 처리 과정을 알면 추출할 때 크게 도움이 될 것 같은데 그렇다고 하둡 자체를 공부하기에는 방향 잡기가 어렵네요. 👉 그래서 최근 추가된 고민, "데이터분석가는 DB에 관한 엔지니어링 지식을 얼마나 가지고 있어야 할까요?" --- 📚 리팩터링 2판 / 마틴 파울러 ◾ 리팩터링 정의 79p - [명사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 ◾ 리팩터링 & 성능최적화 80p - 둘 다 코드를 변경하지만 프로그램의 전반적인 기능은 유지한다. 단지 목적이 다를 뿐이다. - 리팩터링은 코드를 이해하고 수정하기 쉽게 만드는 것으로, 성능이 좋아질 수도 나빠질 수도 있다. - 반면 성능 최적화는 오로지 속도 개선에만 신경 쓴다. 그래서 목표 성능에 반드시 도달해야 한다면 코드가 다루기 어렵게 바뀔 수 있다. ◾ 리팩터링의 필요성에 관해서 27p - 잘 작동하고 나중에 변경할 일이 절대 없다면 놔둬도 아무런 문제가 없다. 다듬으면 좋지만, 누군가 읽지 않는 한 아무런 피해가 없다. "하지만 그러다 다른 사람이 읽고 이해해야 할 일이 생겼는데 로직을 파악하기 어렵다면 뭔가 대책을 마련해야 한다." ◾ 변수명의 중요성에 관해서 35p - 컴퓨터가 이해하는 코드는 바보도 작성할 수 있다. 사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다. 좋은 코드라면 하는 일이 명확히 드러나야하며, 이때 변수 이름은 커다란 역할을 한다. 44p - 이름이 좋으면 본문을 읽지 않고도 무슨 일을 하는지 알 수 있다. 처음에는 당장 떠오르는 최선의 이름을 사용하다가, 나중에 더 좋은 이름이 떠오를 때 바꾸는 식이 좋다. ◾ 성능 개선 전에 일단 리팩터링 47p - '특별한 경우가 아니라면 일단 무시하라'. 리팩터링 때문에 성능이 떨어진다면, 하던 걸 마무리하고 나서 성능을 개선하자. ◾ 간결함 보다 명료함 63p - 처음보다 (코드가) 부쩍 늘어날 수 있다. 그러나 추가된 코드 덕분에 전체 로직을 구성하는 요소 각각이 더 뚜렷이 부각되고, (계산하는 부분과 출력 형식 부분의 분리와 같이) 모듈화하면 각 부분이 하는 일과 그 부분들이 맞물려 돌아가는 과정을 파악하기 쉬워진다. - 간결함이 지혜의 정수일지 몰라도, 프로그래밍에서만큼은 명료함이 진화할 수 있는 소프트웨어의 정수다. 읽으면서 계속 내용을 정리할 예정이고, 이 다음에는 왓챠에서 소개하는 "쿼리 최적화"에 관해 도움이 된 글을 소개하겠습니다. 😊

리팩터링 2판 (리팩토링 개정판)

Hanbit

2021년 3월 21일 오전 10:31

댓글 0

주간 인기 TOP 10

지난주 커리어리에서 인기 있던 게시물이에요!

현직자들의 '진짜 인사이트'가 담긴 업계 주요 소식을 받아보세요.

커리어리 | 개발자를 위한 커리어 SNS