분류 전체보기

Deep Dive Series/Good Condition

[좋은 조건문 작성하기 1] Early Return은 깊이가 얕아서 좋다!

※ 대부분에 언어에 해당될 수 있는 내용이지만, javascipt 언어에 가장 적합한 글입니다. 0. 깊이가 얕은 Early Return 방법 말 그대로 일찍이 RETURN 하여 함수를 빠져나오는 것이다. 바로 코드를 보자. const isNumber = v => /^(\s|\d)+$/.test(v); // function getBoardByRegisterId(registerId) { if (registerId.length >= 4) { if (isNumber(registerId)) { const data = []; // 20 Line ... return data; } else { alert('아이디는 숫자만 유효합니다.'); } } else { alert('아이디는 4자 이상 필요합니다.'); } } ..

Deep Dive Series/Good Condition

[좋은 조건문 작성하기 0] 왜 좋은 조건문을 작성해야 할까?

Q. 코딩에서 조건문은 어떠한 역할을 할까? 조건문은 모든 프로그래밍 언어를 막론하고 절대 빼놓을 수 없는 간단하지만 매우 중요한 뼈.대.요소라고 생각한다. 단순히 A의 조건에는 B의 로직이 수행되고, A가 아닌 조건에는 C의 로직이 수행된다는 개념을 떠나 새로운 조건이 계속 계속 생겨나면 그 조건 전체가 서비스의 복잡도를 결정할 만큼 중요한 요소라고 생각한다. 좋은 조건문은 이러한 요소를 좋게 만든다는 것을 말한다. if (A) { B(); } else { C(); } Q. 그렇다면 좋은 조건문은 어떤 조건문을 말할까? 우리 팀의 유지보수를 위한 가.독.성이 높은 조건문을 말한다. 여기서 단순히 가독성 높음에 집중하면 보기에만 좋은 떡?이 될 가능성이 높다. 유지보수하기 좋게 가독성 높은 조건문을 작성..

Small Talk

개발자 코드리뷰가 필요한 이유 (이상적인게 아니고 기본인 것)

개발자 코드리뷰가 좋거나 안 좋거나 아니면 애매하다는 이유로 잘 정착하지 못하는 개발조직이 많은 것 같다. 잘 정착하기위해서는 코드리뷰 참여자들 모두가 마음에서 우러나는 긍정적인 신호가 필요하다. 그 긍정적인 신호를 만들기 위해 코드리뷰가 필요한지에 대하여 누군가를 설득한다고 가정하고 글을 써보려고 한다. 1. 코드리뷰의 장점 개발 컨벤션 준수, 이슈 발견을 대표적으로 꼽는다. 1-1. 코딩 컨벤션 준수 = 생산성 향상 내가 개발한 기능을 꼭 내가 유지보수하는 것은 아니다. 그리고 내가 개발한 기능을 꼭 내가 기능 고도화하는 것도 아니다. 새롭게 팀을 옮겨 새로운 환경의 코드를 만나게 될 수도 있다. 그렇기에 개발을 하면서 수없이 다른 사람의 개발 코드를 만나야하며 이해해야한다. 이때, 생산성을 높이기 ..

Googling/postgresql

[RDBMS] PostgreSQL vs MySQL 차이 (fear. 버전을 막론하고)

둘 다 사용경험은 있는데, 사용 경험상으로는 큰 차이가 있다고 보기는 어려웠다. 구글링을 통해 차이를 찾아보면 좋지않을까 하여 이곳 저곳 뒤져보았고, 같은 관계형 데이터베이스(RDBMS)로서 어떤 차이가 있는 것인지 정리해보려 한다! 👨‍💻 0. 소프트웨어는 버전이 몇 인지가 중요하다. 항상 느끼지만 소프트웨어는 계속 발전하고, 부족한 부분들이 보완 업그레이드되는 방향으로 흘러간다. 그래서 이전에는 단점이었던 부분들이 업그레이드를 통해서 좋아지는 경우가 많다. MySQL의 경우에는 2020년 8.0 버전업을 하면서 이전에는 단점이라 꼽던 많은 부분들이 개선이 되었다. (그만큼 하위 호환이 안 되는게 많다고 한다.) 그 부분들은 고려해서 차이를 찾아볼 필요가 있다. 다른 블로그들의 비교 글들이 이 부분을 ..

Deep Dive Series/Paging

[페이징 톺아보기 3] 두번째 페이징이 잦을때, IN절 페이징

2페이징 스크롤이 잦은 기능의 경우, 써보면 좋을 법한 아이디어가 있어 공유해보려 한다. 보통 스크롤 페이징을 구현해놓더라도 1페이징에 머무는 기능이 대부분이다. 예를 들어, 채팅 메시지 목록을 1페이징으로 조회한다고 했을 때, 메시지를 스크롤로 올려 이전 메시지를 확인하는 경우보다 1페이징에서 머물다 바로 메시지를 보내는 경우가 많다. (아니라고 하더라도 가정해보자) 하지만, 페이스북의 뉴스피드 타임라인의 경우 첫 페이징에 머물기보다는 2페이징, 3페이징 스크롤하여 나아갈 가능성이 많다. 이러한 경우 물론, OFFSET 페이징보다 커서 페이징이 이점이겠지만, 때에 따라 커서 페이징이 불가능한 경우가 있을 수도 있고, 커서가 2개 이상 존재하여 OFFSET 보다 속도가 나지 않는 경우가 있다. 이럴 때,..

Deep Dive Series/Paging

[페이징 톺아보기 2] 두 테이블의 유니온 페이징 (정석이 아니라 선택)

특수한 경우에 페이징을 구현함에 있어 괜찮은 속도 개선을 만들어낸 경험이 있어 정리해보려 한다. 0. 테이블 2개의 페이징 보통 페이징을 시도하는 테이블은 1개가 정석인데, 2개로 요청이 들어왔다면 어떻게 쿼리를 짜야할까? 게시물과 댓글 각각 테이블로 데이터를 관리하고 있는 상태에서 게시물, 댓글 모두 등록시간순으로 정렬해 한꺼번에 리스팅 해주면 좋겠다는 요건이 나왔다. 일단, 강력하게 게시물, 댓글을 탭을 나눠 따로 조회했으면 좋겠다고 주장했으나 먹히지 않았다. 1. UNION 페이징 --UNION PAGING SELECT data, register_time FROM board --게시물 UNION SELECT data, register_time FROM comment --댓글 ORDER BY regi..

Deep Dive Series/Paging

[페이징 톺아보기 1] 가장 효율적인 커서 기반 페이징

0. 스크롤 페이징이 점점 느려져요! 페이징은 점점 느려질 수 있다. 테이블의 크기가 커지면서 느려질 수도 있고, API 로직이 복잡해지면서 느려질 수도 있다. 하지만, 애초에 OFFSET, LIMIT으로 조회하는 방식은 앞에서 읽었던 행을 다시 읽어야하기 때문에 뒤로 갈수록 느리다. 그리고 OFFSET, LIMIT은 인덱스 스캔과는 전혀 상관없는 명령어기때문에 인덱스의 이점을 살릴 수도 없다. 이 때, 개선 가능한 방법이 No-Offset 페이징 혹은 커서 페이징이라고 불리우는 페이징 기법이다. 1. 속도가 빠른 커서 페이징 "커서 기반 페이징이 가장 효율적인 방법이며, 가능한 항상 사용되어야한다."라고 타임라인 기능을 무한스크롤 페이징으로 만든 페이스북 개발자는 말했다. 그만큼 커서 페이징은 가장 효..

Googling/postgresql

[postgreSQL] 카운트 쿼리 쓸 때 알아두면 좋은 것 (null, limit)

1. 카운트 쿼리에 사용되는 데이터가 null 일 경우 건수에 포함되지 않는다. 이 점을 활용하여 (case when ~ then 1 else null end) 활용 필터링이 가능하다. count(1), count(*), count(column) 모두 실행계획과 실행시간이 동일하니, column 쓸 때만 null로 개수 빠지는지 확인만 하면 된다. --null 상관없이 전체 건수를 셈 SELECT count(*) FROM board; SELECT count(1) FROM board; --contents 중 null 인 데이터를 빼고 셈 SELECT count(title) FROM board; --contents 중 null 인 데이터를 빼고 중복 제거하여 셈 SELECT count(distinct tit..

날개단
'분류 전체보기' 카테고리의 글 목록 (5 Page)