소소한 코딩일지

🔥 서적을 바탕으로 한 내용 정리 느낌이 강한 문서입니다. 이런 방식을 사용하는구나 정도로만 알고, 이 내용이 원칙이 아님을 알립니다. 🙇 코드를 작성하면서 변수, 함수명을 짓는 부분은 항상 고민이 되는 부분이다. 뭔가 길게 쓰면 가독성이 떨어질 거 같고, 짧게 쓰면 당상 쓰기엔 편하지만 어떤 변수인지 정확하게 알기 힘들 수도 있고… Clean Code 와 개발자의 글쓰기라는 서적을 읽으면서 Name Convention에 대한 내용을 정리해보려고 한다. 아래 블로그 글은 오픈소스에 작성된 함수, 변수, 클래스의 네이밍을 분석한 내용을 담고 있다. 한 번 살펴보면 재밌을 것(?) 같다. 오픈소스의 네이밍 특징들 위 블로그에서도 마찬가지지만 이름을 짓는 방식은 어느 특별한 방식이 있는 것이 아니라 우리가 알..

스키마(Schema) 데이터 타입의 집합, API에 반환할 데이터의 타입에 대해서 생각해야 하고, 이 타입에 대해서 충분한 이야기를 나누고, 제대로 정의해두어야 한다. 스키마 우선주의(Schema First)는 디자인 방법론으로 이를 통해서 모든 팀원이 데이터 타입에 대해서 숙지할 수 있도록 유도한다. 백엔드 팀에서는 어떤 데이터를 저장하고 전달해야 하는지 이해할 수 있고, 프런트엔드 팀에서는 사용자 인터페이스를 작업할 때 필요한 데이터를 정의할 수 있다. GraphQL에서도 스키마 정의를 위해 SDL(Schema Definition Language)를 지원한다. 프로그램 언어, 프레임워크에 상관없는 GraphQL의 쿼리 언어처럼, 사용법이 항상 동일하다. SDL을 통해 GraphQL 스키마 문서를 만 ..

SQL과 GraphQL GraphQL은 쿼리 데이터베이스용으로 만들어진 개념을 인터넷에 적용해 만들어진 것 GraphQL 쿼리 하나로 데이터 베이스 내에 존재하는 데이터를 모아서 전달할 수 있다. GraphQL과 SQL 둘다 Query Language이지만 사용환경이 다르다. SQL의 경우 데이터 베이스로 보내지만, GraphQL은 API로 보낸다. SQL의 데이터는 데이터 테이블 내에 존재하지만, GraphQL의 데이터는 단일 데이터 베이스, 여러 개의 데이터 베이스, 파일 시스템, RestAPI, WebSocket, 다른 GraphQL API에서 데이터를 받아올 수 있다. 정리하면 SQL은 데이터 베이스용, GraphQL은 인터넷용 쿼리 언어이다. SELECT, INSERT, DELETE, UPDAT..

그래프 ( Graph ) 그래프는 상호 연관 관계에 놓여 있는 객체 집합을 표현할 때 사용, 객체 간의 관계를 그래프라고 생각하면 편하다. 각 포인트를 노드(Node)나 정점(Vertex)라고 하고, 각 노드/정점을 잇는 선을 엣지(Edge)라고 한다. 그래프는 표현식으로도 나타낼 수 있다. // 노드 or 정점 vertices = { 1, 2, 3, 4 } // Edge edges = { {1, 2}, {1, 3}, {1, 4}, {2, 4}, {3, 4}, } 위 표현식을 그림으로 나타내면 다음과 같이 그려진다. 시작 노드와 끝 노드의 구분 여부에 따라 그래프 종류를 구분할 수 있다. 무방향 그래프: 시작 노드와 끝 노드를 마음대로 정하면 된다. 특정한 번호 순서를 따르지 않는다. 비선형 데이터 구조..

GraphQL 이란 API를 만들 때 사용할 수 있는 쿼리 언어, 쿼리에 대한 데이터를 받을 수 있는 런타임이기도 하다. GraphQL 쿼리는 사용자가 필요한 데이터만 받도록 작성할 수 있다. 쿼리문을 중첩하여 다양한 객체를 응답 데이터로 받아올 수 있고, 하나의 요청으로 두 가지 데이터 타입에 대한 응답을 얻어낼 수 있다. 마찬가지로 원하지 않는 데이터에 대해서는 제외하여 요청을 보낼 수 있다. GraphQLdms 선언형(declarative) 데이터 페칭(fetching)라고 불린다. 어떤 데이터를 불러올 것인지, 요구사항만 작성하면 되고, 어떻게 데이터를 가져올 것인지는 신경 쓰지 않아도 된다. GraphQL의 서버 라이브러리는 다양한언어로 만들어져 있기 때문에 유연한 사용성을 보인다. GraphQ..

동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 무엇(what)과 언제(when)을 분리하는 전략이다. 무엇(what)과 언제(when)을 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 하나의 구조 내에 더 작은 구조들로 문제를 분리하여 시스템의 이해를 도울 수 있다. 이런 구조적인 개선뿐만 아니라 동시성은 다양한 작업을 동시에 처리함으로써 작업시간 면에서도 상당한 성능 향상을 가져다줄 수 있다. 미신과 오해 동시성은 항상 성능 향상을 가져다 준다. 여러 프로세서가 독립적으로 처리할 계산이 많은 경우에 성능이 높아지지만 안 그런 경우도 많다. 동시성을 구현해도 설계는 변하지 않는다. 단일 스레드 시스템과 다중 스레드 시스템은 다른 아키텍처를 가지고 있다. 동시성 여부에 따라서 시스템의 ..

창발성 남이 모르거나 하지 아니한 것을 처음으로 또는 새롭게 밝혀내거나 이루어 내는 성질. 창발적 설계로 깔끔한 코드를 구현하자 켄트 벡이 제시하는 단순한 설계 네 가지는 소프트웨어 품질을 크게 높여준다고 한다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 1. 모든 테스트를 실행한다. 우리는 설계 단계에서 동작하는 시스템을 설계해야 한다. 하지만 그 설계가 실제로 동작하는 것인지 검증하는 단계가 반드시 필요하다. 그래서 테스트 케이스를 작성한다. 테스트 케이스를 작성하는 것만으로도 시스템 설계 품질이 향상될 수 있다. 테스트 케이스가 많을수록 개발자는 수많은 테스트 코드를 작성할 것이고 그 부분에서 추상화, 의존성 주입, 인터페이스와 같은 ..

테스트 주도 아키텍처 구축 코드 수준에서 아키텍처 관심사를 분리할 수 있으면, 테스트 주도 아키텍처를 구축할 수 있게 된다. 테스트 주도 아키텍처를 통해 새로운 기술을 추가하면서 초기의 단순한 아키텍처에서 복잡한 아키텍처로 성장시켜나갈 수 있다. 의사결정을 최적화하라 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 모든 부분에서 한 사람이 모든 의사결정을 할 수는 없기 때문에 그 부분에 적합한 사람이 직접 의사결정을 하는 것이 바람직하다. 그리고 빠르게 결정을 내리는 것보다 최대한 많은 정보를 참고하여 최적의 결정을 내리기 위해 충분한 시간을 가지고 기다렸다가 결정을 내리는 방법 또한 바람직한 방법이다. 명백한 가치가 있을 때 표준을 현명하게 사용하라 어떤 한 분야의 표준을 사용한 다..

클래스 체계 클래스를 정의하면 변수에 대한 내용을 먼저 정의한다. static, public상수를 먼저 정의하고 그다음 private 변수를 정의한다. ( 클래스를 정의하는 부분에 대해서는 전혀 몰라 책의 내용을 그대로 가져왔습니다.) 변수와 유틸리티 함수에 대해서는 최대한 숨기는 것을 원칙으로 한다고 한다. 테스트 코드 작성을 위해서 protected로 선언하여 접근을 허용하기도 하지만 최대한 private으로 정의하는 것을 우선으로 하여 정의한다. (캡슐화) 클래스의 크기 클래스의 크기는 무조건 작으면 작을수록 좋다고 한다. 그렇다면 얼마나 작아야 하는가? 책에서는 클래스가 너무 많은 '책임'을 가지고 있는 것은 부적절하다고 한다. 단일 책임의 원칙 단일 책임의 원칙(Single Responsibil..

TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 테스트 코드는 실제 구현 코드와 함께 수많은 코드라인이 생성되게 되고, 테스트 코드 관리 부분에 대한 문제를 유발한다. 깨끗한 테스트 코드 유지하기 단순 현재 테스트 과정만을 넘어가기 위해서 아무렇게나 테스트 케이스를 작성하는 것은 문제가 되지 않는다. 하지만 이후 변경사항을 적용하고, 유지 보수 부분에서 이전에 마구 짰던 테스트 케이스는 그 테스트 코드를 유지 보수하는 비용 또한 증가하기 때문에 비효율적으로 작용하게 된다. 테스트 코드도 실제 코드만큼이나 중요하다. 테스트는 유..