우테코 프리코스 회고록

 우테코를 준비하면서 어떤 비즈니스 문제들을 해결하는데에 있어

많은 고려사항이 요구됨을 뼈저리게 느꼈다.

느낀점들이 많이 있지만 다 적을 수는 없기에 하나하나 적어나가 보려고 한다.

모든 내용은 저의 주관적인 생각임을 명시한다.

 

 패키지 나누기

 패키지 나누는 기준에 대한건 사람마다 각자 틀린 것 같다.

어떤 문제 유형이냐에 따라 갈리는데, 보통 웹사이트 구조면 MVC 패턴을 따르는 듯하고, 어떤 프로그램이라면 보통 Domain, Service, Controller 등을 기본적으로 가져가고, 거기에 더 추가하는 형태인듯 하다.

특히 Service는 비즈니스 로직의 트랜잭션 부분을 담당하고, 모든 객체들에서 활용할 수 있도록 작성해야 하고, 되도록 내장함수들만 import 하여 사용하는 편이 좋다.

 

패키지를 나누는 나만의 기준은 다음과 같다.

Service : 비즈니스 로직 "한" 단위들에 대한 객체들을 모아놓은 패키지
Controller : 사용자의 입력에 대해 데이터를 처리해주기 위해 맞는 비즈니스 로직들을 하나하나 조합하여 만들어놓은 어떤 하나의 처리 등을 도와주는 패키지
Domain : 어떤 객체를 나누는데 있어서 그 객체의 특성을 가지는 것 또는 상수 객체, 엔티티 따위를 모아놓은 패키지
Repository : 도메인들을 통합 관리할 수 있도록 CRUD를 위한 DAO를 모아놓은 패키지
Console : 데이터의 입출력을 도와주는 패키지
...

 

클래스 나누기

 클래스를 나누는 기준은 명확한 듯하다.

그 객체가 어떤 행동과 어떤 특성을 가지는지에 따라 객체를 가른다. 그리고 패키지의 이름에 걸맞는 역할을 해주어야 한다.

또한, 컨벤션에 있어서도 객체 내부의 필드, 생성자, 메소드 의 순서를 지켜야 하며, 왠만해서는 삼항 연산자나 switch, else의 사용을 줄이고 if 문을 적절히 활용하여 가독성을 높이도록 하는 것이 좋다.

 

기능, 책임 분할

 책임과 기능을 분할하면, 디버그와 가독성이 매우 좋아진다.

이 때문에 각각의 함수가 하나의 기능만 하도록 하게끔 해야한다.

이를 꼭 명심하여 indent가 두 칸 넘어가지 않도록 한다.

이를 잘만 한다면 복잡한 문제 등에 있어서 쉽게 구현을 할 수 있다.

 

컨벤션

앞서 말했지만, 삼항연산자, 불필요한 if문과 반복적 사용, 한 줄에 너무 긴 코드 금지,

switch 금지, 카멜표기법을 사용하고, 커밋마다 자신만의 정해진 규칙을 정하여 변경된 기능들을 커밋 내용에 포함시킨다.

줄바꿈 또한 컨벤션 임을 잊지 말자. 줄바꿈을 너무 해도 서드파티가 보기에는 뭔가 싶을 수 있다.

 

테스트 작성

테스트는 오류를 잡는데 정말 중요한 요소이다.

JUnit5와 assertion 사용법을 잘 알아두는 것이 좋다.

또한 어떤 분이 Nested 내부에 한글 메소드가 포함되어 있으면 오류가 발생한다고 알려주셨다.

테스트를 쓸때 DisplayName을 적절히 써서 무슨 테스트인지 명시해주는 것이 좋으며,

다른 단위 테스트들에 대해서 같은 데이터를 쓰고 싶을때는 MethodSource를 참고하자.

 

Git 사용

.gitignore을 통한 파일 제외는 정말 중요한 것 같다.

mac이면 항상 finder의 파일을 찾는 용으로 .DS_Store라는 파일이 생성되는데,

꼭 삭제를 해주고 인터넷 서칭을 통해 ds_store 생성을 막도록 하자.

그리고 binary 파일들이 생성되는 폴더인 bin 폴더도 꼭 추가해주도록 하자.

 

클래스.of 의 immutable 오류

이것 때문에 애를 먹었다. Operation 관련 에러가 뜬다면 90퍼센트는 얘 때문인 걸로 보면 된다.

혹시 of가 사용되어 있는 부분에 문제가 있는지 보자.

내부적인 원소들에 대해 immutable하기 때문에 바꿀 수 없다.

 

 

 

또 많은데, 나중에 생각나면 계속 수정하면서 포스트를 업데이트 하겠다.