📝SVN, GIT 커밋
──── 제목 ────
─ Body
# ✨feat : 기능 (새로운 기능)
# 🐛fix : 버그 (버그 수정)
# 📝docs : 문서 (문서 추가, 수정, 삭제)
# 🎨style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# ♻️refactor : 리팩토링
# ✅test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# 🔨chore : 기타 변경사항 (빌드 스크립트 수정 등)
# 이모지 참조 > https://gitmoji.dev/
─ Footer
# 이슈번호
# 무엇을 수정했는지
# 왜 수정했는지
🔗 참고 및 출처
https://hyeonsook95.github.io/2021/08/16/git-commit/
for (int i = 0; i < fruits.size(); i++)
→ for (int fruitIndexNum = 0; fruitIndexNum < fruits.size(); fruitIndexNum++)하지만 그 자체로 이해가 되는 수준의 코드면 굳이 할 필요는 없다 → 유연하게 처리
return fruits.size() + vegitables.size();
→ int totalFruits = fruits.size()
int totalVegitables = vegitables.size()
int totalCount = totalFruits + totalVegitables
return totalCount하지만 그 자체로 이해가 되는 수준의 코드면 굳이 코드를 늘릴 필요는 없다 → 유연하게 처리
int totalFruits = fruits.size() // 과일 총 개수
/** ──── 오늘 산 과일과 야채의 총 개수 구하기 ──── **/
int totalFruits = fruits.size()
int totalVegitables = vegitables.size()
int totalCount = totalFruits + totalVegitables
return totalCount
<HTML>
<body>
<div>테이블</div>
/** 과일 테이블 **/
<table>
...
</table>
</body>
</HTML>
class name의 경우 BEM Naming Convention을 사용한다고 한다
블록(B), 블록 내부 요소(E) 수정자인 스타일 변경(M) → button__icon--large
근데 BEM은 점점 늘어날 수록 헷갈려 보이기 때문에 개인적으로는 kebab-case가 더 나아보인다
/** ──── Fetch Data ──── */
/** ──── 상태관리 함수 ──── */
/** ──── 상태관리 ──── */
/** ──── PAGE ──── */
| [공통개발] SVN, Git 주석 달기 (0) | 2024.03.24 |
|---|---|
| [공통개발] 나만의 Clean Code (0) | 2024.03.21 |
| [공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리) (0) | 2024.01.24 |
| [공통개발] 개발 프로세스 (분석 / 설계 / 협업 / 개발 / 테스트 / 배포) (0) | 2023.09.27 |
| [공통개발] Java 자바 Naming Convention (네이밍 컨벤션), JavaDoc (함수 및 클래스 문서), Swagger (API 문서) (0) | 2022.08.01 |
나만의 주석 예시
/** ──── 상태관리 함수 ────**/
/** ──── Query & Mutation ────**/
/** ──── 상태관리 ────**/
/** ──── 이미 등록된 키워드인지 체크 ──── **/ (필요한 경우)
/** ──── TSX ────**/
{/*──── 선택 키워드 ────*/}
등...
Code-Map
export enum Code {
/** ─── 상태 ─── **/
WEAK = 'WEAK', // '약함',
NORMAL = 'NORMAL', // '보통',
STRONG = 'STRONG', // '강함,
}
type CodeMap = {
[key in Code]: string;
};
export const CODE_MAP: CodeMap = {
[Code.WEAK]: '약함',
[Code.NORMAL]: '보통',
[Code.STRONG]: '강함',
}백엔드에서 코드로 내려온 경우 한글로 변환시키는 Mapping을 만들어두고 한 곳에서 관리하면 좋다
프로젝트 구조 (Next + 개인화) [redux + graphql]
src
├ components
│ ├ common
│ └ button.tsx
│ └ dashboard
│ └ pie-chart.tsx
├ config
├ constant
│ └ date-time-constant.ts
├ enums
│ └ code-map.enum.ts
├ assets
│ └ dog.png
├ gql
│ └ dashboard
│ ├ mutations.graphql
│ └ query.graphql
├ hooks
│ └ use-intersection-observer.ts
├ libs
│ └ utils.ts
└ redux
├ slices
├ └ modal-slice.ts
├ reducer.ts
└ store.ts
React 프로젝트 구조 (개인화) [redux 사용]
src
├ components
│ ├ common
│ │ └ button.tsx
│ └ dashboard
│ └ pie-chart.tsx
├ config
├ constant
│ └ date-time-constant.ts
├ enums
│ └ code-map.enum.ts
├ assets
│ └ dashboard
│ └ dog.png
├ config
├ services
│ └ dashboard
├ styles
│ └ dashboard
│ └ table.css
├ hooks
│ └ use-intersection-observer.ts
├ utils
│ └ utils.ts
└ redux
├ slices
├ └ modal-slice.ts
├ reducer.ts
└ store.ts
프로젝트 구조의 정답은 없다 React의 경우 feature으로 분리하는 방식을 많이 이야기한다 이걸 사용하면 ToDo 기능, 인증 등으로 기능별로 분리할 수 있다 feature/ToDo안에 ToDo관련 components, ToDo.tsx, css 등 관련된 걸 다 넣는다 이럴 경우 기능별로 딱 깔끔하게 되겠지만 양이 엄청 많아질 거고 A라는 페이지에서 쓰는 ToDo랑 B라는 페이지에서 쓰는 ToDo가 살짝 다를 수도 있다 특징별로 분리한 건 어떤 기능이 있는지 확인하고 기능별로 분리가 철저해 보이지만 실제 프로젝트를 하면 재활용성을 완벽하게 하는 경우가 그렇게 많지 않다
그럴바에 그냥 DDD구조처럼 중복되더라도 (Auth같이 무조건 공통인 경우는 따로 분리 필요) 살짝 달라서 안에서 분기태우고 이럴바에야 그냥 또 다른 이름으로 제대로 만드는게 좋아보인다
또한 업무도 페이지의 어떤 영역을 맡게 될테고 백엔드도 DDD구조로 가면 프론트에서도 찾기 쉽게 DDD로 가져가는게 프로젝트 이해와 해당 페이지를 찾는게 더 쉬워보인다 그래서 개인적으로는 DDD의 구조를 가져가는게 좋아보인다
→ 물론 프론트랑 백엔드랑 확실히 구분되어있어서 프론트는 백엔드 프로젝트를 볼 일이 없을 경우는 제
물론 회사 프로젝트에서 이미 진행되고 있는 구조가 있다면 그렇게 따라가는 게 맞다
만약 이런 룰을 명확하게 하고 싶다면 프레임워크를 이용하면 된다 (Next.js)
🔗 참고 및 출처
| [공통개발] 나만의 Clean Code (0) | 2024.03.21 |
|---|---|
| [공통개발] HTML, CSS(BEN Naming Convention), JavaScript Naming Convention (네이밍 컨벤션) (0) | 2024.03.21 |
| [공통개발] 개발 프로세스 (분석 / 설계 / 협업 / 개발 / 테스트 / 배포) (0) | 2023.09.27 |
| [공통개발] Java 자바 Naming Convention (네이밍 컨벤션), JavaDoc (함수 및 클래스 문서), Swagger (API 문서) (0) | 2022.08.01 |
| [공통개발] API 생성 팁 (0) | 2022.06.27 |
제품을 만들 때 현재 이와 비슷한 제품은 없는 지 어떠한 서비스가 있고 어떤 자료를 수집해야할지 등에 대한 요구사항 및 분석의 단계이다
요구사항을 토대로 우선순위, 마일스톤, 개발에 필요한 환경 구축 등을 한다
🔗 참고 및 출처
https://imgscf.slidemembers.com/
https://www.edrawsoft.com/kr/program-review/architecture-drawing-program.html
https://www.erdcloud.com/d/TzHsgqxPRGzWGzytR
https://brunch.co.kr/@junovoir/26
https://salmon-kim.tistory.com/25
https://carrotdesign.tistory.com/entry/UXUI-%EA%B8%B0%ED%9A%8D-11%EA%B0%95
https://deep-wide-studio.tistory.com/37
https://m.blog.naver.com/sslim21/221443489759
https://www.marimba.team/kr/blog/task-management-using-backlog/
| [공통개발] HTML, CSS(BEN Naming Convention), JavaScript Naming Convention (네이밍 컨벤션) (0) | 2024.03.21 |
|---|---|
| [공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리) (0) | 2024.01.24 |
| [공통개발] Java 자바 Naming Convention (네이밍 컨벤션), JavaDoc (함수 및 클래스 문서), Swagger (API 문서) (0) | 2022.08.01 |
| [공통개발] API 생성 팁 (0) | 2022.06.27 |
| [공통개발] 로그 생성 팁 (Custom Logging) (0) | 2022.06.27 |
솔직히 모든 Naming Convention을 세세한 것까지 지키면서 한 사람이 작성한 것처럼 보이기는 쉽지 않다 하지만 아무리 그래도 위에 정한 큰 틀은 지키는게 좋다
JavaDoc은 JDK와 함께 패키지로 제공되는 도구로 Java소스 코드의 코드 문서를 생성하는데 도움을 주는 도구로 JDK기본적 + 공식적으로 지원하기 때문에 이용하는게 좋다 → 일단 사용해봐야 알 거 같음
백엔드에서 쓰이는 경우 API문서의 경우 Swagger로 작성하고 공통 메소드나 그 외의 클래스의 경우는 JavaDoc으로 작성하는게 좋아보인다 → 일단 사용해봐야 알 거 같음
| [공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리) (0) | 2024.01.24 |
|---|---|
| [공통개발] 개발 프로세스 (분석 / 설계 / 협업 / 개발 / 테스트 / 배포) (0) | 2023.09.27 |
| [공통개발] API 생성 팁 (0) | 2022.06.27 |
| [공통개발] 로그 생성 팁 (Custom Logging) (0) | 2022.06.27 |
| [공통개발] 개발 더 잘하는 방법 [나만의 팁] [추가중] (0) | 2021.10.11 |
| [공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리) (0) | 2024.01.24 |
|---|---|
| [공통개발] 개발 프로세스 (분석 / 설계 / 협업 / 개발 / 테스트 / 배포) (0) | 2023.09.27 |
| [공통개발] Java 자바 Naming Convention (네이밍 컨벤션), JavaDoc (함수 및 클래스 문서), Swagger (API 문서) (0) | 2022.08.01 |
| [공통개발] 로그 생성 팁 (Custom Logging) (0) | 2022.06.27 |
| [공통개발] 개발 더 잘하는 방법 [나만의 팁] [추가중] (0) | 2021.10.11 |
// 로그 시각
Date today = new Date();
SimpleDateFormat todayDate = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
String getMembmerQuery = "select * from member where id='1'"
"["+ todayDate + "] " + "get_member_query : " + getMemberQuery
예시) [2022-07-17 12:43:22] get_member_query : select * from member where id='1'| [공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리) (0) | 2024.01.24 |
|---|---|
| [공통개발] 개발 프로세스 (분석 / 설계 / 협업 / 개발 / 테스트 / 배포) (0) | 2023.09.27 |
| [공통개발] Java 자바 Naming Convention (네이밍 컨벤션), JavaDoc (함수 및 클래스 문서), Swagger (API 문서) (0) | 2022.08.01 |
| [공통개발] API 생성 팁 (0) | 2022.06.27 |
| [공통개발] 개발 더 잘하는 방법 [나만의 팁] [추가중] (0) | 2021.10.11 |
| [공통개발] [Next.js] [React] Naming Convention (네이밍 컨벤션), 프로젝트 구조, Code-Map (코드 한글 변환, 프론트 코드 관리) (0) | 2024.01.24 |
|---|---|
| [공통개발] 개발 프로세스 (분석 / 설계 / 협업 / 개발 / 테스트 / 배포) (0) | 2023.09.27 |
| [공통개발] Java 자바 Naming Convention (네이밍 컨벤션), JavaDoc (함수 및 클래스 문서), Swagger (API 문서) (0) | 2022.08.01 |
| [공통개발] API 생성 팁 (0) | 2022.06.27 |
| [공통개발] 로그 생성 팁 (Custom Logging) (0) | 2022.06.27 |