Java 코드 컨벤션 협업을 위한 방법

안녕하세요
앵과장입니다.

2022년 이제는 그만 모아야 할것 같은 웰컴 패키지를 받았습니다.
앞으로 3년~4년 정도는 웰컴팩을 받지 않는 방향으로 살아보도록 하겠습니다.

사실 저도 저를 잘모르겠어요!!!

 

why 코딩 규칙이 필요한 이유?

• 소프트웨어 개발에서 가장 고민되는 부분은 변수명 메소드명 입니다.
• 언어별로 요구하는 스타일이 존재하는데 Java는 보통 카멜표기법으로 표현하며 enum을 선언할때 대문자를 선호 하는편입니다.
• Java는 컴파일 언어이며 지속적으로 성장하는 언어입니다. 타입 선언시 var 라는 스크립트에 방법적 접근도 가능하지만 직관적이지 않을 수 있습니다. Long은 기본 Null 이며 long 0의 값으로 선언됩니다.
• 협업에는 구성원들에 성장과 성향에 따라서 학습된 러닝커브가 인지된 상태에서 진행 되어야 합니다. 사람마다 Slow start 또는 Fast start 타입이 존재하며 둘다 모두 시간이 흐름에 따라 성장하기 때문입니다.
• 불필요한 문서보다는 직관적이고 반복해서 볼수 있는 내용을 담고 있어야 합니다. 내생각을 정리 하며 쓰는글과 막연히 쓰는글은 상당히 다른내용을 담고 있습니다.
• 서비스를 지속적으로 성장시키기 위해서는 일관성이 유지되어야 합니다.

소스를 설명하는 주석

클린코드에서 되도록이면 주석을 사용하지 않는 것을 권고 합니다.

하지만 프로젝트 소스레벨 및 팀 구성원에 도메인 지식에 따라서 필요하다면 해당 클래스에 내용을 좀더 이해할수 있는 주석이 필요합니다.

중요한 포인트는 무조건 이게 좋다라는 생각은 잘못된 부분이라는점 명심하세요!!
(미쿡과 우리나라는 사용하는 언어가 다르며 제가 아직 영어가 많이 부족합니다 ㅜㅡㅜ)

되도록 소스레벨 class위쪽에 사용하능것을 추천 드립니다.

/**
* 상품 광고 타입별 처리 내용을 담고 있고
* 특정 타입마다 상태값을 변경해야하는 행위를 정리하는
* 기능을 담고 있습니다.
*
*/

 

의미가 부정확하거나 불필요하다면 과감하게 삭제하시기 바랍니다.

/**
* 2021.01.30일기점에 임시적으로 사용하는 클래스이며
* 이후 삭제 예정
*/

이런건 그냥 날짜가 지났음에도 남아있는데 보이면 지우는것 추천드립니다.
지워서 문제가 발생한다는 생각보다는 어차피 git으로 히스토리를 관리합니다.

소스 중간 중간 사용은 하지마시고 해야한다면
FIXME, TODO 같은 내용을 담아주세요

개발하다 가끔 내가 내일 해야하거나 기억하기위한 포인트를 두는데 왠만하면 남기지말고 제대로 끝낼수 있는 기능단위를 항상 내몸이 적응 하도록 하는것을 추천합니다.

가끔씩 주석된 소스를 올리시는분들이 있는데 ...
소스가 무슨 김장 김치냐!! repo가 김치냉장고야!!
엎드려!!

주석으로 만들소스는 올리지마시고 명확하게 구현을 다시 하는방법으로 진행하시고 필요하다면 git으로 히스토리가 기록되는 방향으로 하셔야 합니다.

불필요한 소스는 분석하는데 상당히 괴로운 포인트중 하나입니다.

들여쓰기

소스는 기능을 구현하는 언어입니다.
책을 읽을때 난독증이 오는 구성보다는 문맥이 잘 보이고 중요한 포인트가 보일수 있도록 하는것이 중요합니다.

개발도 마찬가지로 협업에서 다른사람의 글을 읽는 것과 마찬가지 입니다.

자네 이거 한번 분석해보게!!!!!!!!

• 4개의 빈 칸(space)를 들여쓰기 단위로 사용한다.
• 들여쓰기의 정확한 구현(빈 칸을 사용하거나 탭을 사용하거나)은 정해져 있지 않다.
• 탭은 4개의 빈 칸이 아니라, 8개의 빈 칸으로 설정하는 것이 좋다.

 

한줄에 표현

개발하다보면 좀 길어질수 있습니다.
예전에는 VI로 개발하시는 오래된 찐개발자(꼰대) 분들이 있었는데 그분들은 항상 예기하시지요

앵사원!! 이거 자네가 이렇게 한건가!!
넵 해킹에 대비하여 일부로 이렇게 해봤습니다.

As-is

업드려!!!!!!

To-be

기능이 안돌아 업드려!!

물론 요새는 좀 길어질수 있습니다.
javascript는 길자나요 !!

그래도 되도록이면 권고 하는 글짜수가 있는데  70자라고 하는데 요샌뭐 눈에 잘보이면 됩니다.
우리가 모니터 1개로 개발하는거 아니자나요!! 그래도 너무 길어지면 곤란합니다.

 

인터페이스 를 꼭 만들어야하나요?

예전 Spring 비지니스구현시 Service, ServiceImpl Class 2가지를 꼭 만들어야 하는 형태로 작업했던 기억이 있는데 최근에는 Service에 직접 인터페이스 없이 구현체로 직접 개발되는 소스들을 많이 볼수 있습니다.

 

인터페이스를 만드는 이유는 리스코프 치환원칙(LSP)에 서도 SOLID원칙에 들어갑니다.

하지만 꼭 인터페이스를 만들어야하는건 아닙니다.

우리가 막연히 만드는 인터페이스를 간혈적으로 보면 재사용하지 않는 경우도 많기때문입니다.

 

처음부터 확장성있게 개발하는것도 좋은 방법이지만 서비스가 어떻게 될지 모르는데 모든것을 염려하고 진행할수 있을까요? 

현실적인 방향에서 서비스에 품질과 속도까지 고려되는 형태가 되어야합니다.

 

 

 

메소드 명명 규칙

네이밍을 만들때 중요한 고려사항이 존재합니다.

• 왜 존재 해야 하는가?
• 무슨 작업을 하는가?
• 어떻게 사용하는가?

public List<Piece> findPiecesByColor(Color color){}
// 왜 존재해야 하는가 - color에 대해 존재하는 piece들을 알기 위해.
// 무슨 작업을 하는가 - color에 맞는 piece들을 가져온다.
// 어떻게 사용하는가 - 체스판에서 흑색(or 백색)의 piece들을 가져와서 점수를 계산.

메소드 명명규칙

// Example
// 동사
public void getUserByName(){}
public void setDisplayName(){}
public void inputData(String input){}
    
// 전치사
public String toString(){}
public User of(){}

//조건
public Boolean isCheck(){}

if(isCheck()){
}
.
.
.

//객체 생성
public User newInstanceUser(){
	User user = new User();
    return user;
}

 

개발하면서 다양한 코드 컨벤션이 존재하지만 그래도 많이 사용하게되는 내용에 대해서 정리하였습니다.

 

코드컨벤션에 더 자세한내용은 아래 링크를 첨부 합니다.
http://kwangshin.pe.kr/blog/java-code-conventions-%EC%9E%90%EB%B0%94-%EC%BD%94%EB%94%A9-%EA%B7%9C%EC%B9%99/
https://www.oracle.com/java/technologies/javase/codeconventions-contents.html

Java Code Conventions / 자바 코딩 규칙