단계적으로 요구를 제기하여 평론을 더욱 쉽게 하자!

하나의 기능을 실시할 때 제시한 요구를 분리함으로써 관중의 부담을 줄이자는 제안을 했다.
다음 그림의 그림입니다.

배경.

적당한 입도로 요구를 분할할 수 있었으면 좋겠어요. 그래서 일부러 이렇게 빙빙 돌리지 말고 기본적으로 마스터분지의 형식으로 적당히 요구를 하면 돼요.
그림에서 보듯이 UI를 설치할 때만 마스터에 병합된 후 이상 상태의 코드가 발표되어 오류가 발생할 수 있습니다. 이 경우 인용 요청을 활용하는 것이 좋습니다.
depro를 할 수 있는 단위로 마스터에 통합하고 싶지만,pull 요청을 적당히 분할하고 싶습니다.
어느 개발 현장에서나 일어날 수 있는 상당히 보편적인 문제라고 생각했는데 찾아보니 이번처럼 구체적인 수법은 거의 보이지 않았다.
나는 이것이 틀림없이 이미 누군가가 하고 있을 거라고 생각했다...
그냥 저는 몰랐어요.

이 방법에 대한 명칭

보다 지능적인 방법

"우리 집은 이렇게 하는데 느낌이 좋아요!"

이런 정보가 있으면 꼭 알려주세요!

해봤어요.

아직 시도하는 단계입니다.
단 한 번은 이 흐름에 따라 제안됐지만, 시청자들로부터 "편하게 할 수 있어서 너무 좋다"는 말을 받았다.
또 이 방안이 처음에는 공제출이었기 때문에 이 WIP 모델과 결합해 수법을 제시했다.
Workin Progress 모드를 기반으로 Pull Request 개발 프로세스 활용

조사해 보았다

나는 이런 방법이 이미 사회에 출현한 것을 조사한 적이 있는 필기를 미리 쓸 것이다.

참조 1

'거대한 수법 하나 vs 작은 수법 하나 100가지'고민(번역)
10 lines of code = 10 issues.
500 lines of code = "looks fine."
Code reviews.
기사에서 ↑는 이쪽 트윗을 인용했는데, 저도 그런 경험이 있었고, 이런 일이 일어나지 않도록 최대한 큰 요구를 피하려고 했습니다.
구체적으로 다음과 같은 방법이 쓰여 있다.

초기 및 자주

입도 감소

작업 범위 축소

위의 그림에서 보듯이 ui와api의 작용 범위를 분할하면 평론을 하기 쉽고 분할된 신축 가능한 입도도 작아진다.

참조 2

왜 Pull Request 안 읽어줘요?
문장에 쓰여 있다Issueの単位とPRの単位は違う.
엄청난 파동치를 줄이기 위한 좋은 생각이라고 생각해요.
나는 항상 모호하게 그래야 한다고 생각하지만, 문화를 잘 파악하는 것이 중요하다고 생각한다.
자세한 방법은 제 시나리오와 다르지만 아마 같은 방법일 거예요.

총결산

거대한 포스터는 평론하기 어렵다