의사 코드 프로그래밍 프로세스 대 테스트 주도 개발

Question

코드 완료 2를 읽지 않은 사람들을 위해 의사 코드 프로그래밍 프로세스는 기본적으로 간단한 영어로 설명하여 루틴을 디자인 한 다음 점진적으로 더 자세한 의사 코드로 수정합니다 , 마지막으로 코드를 작성합니다. 이 기능의 주요 이점은 시스템을 상향식이 아닌 하향식으로 빌드함으로써 명확한 수준의 추상화 상태를 유지할 수있게하여 개별 레이어에서 깨끗한 API를 개발하는 것입니다. TDD는 그다지 효과적이지 못합니다. 왜냐하면 테스트를 통과하기 위해 최소한의 노력 만 기울이기 때문에 약간의 초기 설계를 권장하기 때문입니다. 또한 불안정한 코드 (코드가 끊임없이 리팩토링되는 코드)에 대한 단위 테스트 스위트를 유지해야한다는 사실을 알게되면 일반적으로 1 ~ 2 회만 필요로하는 루틴을위한 12 개의 단위 테스트가 있기 때문에 매우 어렵습니다. 리팩토링을 할 때 - 예를 들어 메소드 서명을 변경하는 경우 - 당신이하는 대부분의 작업은 찌르는 코드가 아닌 테스트를 업데이트하는 것입니다. 구성 요소의 코드가 조금 안정화 된 후에 단위 테스트를 추가하는 것을 선호합니다.

제 질문은 두 가지 방법을 모두 시도한 사람들 중 귀하가 선호하는 것입니까?

Answer 1

테스트 기반 개발을 사용하면 처음부터 계획을 세우고 있어야합니다. 처음에는 당신이하려고하는 것을 고차원 적으로 봐야합니다. 모든 세부 사항을 제시하지는 말고 문제 해결 방법에 대한 영어로 아이디어를 얻으십시오.

그런 다음 문제 테스트를 시작하십시오. 일단 시험을 통과하면 시험을 통과하십시오. 그렇게하기가 쉽지 않으면 초기 계획을 수정해야 할 수도 있습니다. 방금 수정하는 데 문제가있는 경우. 이 테스트는 솔루션을 정의하는 것이 아니라 안정성을 보장하면서 더 나은 솔루션을 제공 할 수 있도록 변경을 허용합니다.

나는 TDD를 사용하는 것이 가장 좋습니다. 핵심은 TDD가 "계획 건너 뛰기"를 의미하지 않는다는 것을 깨닫는 것입니다. TDD는 시작을 잘 계획하고 필요에 따라 조정하는 것을 의미합니다. 조정할 필요조차 없습니다.

Answer 2

일반적으로 의사 코드는 문제 해결에 필요한 코드가 솔루션을 테스트하는 데 필요한 코드보다 훨씬 복잡 할 때만 관련이 있습니다. 이것이 사실이 아니라면, 당신이 설명하는 어려움에 빠지지 않습니다. 가장 단순한 일은 대개 문제에 소비 할 가치가있는 시간의 양을 수용할만한 해결책입니다.

이 복잡하면이 복잡하면 초기 접근 방법을 생각해 볼 필요가 있습니다. 코드를 작성하기 전에 계획을 세워야합니다. 따라서 두 가지 접근 방식의 조합을 사용합니다. 처음에 작성할 내용을 영어로 설명한 다음 테스트 도구로, 그 다음 순진한 솔루션 코드로, 다음으로 세분화합니다.

Answer 3

저는 Big Upfront Development와 함께이 두 가지를 사용했습니다. 세 가지 모두 언어, 팀 역학 및 프로그램 크기/복잡성과 같은 문제에 따라 위치가 다릅니다.

동적 언어 (특히 루비)에서는 TDD를 사용하는 것이 좋습니다. 다른 언어가 컴파일 할 때 잡아 먹는 오류를 잡는 데 도움이됩니다.

크고 복잡한 시스템 일수록 더 좋은 디자인을 선행 할 수 있습니다. 그것은 내가 큰 프로젝트를 위해 디자인 할 때, 내가 손으로 손을 흔들며 "이것은 꽤 똑바로되어야한다"고 말한 모든 영역이 프로젝트의 뒤의 걸림돌이었던 것처럼 보인다.

정적으로 형식이 지정된 언어로 작게 혼자 작업하는 경우 목록 접근 방식이 적당하며 TDD보다 많은 시간을 절약 할 수 있습니다 (테스트 유지 관리는 무료는 아닙니다. 너무 나쁘지는 않습니다.) - 작업중인 시스템에 테스트가 없으면 테스트에 추가하는 것이 항상 존경받는 것은 아니므로 원치 않는주의를 끌 수도 있습니다.

Answer 4

테스트가 통과 되었기 때문에 완료되었다고 할 수는 없습니다.

TDD는 Red - Green - Refactor으로 가장 잘 특성화됩니다.

테스트를 받으면 하나의 (2 개의) 골 라인을 제공합니다. 이것은 처음이자 최소한의 요구 사항 일뿐입니다. 진정한 목표는 "의사 코드 프로그래밍 프로세스"또는 모든 디자인 분야와 동일한 목표입니다.

또한, TDD는 테스트하여 구동 이지만 그 테스트가 맹목적 구동 것은 아니다. 코드를 반복하는 것과 같은 방법으로 테스트를 반복 할 수 있습니다. 여기에 바보 같은 계획을 독단적으로 고수 할 곳이 없습니다. 이것은 민첩한 기술입니다. 즉 팀과 상황에 맞게 조정할 수 있습니다.

테스트 가능한 인터페이스를 가질 수있는 충분한 코드를 디자인하십시오. 인터페이스가 제대로 작동하는지 충분한 테스트를하십시오. 리팩터링을 할 필요가있을 때까지 좀 더 많은 테스트와 구현을 추가로 설계하십시오.

진짜 목표는 좋은 소프트웨어입니다. TDD는 "선량"을 배제 할 수 없습니다.

기술은 제한적인 권한이 아닙니다. 기술은 훌륭한 제품을 생산하는 데 도움이되는 버팀목으로보아야합니다. 내가 더 똑똑하고 풍부하며 잘 생긴다면 나는 TDD가 필요하지 않을 것이다. 하지만 나는 나만큼 바보 같기 때문에 리팩터링을 돕기 위해 버팀대가 필요하다.

Answer 5

나를 위해 TDD에는 경쟁 할 수없는 에이스 의사 코딩이 있습니다. 둘 다 추상적 인 설계와 개발 계획을 세우지 만 TDD에서의 개발을 마친 후에는 유닛 테스트가 아직 완료되었습니다..

pseudocoding이 기술 된 CC2와 같은 유용한 접근 방식은 유용하지 않습니다. TDD는 설계의 절반에 지나지 않으며 프로젝트를 발전시킬 수있는 엄격한 발판을 제공합니다. 그러나 TDD가 설정 한 문제를 해결하기 위해 의사 코드를 작성할 수없는 이유는 없습니다.

유기적으로 개발하면 안됩니다.
가짜 코드는 마음을 죽이는 사람입니다.
프로젝트 메모리 망각을 가져 오는 것은 작은 죽음입니다.
나는 나의 90 년대 방법론에 직면하게 될 것이다.
나는 그것이 나를 넘어서 통과 할 수 있도록 허락 할 것이다.
그리고 지나간 후에 내면의 눈을 돌이켜 그 길을 볼 것입니다.
의사 코드가 사라진 곳은 TDD입니다.
단위 테스트 만 유지됩니다.

(I 절반 밖에 심각 해요, 그 날 불꽃하지 마십시오 : P) (적어도 우리를 위해)

Answer 6

우리 팀은 두 가지 방식을 혼합하고 그것을 개발하는 멋진 방법 . 우리는 크고 복잡한 소프트웨어 시스템을 가지고 있기 때문에 단위 테스트가 필요합니다.그러나 Pseudocode Programming Process는 내가 만났던 소프트웨어 설계에 대한 최선의 접근 방식이다. , 우리의 클래스를 작성하여

• 우리는 시작을 완전히 입력과 출력을, 메소드 스텁을 주석으로 기입 : 그들이 함께 작동하도록합니다.
• 페어 코딩과 피어 리뷰를 다이얼로그로 사용하여 디자인을 구체화하고 유효성을 검사합니다 (여전히 스텁 만 사용).
• 이제 우리는 시스템을 설계하고 테스트 가능한 코드를 작성했습니다. 그래서 우리는 단위 테스트를 작성합니다.
• 다시 들어가서 작성해야하는 로직에 대한 주석을 메소드에 채워 넣기 시작합니다.
• 코드를 작성합니다. 테스트가 통과됩니다.

우리가 실제로 코드를 작성하는 시점까지 구현의 대부분은 이미 완료되었습니다. 구현의 상당 부분이 실제로 코드 설계이기 때문에 이미 완성되었습니다. 또한 초기 프로세스가 UML에 대한 필요성을 대체합니다. 클래스 및 메소드 스텁은 설명과 마찬가지로 실제로 사용됩니다. 그리고 우리는 항상 적절한 수준의 추상화에 머물러 있습니다.

분명히 내가 묘사 한 것처럼 프로세스가 실제로는 매우 직선적 인 것은 아닙니다. 구현의 몇 가지 단점은 우리가 고급 디자인을 다시 방문해야한다는 것을 의미합니다. 그러나 일반적으로 단위 테스트를 작성할 때 디자인은 상당히 안정되어 (메소드 레벨에서) 테스트 재 작성을 많이 할 필요가 없습니다.