10-08

내일배움캠프 Node.js 사전캠프 5일차

1. ZEP에서 이루어진 팀단위 아티클 스터디

(1) 아티클 주제

SQL 가독성을 높이는 다섯 가지 사소한 습관 | 요즘IT (wishket.com)

 

SQL 가독성을 높이는 다섯 가지 습관들을 알아보자.

(2) 아티클 요약

1. 예약어는 대문자로
   • 기본적으로 예약어를 하이라이팅해주지만, DB에 따라 예외는 있을 수 있다.
2. 행갈이를 자주 하자
   • 서로 다른 절을 같은 줄에 쓰지 않는다.
   • 각 라인의 예약어만 확인하더라도 코드의 구조를 쉽게 파악할 수 있다.
3. 행갈이를 더 자주 하자
   • 절 뿐만 아니라 각각의 조건식마다 행갈이를 할 경우 주석 처리 시 더 편리하게 코드 관리가 가능하다.
   • 이를 응용하여 WHERE절에 1=1이라는 의미없은 조건식을 추가하는 경우도 있다.(조건식에 한 줄씩 할당해주기 위함)
4. 주석을 쓰자
   • 코드를 쓴 의도를 짧게라도 적어두는 게 좋다.
   • 특히 서브쿼리가 많아지고 코드가 길어진다면 더더욱 주석이 필요하다.
   • 조건이 왜 필요한지, 어떻게 동작하는지 내용을 적어놓으면 코드를 이해하는 데 도움이 된다.
5. Alias(별명)를 잘 쓰자
   • 서브쿼리, 컬럼 Alias를 편의상 a, b, c…등으로 쓰곤 하는데 이는 좋지 못한 습관이다.
   • 예를 들어 아우터 쿼리 어딘가에서 a.x + b.y라는 코드를 발견한다면 그 코드가 무엇을 의미하는지 직관적으로 알기 어렵다.
   • 처음엔 작명이 번거로울 수 있으나 하다 보면 늘기 때문에 점점 쉬워질 것이다.
6. 가장 중요한 건 합의된 규칙
   • 함께 일하는 동료들과 합의된 규칙이 최우선 순위다. 아무리 나의 방식이 효율적이더라도 모두가 공유하는 규칙을 무시하는 건 바람직하지 못하다.
   • 언제나 내가 쓴 코드를 누군가 볼 거라고 생각하며 작성하자. 지금 잘 작성한 SQL 코드 한 단락이 미래의 나에게 도움이 될 수도 있을 테니.

(3) 인사이트 공유하기

뜻밖에도 공감이 가는 습관들이 많았다. 특히 예약어를 대문자로 쓰라는 습관이 그러했다. 아직 강의 신청을 완료하지 못해서 DBeaver 대신 커맨드 창으로 MySQL을 다루고 있는데, 알다시피 커맨드 창에는 예약어를 하이라이팅해주는 기능이 전혀 없다. 행갈이를 해주지 않으면 어디서부터 어디까지가 내가 요청한 쿼리인지 알아보기도 어렵다. 오류까지 발생한다면 더 심각해진다. 때문에 예약어를 대문자로 쓰는 것은 내게 있어서 쿼리문 가독성에 매우 큰 도움이 되곤 했다.

 

반면에 새롭게 깨우치게 된 습관이 하나 있다. 그건 바로 행갈이를 더 자주하라는 항목이다. 코드가 길어지면 가독성이 떨어진다는 게 기존의 인식이었던 터라 처음에는 의아한 제목이라고 생각했다. 절마다 하는 걸로 충분할 텐데 왜 굳이 조건식마다 행갈이를 해주라는 걸까. 그러나 내용을 읽고 나니 고개가 절로 끄덕여졌다.

 

만약 우리가 SQL에서 조건식마다 행갈이를 하게 된다면 특정 로직을 추가하고 제거하는 과정을 주석만으로 해결할 수 있다. 이것만으로도 제공하는 이점이 매우 클 뿐더러, 해당 코드에 몇 개의 조건식을 지정했는지, 또 몇 개의 칼럼을 선택했는지도 한눈에 볼 수 있는 습관이다. 어쩌면 SQL이 쿼리로 이루어진 언어라서 가능한 게 아닐까? SQL에서 한 번 요청을 보낸 쿼리는 그것으로 역할을 다 하지 않던가. 그렇다면 아무래도 SQL에서는 개별적인 코드 단락의 가독성이 훨씬 중요할 터. 코드가 길어진다고 해도 확실한 강점이 있다면 가독성이 올라갈 수 있다는 점에 수긍하게 된다.

 

끝으로 곰곰이 생각해보니, 며칠 전에 작성한 쿼리문을 보면서도 이게 대체 뭘 푼 답안인지 감이 오지 않았던 경험이 떠오른다. 그때는 쿼리문이 작동하게 만들고 오류를 해결하는 일에 급급하다 보니 발생했던 실수였다. 코드의 유지보수라는 게 얼마나 중요한지 원론적으로는 알고 있었으면서도, 막상 실천해야 하는 순간엔 나도 모르게 게을러졌던 게 아닐까. 아무렴 언어는 어떨까. 코드 작성의 편의성을 높여주는 에디터를 쓰고 있기 때문에 대충 코드를 쓰고 prettier 확장프로그램을 돌리면 그걸로 정리가 다 되었다고 착각하곤 했다. 어차피 읽어보면 알 것이라고 단정 지으며 주석 달기조차 귀찮아하던 스스로가 생각난다. 막상 나중에 다시 본다면 한참을 들여다봐야 무슨 코드인지 알 수 있을 텐데 말이다.

 

“언제나 내가 쓴 코드를 누군가 볼 거라고 생각하며 작성하자”

 

이 말을 기억하며 코드를 작성하는 습관을 길러야겠다.

2. 팀 노션으로 회의록 발행

(1) 무엇을 새롭게 배웠는가

코드도 결국 언어이기 때문에 누가 보아도 잘 읽혀야 한다.
특히 함께 일하는 동료들과 명확히 소통할 수 있게 작성 규칙에 관심을 기울여야 한다.

(2) 무엇이 새롭게 궁금해졌을까

코드 작성 규칙들, 데이터 명명 규칙들
[인생 프로그래밍] 코드 작성 규칙들 (Cod.. : 네이버블로그 (naver.com)
데이터베이스 명명 규칙 (Naming Conventions) (tistory.com)

[인생 프로그래밍] 코드 작성 규칙들 (Coding Conventions)

 

데이터베이스 명명 규칙 (Naming Conventions)

 

 

서브쿼리 사용시 별칭을 명확히 정하는 게 중요한 이유

a, b가 대체 무엇일까? 코드를 얼핏 봐서는 알 수 없다는 게 문제!
특히 b는 서브쿼리 안에 서브쿼리가 들어간 구조라서 무슨 코드인지 이해하려면 a에 들어간 내용까지 다 읽어야 한다. → 가독성이 안 좋음

3. 하루를 되돌아 보며

사실 오늘의 아티클은 이게 아니라 자바스크립의 역사를 소개한 글이었다. 그런데 팀원들과 걷기반 퀘스트에 대한 질문을 주고받던 도중, SQL과 관련된 아티클을 먼저 다루어보자는 이야기가 나와서 순서를 변경하게 되었다.

 

다시 생각해봐도 적절한 결정이었던 것 같다. 덜컥 자바스크립트와 친밀해지기엔 우린 아직 미숙한 부분이 많기 때문이다. 지금 배우고 있는 SQL부터 차근차근 공부해나가는 것이 게 맞지 않을까.

 

오늘은 특히 서브쿼리에 대한 개념을 이해하기 위해 머리 싸매며 열심히 팀원들과 정보를 공유했다. 이런 우리의 노력이 앞으로 퀘스트를 수행할 때 도움이 될 것이라 믿어 의심치 않는다. 이전 시간에 배웠듯, 마음껏 실수하고 개선해나가는 게 우리에게 있어선 정답일 테니까.