전제 조건

나는 지금의 회사에 들어간 지 이미 3개월이 되었다.
한 사람의 개발과는 다르다
팀원들에게 코드를 보게 하는 것을 의식하다
이제 소스 코드 관리가 필요합니다.
따라서 コミットの粒度は小さく나는 팀을 보여주는 것이 매우 중요하다는 것을 실감했다.

왜 소립도의 제출이 비교적 좋습니까?

큰 커밋보다 작은 커밋을 쉽게 볼 수 있음
변경된 부분도 이해하기 쉽기 때문이다.
또한 팀에게는
비교적 작은 변경은 코드를 볼 때의 심리적 부담을 줄일 수 있다.
다만, 이렇게 말해도小さい 이런 문제에 직면하게 된다.
(예외는 아니야, 나도)
이 문제는 コミットメッセージから考える를 통해 시원해졌다.

제출 메시지 고려

제출 메시지는 추가/수정만 적습니다.

스네크 박스를 카멜 박스로 추가 변환 처리

정규 표현식의 전역 옵션 수정

위에서 설명한 대로 설치하기 전에
이번 제출에서 추가/수정하고 싶은 정보를 고려해 보세요.
끝부터.
이 약속이 해야 할 일이 무엇인지 명확히 하다.
이렇게 하면 현재 제출과 무관한 기능을 추가할 수 있다
재구성하고 싶은 유혹에서 해방될 수 있을 것 같아서요.
또한 一つのことを書く 메시지를 제출하는 데도 중요하다.
예를 들어 AとBの機能を追加 이렇게 쓰는 것은 그다지 좋지 않다.
이 글은 제출 메시지의 작성법을 처리하지 않으니 아래의 내용을 참고하십시오.

참고문

Git 커밋 메시지 쓰기 방법

실천 승낙

나는 실제로 약속을 만들어 설명하고 싶다.

주 지점

master 분기에는 다음과 같은 코드가 있습니다.

const snakeToCamel = (str) => {
  const reg = /_([a-z])/;
  return str.replace(reg, (matched) => matched.slice(1).toUpperCase())
}

const camelToSnake = (str) => {
  console.log(str);
  const reg = /([A-Z])/;
  return str.replace(reg, (matched) => "_" + matched.toLowerCase())
}

export {
  snakeToCamel,
  camelToSnake
}

또한 String을 납품하면 낙타봉함과 Snek함을 자동으로 변환합니다
지원되지 않는 문제
상기 코드와 규격 변경을 감안하면 다음은 임무입니다.

정규 표현식 오류 수정

새로운 기능 추가

재구성

BAD

항상 안 좋은 약속.
여러 가지 일 (오류 수정, 기능 추가, 재구성 등)
약속에 포함되다.

+ const snakeReg = /_([a-z])/g;
+ const camelReg = /([A-Z])/g;

const snakeToCamel = (str) => {
- const reg = /_([a-z])/;
- return str.replace(reg, (matched) => matched.slice(1).toUpperCase())
+ return str.replace(snakeReg, (matched) => matched.slice(1).toUpperCase())
}

const camelToSnake = (str) => {
- console.log(str);
- const reg = /([A-Z])/;
- return str.replace(reg, (matched) => "_" + matched.toLowerCase())
+ return str.replace(camelReg, (matched) => "_" + matched.toLowerCase())
}

+ const convertSpelling = (str) => {
+   if(snakeReg.test(str)){
+     return snakeToCamel(str);
+   }

+   if(camelReg.test(str)){
+     return camelToSnake(str);
+   }
+   return str
+ }

export {
  snakeToCamel,
- camelToSnake
+ camelToSnake,
+ convertSpelling
}

왜 이렇게 여러 가지 일을 하겠다는 약속이 좋지 않을까요?

팀 사람들은 이 약속이 무엇을 했는지 알기 어렵다.

부작용이나 버그가 발생했을 때 원인을 알기 어렵다.

하나의 제출로 오류 수정과 기능 추가 등을 진행하면 원본 코드를 되돌리려고 할 때 등등 때로는 강등(오류 부활)된다.

기다리다
그래서 나는 가능한 한 작은 약속으로 하는 것이 좋다고 생각한다.

GOOD

여기서부터.
나는 제출 정보에서 여러 개로 나누고 싶다.

FIX

오류 수정은 오류 수정만 제출합니다.
쓸데없는 일을 하지 않고 바로 수정하여 적응하다.
팀도 제출을 볼 때 오류를 복구했다는 것을 쉽게 알 수 있다.
또 가능한 한 다른 오류가 발생할 가능성을 0으로 설정하여 개발하는 것이 좋다고 생각한다.
약속 메시지는 이런 느낌이에요.正規表現のグローバルオプションを修正

- const reg = /_([a-z])/;
+ const reg = /_([a-z])/g;

- const reg = /([A-Z])/;
+ const reg = /([A-Z])/g; 

추가 기능과 함께 개선 가능
새로운 기능이 필요하지 않으면 원상태로 회복합니다
오류가 다시 발생할 수 있습니다(다운그레이드).
따라서 一つのコミット 중一つのやったこと이 중요하다.

새로운 기능 추가

그리고 전달된 String이 낙타 상자인지 뱀 상자인지 검사합니다
제출, 변환할 작업 추가.
약속 메시지는 이런 느낌이에요.検出されたスペルによって変換する処理を追加

...
...
+ const convertSpelling = (str) => {
+   if(/_([a-z])/g.test(str)){
+     return snakeToCamel(str);
+   }

+   if(/([A-Z])/g.test(str)){
+     return camelToSnake(str);
+   }
+   return str
+ }

export {
-  snakeToCamel,
-  camelToSnake
+  convertSpelling
}

재구성

마지막은 콘솔.로그 삭제
반복적으로 사용하는 정규 표현식을 꺼내다.
약속 메시지는 이런 느낌이에요.snakeReg関連をリファクタリング

+ const snakeReg = /(_[a-z])/g;
+
const snakeToCamel = (str) => {
-  const reg = /_([a-z])/g;
-  return str.replace(reg, (matched) => matched.slice(1).toUpperCase())
+  return str.replace(snakeReg, (matched) => matched.slice(1).toUpperCase())
}
...
...
const convertSpelling = (str) => {
-  if(/_([a-z])/g.test(str)){
+  if(snakeReg.test(str)){
     return snakeToCamel(str);
   }
...
...

그다음에 이런 느낌이에요.camelReg関連をリファクタリング

const snakeReg = /(_[a-z])/g;
+ const camelReg = /([A-Z])/g;
...
...
const camelToSnake = (str) => {
-  console.log(str);
-  const reg = /([A-Z])/g;
-  return str.replace(reg, (matched) => "_" + matched.toLowerCase())
+  return str.replace(camelReg, (matched) => "_" + matched.toLowerCase())
}

const convertSpelling = (str) => {
...
...

-  if(/([A-Z])/g.test(str)){
+  if(camelReg.test(str)){
     return camelToSnake(str);
   }
...
...

전체 제출

camelReg関連をリファクタリング
snakeReg関連をリファクタリング
検出されたスペルによって変換する処理を追加
正規表現のグローバルオプションを修正

먼저 재구성하고 정규 표현식을 외부로 출력한 다음
나는 새로운 기능을 추가할 수 있다고 생각한다.
이 일대는 사람과 대열이 각각 다르다고 느낀다.

실천

나는 이전의 제출로 플루릭을 만들고 싶다.
운용 방법에 관하여 이 글은 처리하지 않는다.
플릭은 평론가에게 쉽게 볼 수 있다最小のやったこと프롤릭으로 쓰면 될 것 같아.
프롤릭의 제목 정보를 보면 이것最小のやったこと이 어떤 문제인지도 시원해진다.
방금 한 약속은 세 가지 일을 했다.

오류 수정

기능 추가

재구성

機能の追加과リファクタリング는 다르다
평론가에게는 쉽게 볼 수 있다最小のやったこと이렇게 생각하면 내가 총괄해 봐도 되겠지.
약속은 당연히 헤어지는 거야.
console.log, typo 수정, 요약 변수 삭제
만약 변경이 작다면 하나로 요약할 수 있다.
그러나 디렉터리 구조의 변경, 함수의 집합 등
대재구성最小のやったこと으로 성립
플루릭을 따로 만드는 게 좋을 것 같아.

BAD

아래의 플릭은 그다지 좋지 않다.

기능 추가 및 오류 수정

... 때문에

오류를 수정할 수 있어도 추가 기능이 오류를 발견했을 때 합병할 수 없으며 수정해야 한다

추가 기능이 필요하지 않을 때 오류 수정이 있어 닫을 수 없음

문제
이 점은 제출 부분에서도 통하는 부분이 있어요.

GOOD

이번 예에서는 다음과 같은 느낌으로 하는 것이 좋다.

정규 표현식 수정

캐러멜 박스와 스네크 박스의 추가 자동 변환 처리

오류 수정된 추출과 기능 추가 추출을 만듭니다.
따라서 즉시 반영해야 할 오류 수정 문제
문제가 없으면 보고 즉시 통합할 수 있습니다.
기능 추가 요청도 독립적이기 때문에
규격 변경 등이 있어도 다른 개발에는 지장이 없다.

참고문

더 좋은 당김 요청 힌트 10개
"거대한 요청 1개 vs 사소한 요청 100개" 고려(번역)
당김을 만드는 지점을 사용하고 싶을 때

총결산

종료 (메시지 제출 또는 요청 메시지) 부터
유혹에서 해방되다
나는 내가 가능한 한 작은 약속을 할 것이라고 생각한다.
끝까지 고마워요.
네가 댓글을 달아주면 나는 매우 기쁠 것이다.