코딩 컨벤션(coding convention)은
특정 프로그래밍 언어로 코드를 작성할 때 따르는 스타일 가이드 또는 규칙 세트입니다. 이는 변수명, 메서드명, 클래스명의 네이밍 규칙, 들여쓰기, 주석 작성 방법, 파일 구조, 코드 정렬 방식 등 프로그램의 가독성, 유지보수성, 일관성을 향상시키기 위한 방법론을 포함합니다.
코딩 컨벤션 정의
- 정적 파일 (CSS, XML, JS)
- 규칙: 소문자 사용, 단어 간 구분은 스네이크 케이스(_)로 합니다.
- 예시: style_sheet.css, config_file.xml, main_script.js
- JSP 파일
- 규칙: 카멜 케이스(CamelCase)를 사용하여 첫 글자는 소문자로 시작합니다.
- 예시: home.jsp, accountPage.jsp
- 자바 파일 (클래스)
- 규칙: 파스칼 케이스(PascalCase)를 사용하여 각 단어의 첫 글자는 대문자로 시작합니다.
- 예시: HomeController.java, AccountService.java
- HTML id, name 속성
- 규칙: 카멜 케이스를 사용하여 첫 글자는 소문자로 시작합니다.
- 예시: <input id="userName" name="userName"/>
- CSS 클래스
- 규칙: 소문자 사용, 단어 간 구분은 하이픈(-)(-)**``**으로 합니다. 외부 라이브러리와의 충돌 방지를 위해 접두사를 사용하는 것을 권장합니다.
- 예시: .btn--primary, .nav--item
- URL 주소 설계
- 규칙: 모두 소문자 사용, 단어 간 구분은 하이픈(-)**``**으로 합니다.
- 예시: /user-profile, /get-account-details
- 데이터베이스 테이블
- 규칙: 소문자 사용, 단어 간 구분은 스네이크 케이스로 합니다.
- 예시: user_account, transaction_history
- 함수명 (서비스 레이어)
- 규칙: 카멜 케이스를 사용하여 첫 글자는 소문자로 시작합니다. 함수가 수행하는 동작과 객체를 명확하게 표현합니다.
- 예시: saveAccountDetails(Account account), findUserById(Long id)
💡 서비스 레이어
서비스 레이어에서의 메서드 네이밍은 코드의 가독성과 유지보수성에 큰 영향을 미칩니다. 명확하고 일관된 네이밍 컨벤션을 사용함으로써, 코드를 더 쉽게 이해하고, 다른 개발자들이 코드와 상호 작용할 때 발생할 수 있는 혼란을 최소화할 수 있습니다. 아래는 서비스 레이어에서 널리 사용되는 네이밍 컨벤션 규칙입니다:
CRUD 연산 Create: 새로운 엔티티를 생성하는 메서드는 create로 시작합니다.
예: createUser(User user)
Read: 엔티티를 조회하는 메서드는 read, find, get 등으로 시작할 수 있습니다. 단순 조회뿐만 아니라 조건에 따른 검색을 포함합니다.
예: readUser(Long id), findUserByUsername(String username), getUserDetails(Long userId) Update: 엔티티를 수정하는 메서드는 update로 시작합니다.
예: updateUser(User user) Delete: 엔티티를 삭제하는 메서드는 delete로 시작합니다.
예: deleteUser(Long id)
조회 연산 findBy: 특정 조건을 만족하는 엔티티를 찾을 때 사용합니다.
예: findByUsername(String username) findAllBy: 주어진 조건을 만족하는 모든 엔티티를 찾을 때 사용합니다.
예: findAllByStatus(String status) countBy: 특정 조건을 만족하는 엔티티의 수를 계산할 때 사용합니다.
예: countByStatus(String status)
명확한 도메인 객체 처리 표현 메서드 이름은 처리하는 특정 도메인 객체를 명확하게 나타내야 합니다. 이는 메서드의 목적이나 수행하는 작업을 직관적으로 이해할 수 있게 해 줍니다. 예: getOrderListByUserId(Long userId), updateUserProfilePicture(User user, Image picture)
구글 코딩 컨벤션 사례 살펴 보기
https://google.github.io/styleguide/
Google Style Guides
Style guides for Google-originated open-source projects
google.github.io
참고 자료 - 도메인 설계 모범 사례
REST API 란 (1)
1. REST API의 탄생
REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.
2. REST 구성
쉽게 말해 REST API는 다음의 구성으로 이루어져있습니다.
- 자원(RESOURCE) - URI
- 행위(Verb) - HTTP METHOD
- 표현(Representations)
1) URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)
GET /members/delete/1
위와 같은 방식은 REST를 제대로 적용하지 않은 URI입니다. URI는 자원을 표현하는데 중점을 두어야 합니다. delete와 같은 행위에 대한 표현이 들어가서는 안됩니다.
2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
위의 잘못 된 URI를 HTTP Method를 통해 수정해 보면
DELETE /members/1
회원정보를 등록하는 URI
GET /members/insert/2 (x) - GET 메서드는 리소스 생성에 맞지 않습니다.
POST /members/2 (o)
HTTP METHOD의 알맞은 역할 POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있습니다.
METHOD 역할
| POST | POST를 통해 해당 URI를 요청하면 리소스를 생성합니다. |
| GET | GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다. |
| PUT | PUT를 통해 해당 리소스를 수정합니다. |
| DELETE | DELETE를 통해 리소스를 삭제합니다. |
URI 설계 시 주의할 점
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
<http://restapi.example.com/houses/apartments>
<http://restapi.example.com/animals/mammals/whales>
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 합니다. REST API는 분명한 URI를 만들어 통신을 하는 것이 목표 이기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않습니다.
<http://restapi.example.com/houses/apartments/> (X)
<http://restapi.example.com/houses/apartments> (0)
3) 하이픈(-)은 URI 가독성을 높이는데 사용
URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높일 수 있습니다.
4) 밑줄(_)은 URI에 사용하지 않는다.
글꼴에 따라 다르긴 하지만 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 합니다. 이런 문제를 피하기 위해 밑줄 대신 하이픈(-)을 사용하는 것이 좋습니다.(가독성)
5) URI 경로에는 소문자가 적합하다.
URI 경로에 대문자 사용은 피하도록 해야 합니다. 대소문자에 따라 다른 리소스로 인식하게 되기 때문입니다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이지요.
