문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2019/03/31 13:53] kwon37xi [Database / 저장소] |
web:신규서비스 [2020/03/17 11:37] kwon37xi [기타] |
||
---|---|---|---|
줄 22: | 줄 22: | ||
* 또한 서로 다른팀간의 연동을 할 때, 변수, 메소드, 클래스 이름등이 너무 많이 달라서 이들간의 연동을 할 때 혼란이 매우 커진다. | * 또한 서로 다른팀간의 연동을 할 때, 변수, 메소드, 클래스 이름등이 너무 많이 달라서 이들간의 연동을 할 때 혼란이 매우 커진다. | ||
* 프로젝트를 시작할 때 **한국어 용어, 그에 대응하는 영어 단어(이를 사용해서 클래스, | * 프로젝트를 시작할 때 **한국어 용어, 그에 대응하는 영어 단어(이를 사용해서 클래스, | ||
+ | * 프로젝트 이름을 nickname 으로 만들지 말것. 프로젝트에 대해 직관적인 이름으로 짓지 않으면 다른 팀/신규 입사자와 소통할 때 매번 설명이 필요해진다. | ||
===== 영웅 의존 금지 ===== | ===== 영웅 의존 금지 ===== | ||
* 프로그래밍 언어 선택에 이어지는 것인데, 비즈니스의 핵심이 아닌 영역에 대해 영웅 한 두명에 의존하게 시스템을 구성하면 안된다. | * 프로그래밍 언어 선택에 이어지는 것인데, 비즈니스의 핵심이 아닌 영역에 대해 영웅 한 두명에 의존하게 시스템을 구성하면 안된다. | ||
줄 165: | 줄 165: | ||
* 대체로 **PK asc**를 하는게 DB에서 가장 성능이 좋다. [[https:// | * 대체로 **PK asc**를 하는게 DB에서 가장 성능이 좋다. [[https:// | ||
* offset/ | * offset/ | ||
+ | * 사용자 ID 같은 경우에는 소문자로통일해서 받는것이 좋다. 대문자로 입력해도 소문자로 변환한다. 사용자는 자신이 대소문자를 어떻게 입력했는지 혼동하는 경우가 많다. 단 email 같은 외부 값을 받는 경우는 있는 그대로 넣어야 한다. | ||
===== 사용자에게 전달하는 메시징 솔루션 ===== | ===== 사용자에게 전달하는 메시징 솔루션 ===== | ||
* Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | ||
줄 293: | 줄 294: | ||
* 호출자 서비스 이름 | * 호출자 서비스 이름 | ||
* 호출자 서비스의 구체적 기능(컨트롤러 이름이나 배치 이름 등) | * 호출자 서비스의 구체적 기능(컨트롤러 이름이나 배치 이름 등) | ||
+ | * 인증의 역할 | ||
* 수정/ | * 수정/ | ||
* 다른 API를 호출한 결과는 항상 값이 null 일 수도 있다고 간주한다. | * 다른 API를 호출한 결과는 항상 값이 null 일 수도 있다고 간주한다. | ||
줄 309: | 줄 311: | ||
* 관리툴은 내부 관리자들만 사용하기 때문에 개발자들이 대충만드는 경향을 보이는데 여기에 SPA를 적용하면 UX가 형편없어져서 굉장히 불편해진다. | * 관리툴은 내부 관리자들만 사용하기 때문에 개발자들이 대충만드는 경향을 보이는데 여기에 SPA를 적용하면 UX가 형편없어져서 굉장히 불편해진다. | ||
* 관리툴은 최대한 단순함을 유지하는 것이 낫다. | * 관리툴은 최대한 단순함을 유지하는 것이 낫다. | ||
+ | |||
+ | ===== 예외 ===== | ||
+ | * 예외(Exception)에 해당 예외의 근본 원인을 찾알 수 있는 정확한 정보를 남겨준다. 예를들어 사용자의 전화번호가 잘못된 포맷으로 입력되었다면, | ||
+ | * 예외는 먹는게 아니다. | ||
+ | * 예외 메시지를 UI 에 노출하는 경우가 있는데, 여기에 너무 많은 메시지를 주면 불필요하게 시스템의 보안 이슈가 될 수도 있다. 따라서 UI 노출용 메시지와 로깅용 예외 메시지를 분할하는게 좋다. | ||
+ | * API나 Web 애플리케이션의 경우 예외 발생을 적절한 JSON + HTTP Code 로 변환해주는 예외 핸들러를 두는 것이 좋다. 자동으로 예외가 JSON 으로 변환되 나가도록 하며 그 때, UI 노출용 예외 메시지도 함께 준다. ([[springframework: | ||
===== 기타 ===== | ===== 기타 ===== | ||
줄 315: | 줄 323: | ||
* 가급적, 밀리초까지 포함한다. 초까지만 지정하면 추후에 밀리초를 사용할 일이 생겼을 때 매우 당황스러워질 수 있다. | * 가급적, 밀리초까지 포함한다. 초까지만 지정하면 추후에 밀리초를 사용할 일이 생겼을 때 매우 당황스러워질 수 있다. | ||
* 네트워크 연결 되는 설정의 경우 **Connection Timeout과 Read Timeout** 두 가지가 존재한다. 항상 이 둘을 적절히 설정해야 한다. | * 네트워크 연결 되는 설정의 경우 **Connection Timeout과 Read Timeout** 두 가지가 존재한다. 항상 이 둘을 적절히 설정해야 한다. | ||
- | * 예외(Exception)에 해당 예외의 근본 원인을 찾알 수 있는 정확한 정보를 남겨준다. 예를들어 사용자의 전화번호가 잘못된 포맷으로 입력되었다면, | ||
* UI 에 페이징을 사용하지 않는 것이 좋다. 페이징은 전체 결과 갯수를 필요로 하는데 이로 인해 DB 부하가 매우 크다. [[search: | * UI 에 페이징을 사용하지 않는 것이 좋다. 페이징은 전체 결과 갯수를 필요로 하는데 이로 인해 DB 부하가 매우 크다. [[search: | ||
+ | |||
===== 전사 가이드 ===== | ===== 전사 가이드 ===== | ||
* 신규 서비스 런칭/ | * 신규 서비스 런칭/ |