Portfolio

(투표하고 갔으면 좋겠는 것) 함수 선언문 vs 함수 표현식 (둘 중 어떤걸 더 선호하시나요?)

(투표 요청)파일 네이밍 : 케밥 vs (파스칼+ 카멜), 만약 파스칼, 카멜이라면 각각 어느상황에서 사용할지

components, pages: 파스칼 케이스

hooks: 카멜 케이스 - use prefix

utils: 무슨 케이스? 가 좋을까요

api: 무슨 케이스? 가 좋을까요

types: 무슨 케이스? 가 좋을까요

camelCase! ~~kebab-case!~~

(제안)

컴포넌트 내부의 이벤트 핸들러를 작성할때는 handle로 시작하고


function App(){
	const handleClick = ()=>{}
	<button onClick={handleClick}></button>
}

상위 컴포넌트에서 받는 이벤트 핸들러는 on으로 시작하도록 하는게 어떨까요


function App(){
	const doAnything = () =>{}
	<Button onClick={doAnyThing}/>
}

function Button({onClick}){
  const handleClick = () =>{
    onClick && onClick()
	}
	<button onClick={handleClick}></button>
}

(확정) PR 코드양을 어느정도로 할지도 결정하면 좋을 것 같습니다. (ex. 300라인)

(확정) 브랜치 병합 전략 (의견1)

(논의 요청) 커뮤니케이션 비용을 줄이기 위한 Pn 룰을 적용하면 좋을 것 같습니다.

(확정) 전역 상수 파일(index.ts)을 사용합시다

(확정) 타입을 메인으로 사용하고, 클래스를 정의할 때(ex. 프로퍼티, 메서드) 인터페이스를 사용하는 건 어떨까요?

(완료) API 데이터 모델의 타입 정의가 필요할 것 같습니다. ⇒ API 타입 types 폴더에 복붙하기!

논의할점

브랜치 병합 전략

Merge

Squash and Merge

Rebase and Merge

참고: https://im-developer.tistory.com/182

여러 의견들

의견 1

feature → develop 머지 Squash & Merge가 유용하다. feature 브랜치에서 기능을 개발하기 위한 지저분한 커밋 내역을 하나의 커밋으로 묶어 develop 에 병합하면서, develop에는 기능 단위로 커밋이 추가되도록 정리할 수 있다.

또한 feature 브랜치는 develop 브랜치에 병합 후 제거하므로, Merge Commit 을 남길 필요가 없다.

+기능 별로 커밋을 묶기 위해서는 merge나 squash 사용하도록 권장하는 듯

develop → main 머지 main 브랜치는 지금까지 작업한 모든 기능을 배포할 때 병합한다. develop 브랜치를 squash & merge 하게 되면 커밋 이력이 모두 사라져, 특정 기능에서 문제가 생겼을 때 롤백할 수 없게된다. main 브랜치 또한 Merge Commit 을 남길 필요 없다. 따라서 Rebase & Merge 가 적합하다.

의견 2

팀이 실력이 아직 부족하다 느끼면, 이제 막 git으로 버전관리하는 법을 배우기 시작했다면 Squash and Merge가 좋을 겁니다.

(정동환) 개인적으로는 의견 1이 괜찮다고 보는데 2도 상관없슴다

투표함

논의할점