작은 변화를 만들어 테스트하고 나쁜 습관을“헹구고 반복”하는가?

나는 수년간의 경험을 가진 프로그래머입니다. 나는 습관이 있다는 것을 깨달았습니다. 그것이 실제로 나쁜 습관인지 아닌지 잘 모르겠습니다.

솔루션을 위해 수행해야 할 작업 목록, 예를 들어 작은 작업도 포함됩니다.

1. 이 사용자 컨트롤의 리소스 변경
2. 다른 크기 변경
3. 다른 사용자 정의 컨트롤에 HTML 및 코딩 추가

이 모든 작업은 작습니다. 나는 그들이 10 분 안에 할 수 있음을 의미 하지만 , 약간의 변경을 한 다음 웹 브라우저에서 반복해서 테스트하는 나쁜 습관이 있습니다. 이것이 좋은 습관입니까?

아니면 한 번에 모두 수행 한 다음 함께 테스트해야합니까?

그것이 실제로 나쁜 습관이라면 작은 변화를 반복해서 테스트하는 데 시간을 낭비하는 느낌이 들기 때문에 어떻게 교정해야합니까?

• 좋은 습관입니다.
• 당신은 과학적인 방법을 따르고 있습니다.
• 테스트하기 전에 몇 가지 사항을 변경하면 사전 조건을 준비하기가 어려워지고 다른 변경 사항이 예상치 못한 방식으로 서로 상호 작용할 수 있기 때문에 각각의 테스트가 더 어려워지고 아마도 신뢰할 수 없습니다.
• 지금 당신이 "낭비" 한다고 느끼는 순간 , 당신은 나중에 intregration, 테스트 및 유지 보수 단계에서 회복 될 것입니다.
• 잘 했어.

약간의 변경을하고 각각을 테스트하는 것은 나쁜 것이 아닙니다. 각 변경의 효과를 확인할 수 있으며 한 변경으로 문제가 발생하면 어떤 변경으로 인해 문제가 발생 했는지 가장 쉽게 알 수 있습니다!

10 개의 항목이있는 작업 목록이 있고 모든 항목을 한 번에 수행 한 다음 페이지를 테스트 한 다음 페이지가 잘못 표시되는 것을 확인하면 페이지 를 변경 한 변경 내용 을 파악하기가 더 어려울 수 있습니다 .

물론,이 접근법을 극단적으로 취할 수도 있습니다. 균형을 찾는 것이 핵심이며, 그것은 더 나은 이해를 얻고 함께 제공 무엇을 당신이 변화하고 있고 변화가 서로 영향을 줄 수있는 방법을.

귀하의 질문에는 두 부분이 있습니다.

1. 모두 한 번 수행 한 다음 함께 테스트해야합니까?

   VCS를 사용한다고 가정합니다 .
   그리고 어떤 작업이 수행되었는지 추적하려면 작업 목록을 커밋 목록에 배포하는 것이 좋습니다. 하나의 작업, 하나의 커밋 .

   따라서 현재 코드베이스의 다른 버전을 쉽게 관리 할 수 ​​있습니다. 이전 상태로 되돌릴 수 있고 주 트렁크에 들어 가려는 변경 사항을 체리 픽 선택 등

   대답은 명확합니다.

   아니요, 한 번에 하나씩 만 커밋을 변경하십시오 .

2. 그러나 작은 작은 변경을 한 다음 웹 브라우저에서 반복해서 테스트하는 나쁜 습관이 있었습니까?

   무엇이든 코드 / UI를 테스트하는 것이 좋지만 브라우저에서 반복해서 수행하는 것은 말이되지 않습니다. 자동으로 수행 할 수있는 도구가 있습니다 ( Selenium, PhantomJS / Casper, ZombieJS )

   이 경우에 대한 답변은 다음과 같습니다.

   예, 소프트웨어를 두 번 이상 테스트하는 것이 좋지만 자동화를 사용하는 것이 좋습니다

개발자의 습관에는 두 가지 주요 질문이 있습니다.

1. 코드의 품질에 어떤 영향을 미칩니 까?
2. 생산성에 어떤 영향을 미칩니 까?

두 가지 모두에 대한 답이 "더 나아진다"라면 습관을 없애고 다른 사람들에게 가르쳐주십시오!
하나에 대한 대답이 "더 나은"이고 다른 하나는 "말"인 경우-그것은 스타일이며 당신은 그것에 대해 의식해야합니다. 항상 적용 가능한 것은 아니며, 때때로 그것을 억제하기 위해 노력해야 할 수도 있습니다.
둘 다에 대한 답변이 "부정적"인 경우 심각한 문제가있는 것입니다.

물론 처음 두 가지 경우에 대해서도 "긍정적 인 효과가 어떻게 자동화되거나 제도화 될 수 있습니까?"에 대해 생각해야합니다. 매번 다른 브라우저를 사용해 보는 것보다 테스트를 작성하는 것이 더 낫습니까? (웹 개발에서 적절한 레이아웃을 테스트하는 것이 쉽지 않다는 것을 알고 있습니다. 이것이 항상 가능하거나 가치가 있다고 말하는 것은 아닙니다.)

이 경우 품질이 향상되고 생산성 이 저하 될 수 있습니다 . 작은 변경의 경우, 특히 변경 사항이 서로 관련이있는 경우 다소 나쁠 수 있습니다. 최종 결과도 테스트하는 한 ( "각 모듈이 테스트되어 작동하므로 테스트 할 필요가 없습니다!").

따라서 근무일의 90 %가 실제로 약간의 변화를 겪지 않는다면 아주 좋은 습관입니다. 근무일이 이와 같은 경우 작업 스타일 (또는 작업장)을 검토 할 수 있습니다.

이것은 도메인에 따라 다릅니다. 웹 페이지를 배치하면 정상적으로 작동하고 즉각적인 피드백을 얻을 수 있습니다 (브라우저에서 직접 할 수도 있습니다!). 마찬가지로 초기화하는 데 오랜 시간이 걸리지 않는 모든 경우에 잘 작동합니다. 이는 정신적 워크로드를 낮게 유지하고 실수 가능성을 줄이기 때문에 선호됩니다.

그러나 코드를 컴파일해야하고 시간이 몇 분이 걸리지 않는 대규모 프로젝트의 경우 다운 타임이 많이 발생할 수 있으므로 다음을 자주 사용해야합니다.

• 작업 흐름을 "병렬화"(예 : 여러 빌드에서 동시에 작업) 또는
• 한 번에 가능한 많은 작업을 수행하거나
• 작은 독립적 인 부분을 만들어 나중에 작업하고 더 큰 프로젝트에 통합합니다.

(아마도 다른 방법이있을 수 있습니다.)

다른 사람들이 말했듯이, 이것은 분명히 나쁜 습관이 아닙니다 . 일반적으로 한 번에 몇 가지만 수정하는 것이 좋습니다. 유일한 예외는 서로에게 영향을 미치지 않는 많은 변경 목록이있는 경우입니다 (예 : 작은 스타일 또는 복사 변경, 다른 페이지의 변경 등). 레이아웃을 수정하는 경우 한 번에 하나씩 변경하여 다음 문제로 넘어 가기 전에 지원되는 모든 브라우저에서 모든 것이 100 %인지 확인할 수 있습니다.