프로그래밍하는 동안 얼마나 자주 코드를 실행하고 테스트합니까? [닫은]

특히 C로 처음부터 새 코드를 작성할 때 가끔 문법 검사를 제외하고 컴파일러를 실행하지 않고 몇 시간, 심지어 며칠 동안 코드를 작성하는 것을 발견했습니다.

나는 더 큰 코드 덩어리를 신중하게 작성하고 코드가 내 머리 속의 흐름을 분석하여해야 할 일을 수행한다고 확신 할 때만 철저히 테스트하는 경향이있다. 잘못하지 마십시오-전혀 테스트하지 않고 1000 줄을 쓰지 않을 것입니다 (도박입니다). 완료 된 것으로 생각한 후 전체 서브 루틴을 작성하고 테스트 (필요한 경우 수정)합니다.

다른 한편으로, 나는 에디터에 입력 한 모든 줄마다 코드를 실행하고 테스트하는 초보자를 보았습니다. 디버거는주의와 정신을 대신 할 수 있다고 생각합니다. 일단 언어 구문을 배운 후에는 이것이 많은 산만하다고 생각합니다.

두 접근 방식의 균형이 무엇이라고 생각하십니까? 물론 첫 번째는 더 많은 경험이 필요하지만 생산성에 긍정적 또는 부정적인 영향을 미칩니 까? 두 번째 것은 더 세밀한 수준에서 오류를 발견하는 데 도움이됩니까?

그것은 실제로 작업중 인 프로젝트의 측면에 달려 있습니다.

• 상태 머신처럼 작동하는 OpenGL로 무언가를 할 때 실수로 아무것도 조이지 않도록 끊임없이 컴파일하고 실행합니다. 함수의 끝에서 값을 재설정하지 않고 하나의 값을 설정하면 응용 프로그램이 검은 색 화면 만 렌더링하도록 쉽게 만들 수 있습니다.

• 더 큰 규모의 "후드"개발을 위해 가능한 한 많은 테스트를 미리 시도합니다. 테스트를 통해 어떤 문제가 발생했는지 더 쉽게 알 수 있기 때문에 일반적으로 긴 컴파일을 기다리지 않고도 시간을 보낼 수 있습니다.

• UX 디자인의 경우 항상 일종의 비주얼 디자이너를 사용합니다. 비주얼 디자이너는 항상 실행 방식에 가깝습니다. 기본적으로 항상 디자인 코드를 컴파일합니다.

개인적으로 생물학적 L1 캐시에 몇 시간 분량의 코딩을 유지할만큼 똑똑하지 않기 때문에 작은 청크로 작업해야합니다. 제한된 기능으로 인해 작고 응집력있는 방법과 디자인 개체를 작성하여 매우 느슨한 결합을 갖습니다. 더 강력한 도구와 언어를 사용하면 빌드하지 않고도 더 쉽게 코딩 할 수 있지만 여전히 한계가 있습니다.

선호하는 것은 작은 조각을 쓰고 예상대로 작동하는지 확인하는 것입니다. 그런 다음 이론적으로는 그 부분의 세부 사항을 잊어 버리고 가능한 한 블랙 박스로 취급합니다.

구현 코드를 작성 하기 전에 테스트를 작성하고 싶습니다 . 나는 세 가지 이유로 이것을 좋아한다.

1. 미리 테스트 코드를 작성하면 코드 사용 방법을 생각하는 데 도움이됩니다. 처음에 프로그램을 디자인 할 때 생각하지 못한 엣지 사례를 생각하는 데 도움이됩니다.
2. 모든 테스트 사례가 통과되면 구현 코드 작성이 완료되었음을 알고 있습니다.
3. 코드 전에 테스트를 작성하는 습관을들이는 것도 코드에 새로운 버그가 추가되지 않았다는 것을 증명할 수있는 효과가 있습니다 (좋은 테스트 사례를 작성했다고 가정).

나는 때때로 문법 검사를 제외하고 컴파일러를 실행하지 않고 몇 시간, 심지어 며칠 동안 코드를 작성하는 것을 발견했다.

몇 시간에서 며칠-코드를 더 작은 덩어리로 분해하여 자체적으로 검증하고 테스트 할 수있는 능력을 놓쳤다는 명백한 징후입니다. 당신은 분명히 그 일을해야합니다.

나는 더 큰 코드 덩어리를 신중하게 작성하고 코드가 내 머리 속의 흐름을 분석하여해야 할 일을 수행한다고 확신 할 때만 철저히 테스트하는 경향이있다.

머릿속에서 분석하는 데 몇 시간이 걸리는 더 크고 복잡한 코드를 작성하는 대신 큰 빌딩 블록이 아닌 더 작게 작성해야합니다. 이것을 건축 추상화 라고합니다. 그리고 그것은 좋은 프로그래밍의 요지이며, 초보자가 아니라는 신호는 아닙니다.

훌륭한 프로그래밍은 훌륭한 Billard 게임과 같습니다. 훌륭한 플레이어는 하드 스트로크를하지 않습니다. 대신, 그는 각 스트로크 후 볼이 다음 스트로크가 다시 쉬운 위치에서 멈추는 방식으로 경기합니다. 그는 복잡한 코드를 작성할 수 있기 때문에 프로그래머는 좋지 않다 - 그가 할 수 있기 때문에 그는 좋은 피 복잡한 코드를 작성.

다음 조건 중 하나가 충족되는지 컴파일하고 테스트합니다.

• 마지막 컴파일은 15 분 전
• 마지막 컴파일은 25 줄이었습니다.
• 새로운 기능 / 서브 루틴이 구현되었습니다
• 주요 변화
• 새로운 기능 (또는 기능으로 위장한 버그)
• 버그 수정 ( "기능"제거)
• 나는 지루해

코드를 실행하고 테스트하는 빈도는 당시 사용중인 언어에 따라 다릅니다. 저장 프로 시저를 코딩하는 경우 일반적으로 모든 것이있을 때까지 기다립니다.

반면에 Lisp로 코딩하는 경우 입력 한 후에 각 함수를 시도합니다.

Haskell로 코딩하는 경우 일반적으로 각 함수 다음에 컴파일하여 모든 유형 오류를 포착하고 모든 작업이 완료된 후 코드를 실행합니다.

초록색으로 테스트하기에 충분한 코드를 작성합니다. 즉, 몇 분마다 테스트를 실행합니다. 이것이 내 C ++ 스타일입니다. 그러나 Ruby에서는 자동 테스트를 사용하므로 save를 누를 때마다 멋진 팝업을 통해 테스트 피드백을받습니다. 코드 작성을 중단하지 않고 백그라운드에서 발생합니다.

필요 여부에 관계없이 한 시간에 세 번.

테스트 우선 프로그래밍을 수행하고 VCS에 작동 코드 만 커밋합니다. smolderbot은 20 분마다 리포지를 확인하고 테스트 스위트를 실행합니다. 모든 오류는 즉시 전체 프로그래밍 팀으로 우송되어 즉시 수정됩니다.

나에게 그것은 얼마나 쓰는지에 관한 것이 아닙니다. 테스트하지 않고도 수천 줄의 간단한 코드를 작성할 수 있습니다. 그러나 더 어려운 코드를 작성할 때 응집력있는 세트를 작성한 후에 각 함수를 개별적으로 테스트하는 경향이 있습니다.

때로는 코드 실행을 보는 것이 동기 부여를 크게 증가 시키는데, 잠시 동안 아무것도 실행하지 않으면 작동하는 것이 좋습니다.

나를 위해;-
짧은 타임 라인 (생각할 시간이별로 없습니다)-코드 작성, 컴파일, 테스트. 디버그
충분한 시간-while (완료) {작은 코드 작성, 컴파일}, 테스트, 디버그

각 코딩 개념을 테스트합니다. 때때로 이것은 함수 또는 클래스이며 때로는 if 문에 지나지 않습니다. 개념이 작동하면 다음 개념으로 넘어갑니다.

코드 전에 테스트를 시도하고 작성합니다. 커밋 전에 적어도 두 번 테스트를 실행합니다. 그런 다음 Continous Integration 서버와 함께 다시 실행됩니다.