728x90
프로그램 개발 규칙
- Package 명
- 모두 소문자로 작성한다
- Class 명
- 대문자로 시작하는 파스칼 케이스로 작성한다.
- 예시 : ExampleClass.java
- 대문자로 시작하는 파스칼 케이스로 작성한다.
- Method 명
- 소문자로 시작하는 카멜 케이스로 작성한다
- 예시 : exampleMethod()
- 소문자로 시작하는 카멜 케이스로 작성한다
- Mapping 명
- 매핑명은 소문자를 사용한다
- 문자가 길어져 단어가 나뉠 경우 하이픈(-)을 사용한다
- Exception 발생에 따른 처리
- try catch에 대해서
- try catch는 최대한 지양해라
- 에러가 발생할 경우 그 흐름을 끊어야 함이 당연하다
- 사용하고자 한다면 구체적인 에러가 발생하도록 코드를 추가하라
- try catch에 대해서
- Map 사용의 지양
- 객체를 유연하게 처리하기 위해 Map을 사용하지만,
Map은 <Key, Value>로 이루어져 있기 때문에 어떠한 데이터가 들어갔는지? 들어있는지?에 대해서 런타임시 정확히 알 수 있다.
처음에는 개발하기 쉬워도 이후에는 본인은 물론이고 다른 개발자 또한 개발하는데 애로사항이 발생한다.
- 객체를 유연하게 처리하기 위해 Map을 사용하지만,
- 메소드 기능별 분할
- 무분별한 기능의 분할은 코드의 가독성을 떨어뜨린다.
- 최대한 하나의 메소드는 '한가지'의 기능을 구현하는 것이 좋다.
- 만약 하나의 메소드가
1번 기능도 구현하고,
2번 기능도 구현하고,
3번 기능 ....
모든 기능을 구현하는 로직이 형성되어 있을 경우
가독성도 떨어지고 해당 메소드의 의미가 퇴색된다.
- 만약 하나의 메소드가
- 어떻게 하는 것이 가장 좋을까?
a와 b를 적재 적소에 사용하는 것이 중요하겠다.
결론적으로 코드를 작성하는 개발자의 센스일 뿐
- DTO 작성
- toString() 작성
- 일부의 데이터만 표현하지 말고 모든 데이터를 보여주는 용도로 사용하자
- override 할 때, Lombok을 사용하면 깔끔하게 재정의가 가능하다
- @toString()
- @builder 사용
- builder 를 사용할 경우 실제 가독성이 올라가고 불필요한 다양한 생성자 생성을 방지할 수 있다.
- toString() 작성
- IoC의 올바른 DI( Dependency Injection ) 의존성 주입 방법
- 스프링에서는 생성자 주입 방법을 권장하고 있다.
- 생성자 주입
@Controller class ExampleController{ // final로 선언해야 한다. private final ExampleService exampleService; // 단일 생성자일 경우 스프링에서 자동으로 생성자 주입을 해준다. public ExampleCalss(ExampleService exampleService){ this.exampleService = exampleService; } }
- 필드 주입
@Controller class ExampleController{ @Autowired private ExampleService exampleService; }
- 수정자 주입
@Controller class ExampleController{ private ExampleService exampleService; @Autowired public void setExampleService(ExampleService exampleService){ this.exampleService = exampleService; } }
- 스프링에서는 생성자 주입 방법을 권장하고 있다.
- 테스트 코드의 작성
- 테스트 코드에만 사용하는 기능이 있을 경우 실제 운영되는 로직과 분리하여 관리 할 수 있도록 하자
- 클래스명, 메소드명, 변수명 명칭 작성 할 때의 나의 규칙
- 개발자에 따라 이 부분에서는 다를 수 있다.
하지만 나의 관점으로 볼 때 명칭이란, 읽었을 때 누구나 알 수 있도록 줄임말을 사용하지 않아야 한다고 생각한다.
예를들어 authority → auth 또는 parkingLot → park
위와 같이 줄임말이란 편할 수도 있지만 추후 혼동이 발생 할 수 있다.
줄임말은 꼭 사용해야 하는 경우에만 사용하자
- 개발자에 따라 이 부분에서는 다를 수 있다.
- Null 체크는 다음과 같이 하자
if( User.getName() ≠ null ) {} ---> (x) User.getName이 null일 경우 NullPointerException이 발생한다. if( null != User.getName() ) {} ---> (o) 이래야 null 체크가 정상적으로 가능하다. 또는 java에서 지원하는 기능을 이용해 확인하자 Objects.isNull or StringUtils.isEmpty
- Mybatis를 사용 할 경우
- alias 즉 별칭을 꼭 작성해서 어디의 컬럼을 사용하는 것인지 확실히 인지될 수 있도록 하자 동일한 컬럼이 많이 존재 할 경우 추후 혼동이 발생한다.
SELECT DK.id, PP.name, PP.id FROM discount_key AS DK JOIN parkinglot_product AS PP .....
- DAO를 작성 할 때는 어떤 동작을 하는지 명시 되도록 동사를 포함하여 작성하는 것이 이롭다.
- modifyStoreName() {}
- addUser() {}
- deleteProduct() {}
- 데이터의 확인 Validation
- Front-End에서 아무리 null check , 제한 사항 체크 등등 철저히 하였어도
- Back-End는 Controller에 Request 값이 들어온 이상 한번 더 철저히 확인해야 한다.
- 추가적으로 Database에서 가져온 값도 포함이다.
어느누가 null값을 넣어 놓았을지? 잘못된 값을 넣어 놓았을지 어떻게 아는가?
- 추가적으로 Database에서 가져온 값도 포함이다.
- 개발을 할 때 어떤 사항을 고려해야 하나?
- 가독성은 중요하다.
- 프레임워크에 기능에 맞게 활용해서 개발하자 스프링을 사용하면 당연하게도 스프링에 대해 알아야 활용하고 효율적인 개발이 가능하다.
- 사용자를 가르치지 않아도 사용이 가능한 프로그램을 개발해야 한다.
- 무언가를 개발하며
아... 이건 이거 때문에 안돼, 저건 저거 때문에 안돼 라고 하지만
그냥 편하게 개발하고 싶을 뿐이었다, 좀 더... 아니 조금만 더 많이 생각해보면 해결 가능 하더라.
모든 방도를 생각해서 정석대로 하려 하자. - 어떤 문제가 발생했을 때 정확한 이유가 무엇인지 본질을 파악하려 노력하자.
728x90
'Etc > Etc' 카테고리의 다른 글
Nvidia Cuda 설치 (0) | 2022.08.14 |
---|---|
파일질라(filezilla) sftp 연결 방법 (0) | 2022.02.13 |
에러, web http 상태 500 - 내부 서버 오류 속성 이름은 반드시 whitespace 다음에 나타나야 합니다... (0) | 2021.03.20 |
eclipse whitespace , 이클립스 화면 줄표시 (0) | 2021.03.17 |
cmder git E325 Error ,Found a swap file by the name ... (0) | 2021.02.21 |