단순히 코드를 테스트하는 데 오랜 시간이 걸리면 어떻게 효과적으로 프로그래밍합니까?

16

내 워크 플로는 항상 하나의 논리적 단계를 작성한 다음 프로그램을 실행하고 출력을 검사하는 것이 었습니다. 이 과정을 통해 대학에서 과제를 수행 할 수있었습니다. 그러나 더 많은 개발을 할 때 코드를 컴파일하고 실행하는 데 1-2 분이 걸리는 경우가 종종 있습니다. 예를 들어 프로그램을 마이크로 컨트롤러에 업로드하고 외부 서버와 상호 작용해야하며 인증, 소프트웨어 아키텍처 또는 복잡성으로 인해 자동화를 구현할 수 없습니다.

이러한 유형의 작업은 내가 일반적으로 프로그래밍하는 방식에 매우 적합하지 않으며 효과적으로 코딩하는 데 어려움을 겪고 있습니다. 나는 일반적으로 많은 구문 오류와 논리 오류를 만들며, 대부분은 테스트를 통해 쉽게 잡을 수 있습니다. 그러나 대기 시간이 길면이 방법이 너무 시간이 많이 걸립니다.

efficiency time

— 앤 노니 무스
소스

IDE를 사용하고 있습니까?

— Woot4Moo

3

근본 문제는 효과적으로 코드를 작성할 수 없으며 실행하는 데 너무 오래 걸리는 테스트입니다. 당신은 잘못된 질문을하고 있습니다.

— Rein Henrichs

REPL이있는 언어를 사용하십시오.

— Robert Harvey

질문하고 배울 수있는 동료가 있습니까?

— user985366

25

우선, 모든 종류의 대화식 디버깅이 좋습니다. 아직 툴킷에 포함되어 있지 않다면 언젠가는 툴킷을 사용하면 큰 도움이 될 것입니다. (자세한 내용은 언어, 플랫폼 및 IDE에 따라 다릅니다.)

외부 서버와의 상호 작용이 필요하고 인증, 소프트웨어 아키텍처 또는 복잡성으로 인해 자동화를 구현할 수 없습니다.

모의 객체 를 사용하기위한 프레임 워크를 살펴 보았습니다 . 이를 통해 테스트중인 구성 요소를 다른 구성 요소의 가짜 에코 시스템으로 둘러 쌀 수 있으므로 테스트가보다 구체적으로 대상화되고 전체 단위로 모든 테스트를 피할 수 있습니다.

또한 모의 객체 자체를 어설 션으로 프로그래밍 할 수 있으므로 테스트 할 구성 요소가 실제로 특정 호출을 수행했는지 확인할 수 있습니다.

— 다리 엔
소스

12

시험 시간을 줄이기 위해 열심히 노력했습니다. 임베디드 코드를 개발하는 두 회사에서 근무했으며 테스트가 어려워 서버 룸과 수동 FTP 로의 트립과 재부팅 및 테스트 하드웨어에 대한 여러 명령이 필요했습니다. 그런 다음 정말 좋은 그룹에 합류하여 책상에 'make test'를 입력하고 1 분 안에 결과를 다시 얻을 수있었습니다. 그 1 분 안에 :

내 코드는 임베디드 하드웨어를위한 새로운 커널 이미지로 만들어졌습니다.
DHCP 서버가 새 커널을 가리 키도록 업데이트되었습니다.
테스트 보드가 재부팅되었습니다.
테스트 보드는 NFS 마운트를 통해 내 워크 스테이션에서 커널을 검색했습니다.
테스트 보드가 새 커널로 재부팅되었습니다.
단위 테스트가 실행되었습니다.
단위 테스트 출력이 다시 내 워크 스테이션으로 전달되었습니다.

이 모든 작업을 수행하는 데 약간의 시간이 걸렸지 만 개발 스태프가 커짐에 따라 이러한 모든 단계를 자동화하려는 노력은 100 배나 증가했습니다.

— 케빈 클라인
소스

2

+1. 충분한 양의 셸 스크립트로 해결할 수없는 문제는 없습니다.

— Tom Anderson

1

나는 속도 향상에 신경 쓰지 않는 팀에 머물지 않을 것입니다.

— 케빈 클라인

@Tom 너무 많은 abst-er, shell scripts를 제외하고;)

— Darien

아냐, 다른 쉘 스크립트를 감싸는 쉘 스크립트 만 작성하면된다. 그런 다음 하나의 쉘 스크립트가 있습니다. 날 믿어.

— Tom Anderson

3

+1 : 편집 속도 향상-> 컴파일->로드-> 실행-> 디버그-> 편집은 코드 생성 속도를 높이는 가장 좋은 방법입니다. Tymshare에서 근무했을 때 우리는 그의 코드가 처음 시도 할 때 87 %의 시간 동안 올바르게 작동했다고 주장하는 사람이있었습니다. 반면에, 나는 오전 1시에 카페인 원숭이에게 과다 복용 한 것처럼 코딩했습니다. 나는 많은 오타 등을 만들었지 만 컴파일러가 오류를 잡을 것이라는 것을 알고 있기 때문에 걱정하지 않았습니다. 하루가 끝날 무렵 나는 아마 그보다 3 ~ 5 배 더 생산적이었습니다.

— 피터 로웰

8

자동화 된 테스트는 검토 및 이해를 대신 할 수 없습니다.

목발로 테스트를 사용하고있을 수 있습니다. 이 작업을 수행하면 학습에 방해가됩니다. 나는 당신이 시험하지 말라고 주장하지 않습니다. 대신 테스트를 실행하기 전에 작성한 내용을 검토하는 것이 좋습니다. 작성한 내용을 이해하고 의미가 있는지 확인하고 구문이 올바른지 확인하십시오.

— 다이어트
소스

5

당신은 이미 대답을 했어요 : I usually make a lot of syntax errors and logic errors

따라서이를 개선하기 위해 열심히 노력하면 테스트 시간을 단축 할 수 있습니다. 구문 오류는 가장 먼저 줄여야합니다. 연구에서 종이와 연필로 프로그래밍 테스트를 한 적이 있습니까?

PHP에서 Java로 전환했을 때도 마찬가지였습니다. 브라우저에서 일부 변수를 인쇄하고 F5 키를 누르는 대신 디버그하는 법을 배워야했습니다 ...

— 워렌 페이스
소스

2

우리 모두는 때때로 어리석은 실수를 저지르며, 시간과 경험이 적은 경우에만 발생합니다.

— maple_shaft

@maple_shaft는 사실이지만, 그는 make a lot of그것을 개선하기 위해 자신의 에너지를 투자해야 한다고 말하는 것처럼 들립니다

— WarrenFaith

3

나는 종이와 화이트 보드에 상당한 양의 코딩을했습니다. 문제는 동일합니다. 코드는 첫 번째 검사에서 올바르게 보이지만 실행 한 후에 실수를 발견했습니다.

— Anne Nonimus 2016 년

코드에서 실수를 지적하고 잘못된 구문으로 코드를 작성하는 것은 큰 차이입니다. 첫 번째는 모든 사람에게 일어날 수 있고 두 번째는 초보자 수준을 제안합니다. 나는 당신의 배경을 모르지만 초보자라도 구문 문제를 최소화해야합니다. IDE와 언어는 무엇입니까? 구문 검사를 지원해야합니다.

— WarrenFaith

@Anne Nonimus : 논리적 오류를 의미합니까? IDE에서 구문 오류를 선택해야합니다 (이상적으로-동적으로 생성 된 코드로 작업하는 경우 컴파일시 해당 구문 오류가 선택되지 않음).

— FrustratedWithFormsDesigner 2016 년

4

배경, 바람직하게는 백그라운드에서 자동으로 테스트를 실행할 수있는 우수한 단위 또는 기능 테스트 플랫폼이 필요합니다. 위에서 언급 한대로 Mocks를 사용해야하며, 어떤 종류의 의존성 주입을 사용하는 언어에 따라 다릅니다.

객체를 가능한 한 독립적으로 만든 다음 주입 방법을 사용하여 외부 제약 조건을 추가하면 코드에 대한 테스트 플랫폼을 만드는 것이 어렵지 않습니다.

— 빌 리퍼
소스

2

화를내는 것 외에는 코드를 테스트 할 수 없을 때 정말 재미 있습니다. 사용 가능한 교환 시뮬레이터가 종종 열악하거나 존재하지 않거나 교환 소프트웨어 공급 업체의 말에 따르지 않기 때문에 거래 시스템에서 많은 일이 발생합니다. 이것은 내가 두려워하는 인생의 풍부한 태피스트리의 일부입니다. 나의 접근 방식은 거래의 적어도 내 측면이 잘 작성되고 문서화되어 있는지 확인하여 쉽게 변경할 수 있도록하는 것입니다.

— 닐 버터 워스
소스

3

"교환"및 "거래"소프트웨어 엔지니어는 고유 한 유형입니다. 내 친구는 그러한 회사에서 일하는 일련의 정신적 장애를 겪었습니다. 나는 소프트웨어 산업의 틈새 시장에서 좋은 것들이 나오지 않는다고 들었습니다.

— maple_shaft

@maple 글쎄, 나는 더 이상 나 자신을하지 않습니다. 그러나 독특합니까? 아냐-누구나 엉터리 코드를 작성할 수 있고, 대부분의 거래 코드는 깊고 깊다. 그러나 그것이 좋든 싫든 우리 사회의 기초입니다.

— Neil Butterworth

예, 통신 코드와 스위치 제어 소프트웨어에있는 수백만 개의 회선에 대해 같은 이야기를 들었습니다. 그런 다음 Telecom 회사에 입사하여 일부 프로그래머를 고용 한 경우 수천 개의 회선으로 충분하다는 것을 깨달았습니다.

— 케빈 클라인

2

단위 테스트; 모의 애플리케이션 / 시뮬레이터.

이 작업에는 시간이 걸리고 당연한 것이며 적절한 모형을 만들기 위해 샘플 데이터를 수집하고 마사지해야 할 수도 있지만 결국에는 돈을 지불하게됩니다. 시스템.

올바르게 사용하면 이러한 도구를 사용하면 외부 시스템 근처로 이동하기 전에 코드가 실패 할 경우 외부 시스템 / 환경 변경으로 인해 자체 코드의 버그가 아니라고 99.9 % 확신 할 수 있습니다.

나는 당신이 학교에서했던 것처럼 꽤 오랫동안 전문적으로 일했으며 많은 경우에 매우 효과적이었습니다. 결국 나는 그 방법론을 포기하고 대신 단위 테스트와 모형을 사용하도록 강요했던 일부 사람들과 함께 일했습니다.

이제 단위 테스트, 모형, 시뮬레이터, 샘플 데이터 등 테스트 단계의 구현을 통해 먼저 생각하지 않고 프로젝트를 시작하지 않습니다.

— 벡터
소스

1

나는 일반적으로 많은 구문 오류와 논리 오류를 만듭니다.

아마도 Linter를 사용하면 약간 도움이 될 수 있습니다.

나는 이전 고용주와 비슷한 상황에있었습니다. 우리의 코드베이스는 정말 커서 코드를 변경 .class하고 dev-server에서 파일을 컴파일 한 다음 바꾸기 스크립트를 사용하여 dev-sever를 다시 시작했습니다. 그리고 실망스럽게도 dev-server를 다시 시작하는 데 약 30 분이 걸립니다.

나중에 dev-server의 원격 디버깅도 가능하다는 것을 알았습니다.

프로세스를 최적화하기 위해 수행 한 작업은 다음과 같습니다.

최초의 원격 디버깅 라운드를 통해 정확한 코드 흐름과 변수의 정확한 값 / 상태를 볼 수있었습니다.
어떻게 그리고 어떤 변경을 할 것인지 계획하기.
변경 후 diff 비교
linter를 사용하거나 컴파일하여 실수를 캐싱합니다.
.class파일 을 교체 하고 다시 시작 하여 핫픽스를 제공합니다 .

때로는 코드 흐름을 다시 확인하고 값 / 상태를 확인하기 위해 많은 로그 문을 포함하기도합니다. 이것은 나에게 많은 도움이되었습니다.

또한 자동 복잡성이 좋은 IDE를 사용하면 오타를 줄이는 데 크게 도움이 될 수 있습니다.

도움이 되었기를 바랍니다.

— 알 라프 아잠
소스