개발 패시브 문서

 

 

 

시작하며

---

프로그래머에게 요구되는 것은 100점이 아닌 80~90짜리 프로그램을 기간 내에 완성하는 일이다.
// 오늘, 또 일을 미루고 말았다 中

 

 게임 캐릭터에게 '패시브'는 아주 중요합니다. 캐릭터에게 성능적으로 탁월함을 부여하기도 하고, 스킬을 보조하기도 하는 여러가지 장점이 있지만, 그 중 두드러지는 장점은 '스킬을 사용하지 못하는 상황에 처하더라도, 직면한 문제를 해쳐나갈 수단으로 사용 될 수 있다는 것' 입니다.

 

 이 문서는 업무 효율의 최적화를 위해 추상적인 제 개발 원칙들을 문서화하여 패시브처럼 사용하고자 작성 되었습니다. 시간이 날 때마다 추가 할 예정이고, 목표는 급하게 처리해야 하는 프로젝트가 생기더라도 문서를 기반으로 80% 이상의 완성도를 유지하는 것 입니다.

( 최종 수정 : 2023.04.06 )

 

 

 

목차

1. 설계
2. 코드 형식
3. 네이밍
4. 오류 처리
5. 테스트
6. 주석
7. 커밋

+ Memo
+ Reference

 

 

 

아키텍처

기본	사전에 아키텍처가 계획되지 않았다면 계층형 아키텍처로 시작한다.
	구조는 Interface, Application, Domain, Infrastructure, Dto로 시작한다.
규칙	인터페이스와 구현체를 분리한다. ( 1:1 매핑이라도 분리 )
	공통 기능은 global.util에 값 객체로서 정의한다.
	Application(Service)영역은 상태가 없는 선언의 집합으로만 구성한다.
	상태 변경은 도메인에서 진행하지만, 화면 노출을 위한 형식 변경은 DTO에서 진행한다.
	도메인의 결합을 최소화 하고, 조회가 많이 발생하는 기본 정보는 Authentication 객체에서 관리하는    것을 고려한다.

---

 

코드 형식

공통	클래스와 메서드 작성 전에 설명하는 주석을 먼저 작성한다. 대신 주석은 한 문장을 넘기면 안된다. ( SRP )
	최대한 클래스와 메서드의 크기를 줄이고 응집력을 높인다.
	적절한 추상화 수준에서 이름을 선택한다. 너무 구현을 드러내는 이름만 사용하여 발생하는 혼동을 없앤다.
	'Google Java Style Guide'를 따른다.
클래스	의미가 불분명한 숫자는 상수로 처리한다. 상수들이 4개를 초과한다면 enum으로 그룹화를 진행한다.
	import문이 길어진다면 와일드 카드를 사용한다.
	인터페이스를 통해 상수를 상속하지 않는다.
메서드	고차원 모듈에서 저차원 모듈로 코드를 배치한다. 결합이 강한 메서드끼리는 가깝게 위치하도록 한다.
	인수를 최소화 한다. 기본적으로 Model 객체를 인수로 사용하지 않는 것을 원칙으로 하지만, 인수가 5개를 초과한다면 DTO로 묶어 전달한다.
	함수 내부의 코드는 추상화 수준이 일치 해야한다.
	추이적 탐색이 발생한다면 DTO로 해결한다. ( 한 줄에 점은 하나만 찍는다. )
	조건문의 코드블럭을 생략하지 않는다.
	조건문을 사용할 때 부정 조건을 최대한 사용하지 않는다.

---

 

네이밍

규칙	기본적으로 주석이 없어도 이해가 될 정도로 서술적인 이름을 사용하는 것을 원칙으로 한다.
	너무 전문화된 단어나 나만 알고 있는 단어의 사용을 하지 않고 표준 명명법을 따른다.
	의미의 혼동을 방지하기 위해 Manager, Processor, Data, Info와 같은 단어를 사용하지 않는다.
	표기법에 일관성을 부여하고 검색에 용이하게 작성 한다. ( 하단의 규칙 참고 )
	줄여쓰지 않는다.
패턴	값을 가져오는 동작 : get□
	값을 변경하는 동작 : change□
	값을 추가하는 동작 : append□
	형식을 변경하는 동작 : convert□
	숫자를 처리하는 동작 : criculate□
	메세지를 전송하는 동작 : send□

---

 

예외 처리

규칙	최대한 if문을 사용하되, if문으로 처리할 수 없을 때만 try-catch로 처리한다.
	예외 처리 코드가 2개 이상 생긴다면 캡슐화한다. ( 외부 라이브러리의 예외는 항상 묶어서 사용한다. )
	기본적으로 JAVA Exception 표준을 사용하고, 항상 충분한 정보를 제공한다.
	return 값으로 null을 반환하지 않는다.

---

 

테스트

규칙	기본적으로 비즈니스 로직 작성 후 즉시 테스트 코드를 작성하는 것을 원칙으로 한다. ( 자동화 예정 )
	GIVEN / WHEN / THEN 원칙을 사용한다.
	테스트 당 하나의 개념만을 사용한다.
	Infrastructure 계층은 TestContainer를 사용하여 테스트한다.
	상단의 계층들은 Junit5와 Mockito를 사용해 다른 계층과 격리하여 테스트한다.
커버리지	Jacoco 라이브러리를 사용해 구문 커버리지를 항상 체크한다. ( 커버리지는 유동적으로 조절 )

---

 

주석

규칙	코드 작성 전 한 줄로 설명하는 주석을 작성한다.
	라이선스나 외부 참고 문서를 작성한다.
	정규 표현식과 크론 식 등을 설명하는 주석을 작성한다.
	체크포인트가 되는 부분에 주석을 작성한다.
관리	주석 처리된 코드는 항상 제거한다.

---

 

커밋

규칙	(작성중)

 

 

 

 

 

✔ Memo

---

물론 아직은 부족하고 당연한 이야기만 나열되어 있지만, 꾸준히 규칙을 문서화 한다면 개발 기본기와 속도에 큰 기여를 할거라고 믿습니다.

(2023.04.06)

 

 

 

 

   

 

✔ Reference 

Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고

개발자 원칙 | 박성철 - 교보문고

객체지향 생활 체조 원칙