실제 코딩 전에 의사 코드를 사용해야합니까?

의사 코드는 언어에 관계없이 작업을 이해하는 데 도움이됩니다. 개발 수명주기의 일부로 의사 코드를 작성하는 것이 가장 좋은 방법입니까? 예를 들어 :

• 코딩 작업 식별 및 분할
• 의사 코드 작성
• PL 또는 TL에 의해 승인 받기
• 의사 코드를 기반으로 코딩 시작

이것이 제안 된 접근법입니까? 업계에서 시행되고 있습니까?

코딩하기 전에 의사 코드를 작성하는 것은 계획없이 코딩하는 것보다 확실히 낫지 만 최선의 방법은 아닙니다. 테스트 중심 개발이 개선되었습니다.

Cleanroom, RUP, Lean, Kanban, Agile 등과 같은 방법론에 따라 사용자 스토리, 사용 사례, CRC 카드, 다이어그램 작성과 같은 기술을 사용하여 문제 영역을 분석하고 솔루션을 설계하는 것이 더 좋습니다.

문제의 본질과 솔루션 구현에 사용하는 구성 요소를 철저히 이해하는 것이 모범 사례의 기본 원리입니다.

코드를 작성하기 전에 주석을 작성한다는 점에서 주석을 일종의 매우 높은 수준의 의사 코드로 사용합니다. 높은 수준에서도 전체 문제를 통해 생각하면 코드가 상당히 향상됩니다.

아니요, 먼저 의사 코드를 작성하지 마십시오

너무 많은 오버 헤드입니다. 당신은 아무런 이점없이 논리를 작성하는 일을하고 있습니다. 대신 다음 중 하나를 제안합니다.

1. 제공 할 언어로 된 프로토 타입 (AKA는 버리기 위해 하나를 작성하십시오 )
2. 가정 / 핵심 설계를 테스트하기위한 코드 스 니펫이 포함 된 아키텍처 다이어그램
3. 인터페이스 / 코드 구조를 먼저 작성하고 테스트를 수행 한 다음 코드를 구현하는 테스트 중심 개발.

이 세 가지 모두 의사 코드와 달리 솔루션으로 직접 이동합니다. 개인적으로 나는 팀 규모에 따라 기술 1 또는 2를 사용하는 경향이 있습니다. 소규모 (예 : 5 명 이하) 팀의 경우 프로토 타이핑이 매우 효과적입니다. 여러 개발자 그룹이 병렬로 작업하는 대규모 팀의 경우 기술 2에서 초기에 생성 된 문서가 조기에 논의 할 내용을 제공하고 구성 요소 경계를보다 잘 정의 할 수 있도록 도와 주므로 효과적입니다. TDD도 잘 작동 할 것이라고 확신하지만 아직이 프로세스를 수행 한 팀에서 일하지 않았습니다.

필자의 의견으로는 의사 코드에는 두 가지 유효한 목적 만 있습니다.

(1) 모듈 성과 알고리즘의 개념을 배워야하지만 아직 프로그래밍 언어에 능숙하지 않은 프로그래밍 학생들.

(2) 비 기술적 인 사람에게 또는 어떻게 화이트 보드 회의에서 편의를 위해 무언가가 어떻게 작용할 것인지를 알리는 것.

의사 코드가 제안 된 접근법입니까? 초보 프로그래머에게는 예라고 말합니다. 새로운 프로그래머가 언어의 정확한 구문에 대해 걱정하지 않고 문제를 코드로 변환하는 방법을 배우도록 도와줍니다. 이것은 사고 과정을 형성하고 유용한 습관을 심어주는 데 도움이 될 수 있습니다 (나도 나쁜 습관을 가정합니다). 이것이 학교에서 그렇게 많이 사용되는 이유입니다.

업계에서 실천되고 있습니까? 내 경험으로는 그렇지 않습니다. 문서 (요구 사항, 사양, 스토리 보드, 사용 사례 또는 기타 사용)와 실제 코드 사이에서 프로젝트를 마무리 할 시간이 없습니다. 일반적으로 코드를 작성하기 전에 문제에 대한 충분한 생각이 이미 있다고 가정합니다. 이 시점에서 하나 이상의 설계 준비 레이어를 추가하는 것보다 프로젝트 코딩이 더 중요합니다.

의사 코드를 추천합니다. 수행 할 작업을 명확하게하고 잊어 버렸거나 잠재적 인 문제가있는 항목을 식별하는 데 도움이됩니다. 계획 단계에있을 때 코드를 수정하는 것이 훨씬 쉽고 빠릅니다. 대부분의 코드를 이미 코딩 할 때까지 기다리십시오.

의사 코드는 언어에 익숙하지 않거나 정신적 상황을 바꿔야 할 때 유용 할 수 있습니다. 드문 경우에 내가 의사 코드를 작성하는 것은 종이에 있습니다. 때로는 키보드에서 손을 떼고 종이에 낙서하는 것만으로도 정신적 장애를 피할 수 있습니다.

그러나 개발 과정의 공식화 된 부분으로? 안 돼 개인에게 매우 유용한 도구입니다. 다음과 같이 "쓰기 전에 무엇을 쓰고 있는지 알 수있는"더 좋은 방법이 있습니다.

1. 시작하기 전에 분석법의 계약 (사전 / 사후 / 불변 조건) 정의
2. TDD
3. 1과 2의 결합 (계약 실행을위한 테스트 작성)

또한 코드 작성을 시작하기 전에 모든 종류의 승인을 얻는 것이 가치보다 훨씬 번거로울 수 있다고 제안합니다. 설계 검토 (사전 구현)는 유용 할 수 있지만 개별 알고리즘보다 높은 수준이어야합니다.

이전 답변에 동의하지 않고 아니요라고 말하지만주의해야 할 점은 자르는 문제를 처리하기 위해 코드를 리팩토링하는 데 열성적으로 헌신 한 경우에만 psuedocode를 제거 할 수 있다는 것입니다. Psuedocode는 본질적으로 코드를 정의하기 전에 코드를 정의하는 방법입니다. 그것은 많은 상황에서 불필요한 추상화이며, 코드가 처음으로 완벽하지 않을 것이므로 (psuedocode의 디자인을 완성하지 못할 가능성이 높음), 그것은 나에게 외모로 보입니다.

COBOL 또는 C를 작성하는 경우 실제 코드를 작성하는 데 시간이 오래 걸리기 때문에 의사 코드가 도움이 될 수 있으며 의사 코드에서 알고리즘 / 요구 사항을 확인할 수 있으면 시간을 절약 할 수 있습니다.

보다 현대적인 언어에서 의사 코드는 그다지 의미가 없습니다. 더 잘 작동하는 것은 메소드 스텁을 작성하고 최상위 로직을 채우고 알고리즘과 요구 사항을 확인하는 데 필요한 세부 사항을 실제 코드로 작성하는 것입니다. 그런 다음 승인을 위해 해당 코드를 팀 리더에게 보여주고 실제 코드를 이미 시작하도록 할 수 있습니다.

지난 10 년 동안 의사 코드를 사용한 유일한 시간은 우리가 화이트 보드 작업을 할 때 면담 중이며 특정 언어는 중요하지 않습니다.

구문에 얽매이지 않고 느슨한 용어로 프로세스 / 알고리즘을 통해 대화하는 데 확실히 도움이됩니다. 예를 들어 요점을 설명하기 위해 C # 속성이있는 C ++ 클래스 작성

그것은 그 자리를 가지고 있지만, 당신이 그것을 요구하는 ISO 유형 표준이 없다면, 반드시 필요한 곳에서만 사용해야합니다 (당신이 버릴 일입니다) 그리고 공식적인 프로세스의 일부가 아닙니다.

나 자신과 내가 지난 몇 년 동안 함께 일해온 사람들을 위해 의사 코드는 거의 완벽한 실제 코드로 바뀌지 않았습니다. 여러 언어를 동시에 사용하지 않는 한 대부분의 사람들은 기본 언어의 일반적인 패턴으로 생각하기 시작합니다. 나는 .net 상점에서 잠시 동안 일해 왔기 때문에 사무실 주위의 대부분의 사람들이 화이트 보드 낙서는 문장 부호 중 일부가 누락 된 vb 또는 c #처럼 보입니다.

운동은 옵션 등을 토론 할 때 여전히 가치가 있지만, 몇 가지 언어로 더 많은 시간을 보내면서 언어에 구애받지 않는 비트가 표류하는 경향이 있습니다.

의사 코드는 점점 UML과 같은 도구로 그래픽으로 작성되었습니다. 예를 들어 yUML을 사용해보십시오 .

간단한 UML 다이어그램을 작성하고 공개하기위한 온라인 도구. 그것은 당신이 정말 쉽게 할 수 있습니다 :

• 블로그, 이메일 및 위키에 UML 다이어그램을 임베드하십시오.
• 포럼 및 블로그 주석에 UML 다이어그램을 게시하십시오.
• 웹 기반 버그 추적 도구 내에서 직접 사용하십시오.
• UML 다이어그램을 MS Word 문서 및 Powerpoint 프리젠 테이션에 복사하여 붙여 넣기 ...

... yUML은 시간을 절약 해줍니다. 작은 UML 다이어그램 및 스케치를 작성하려는 사람들을 위해 설계되었습니다.

yUML이 없으면 UML 다이어그램 작성에는 UML 도구로드, 다이어그램 작성, 이름 지정, 레이아웃 조정, 비트 맵으로 내보내기 및 온라인 어딘가에 업로드가 포함될 수 있습니다. yUML은 그 어떤 것도하지 않습니다 ...

훌륭한 일. 좋은 토론을 시작했습니다. 필자는 다양한 루프와 알고리즘을 이해하기 위해 프로그래밍을 배우면서 의사 코드를 작성했습니다. 이것은 15 년 전보다 더 많았습니다. 당시에는 프로그래밍 언어조차 그다지 강력하지 않았습니다 ... 이벤트 중심 프로그래밍은 미래였습니다. 이제 4GL과 5GL을 사용하면 언어 자체가 아닌 일반 영어로 생각합니다. 문제를 생각할 때 우리는 객체와 작업의 관점에서 생각합니다. 그리고 복잡한 알고리즘이 될 때까지 의사 코드 (또는 농담하는 PSEU-DO-Codes)를 작성하는 것은 의미가 없습니다. 더 나은 방법으로 솔루션을 그래픽 방식으로 표현하십시오.

사용되는 언어 및 익숙한 언어에 따라 다릅니다.

파이썬이나 자바와 같은 많은 현대 언어는 이미 의사 코드에 너무 가까워서 임시 의사 코드를 먼저 작성하는 것은 낭비입니다 (IMHO). 추적 프로그램 총알 접근 방식을 사용하여 즉시 수행하는 것이 좋습니다.

저수준이거나 금속에 가깝거나 사용중인 언어에 익숙하지 않은 경우 다른 거래입니다. 그런 다음 의사 코드는 확실히 유용 할 수 있습니다.

내 작업에서 의사 코드가 깨지는 경향이있는 몇 가지 상황이 있습니다. 프로그래밍에서 도구로 사용되는 경향이있는 학계와 프로젝트의 중간에 "지금 우리는 그것을 해결합니다".

1. 코드가 의사 코드보다 실제 상황을 이해하는 데 역효과를 낳을 때. 예를 들어 SAS는 화이트 보드의 절반을 차지하여 상당히 기본적인 프로그래밍 작업을 수행합니다. 다른 포스터에서 논의한 C도 참조하십시오.
2. 많은 데이터 분석 및 통계 코딩을 사용하면 결과가 생성 될 때 코드에 많은 영향을주는 경향이 있습니다. 의사 코드는 "여기서 진단 플롯이 올바르게 보이지 않으면 X를 시도하십시오.
3. 학생들은 다양한 프로그래밍 언어를 배웁니다. 예를 들어, 내가 아는 사람들 중 통계 문제는 SAS, R 또는 Stata에서 분석 될 수 있습니다. 전통적인 프로그래밍에 더 가까운 것이 필요한 것은 R, Matlab, C, C ++, Java, Python에서 수행 될 수 있습니다. 그것은 실제로 특정 학생이 프로그램을 구현하는 대상과 목적에 달려 있습니다. 그러나 Java 사람들과 Python 사람들과 Matlab 사람들은 다른 사람들이하는 일과 코드 자체가 아닌 접근 방식이 어떻게 작동 하는지에 대한 공동 아이디어를 얻는 것이 여전히 유용 합니다.

이것은 예 / 아니오 종류의 질문이 아닙니다. 오히려 의사 코드를 언제 사용 해야하는지 궁금해야 합니다. 솔루션을 디자인하기 전에 문제점을 이해하는 것이 중요하며 솔루션을 구현하기 전에 솔루션을 명확하게 파악하는 것이 중요합니다. 의사 코드는 다음 단계 중 하나에서 사용될 수 있습니다.

1. 문제를 정의 할 때 사용 사례를 기록하는 것이 일반적이며 때로는 일련의 작업을 사용합니다.
2. 솔루션을 설계 할 때 클래스 다이어그램은 훌륭하지만 "정적"부분, 즉 데이터 만 설명합니다. 동적 부분의 경우 루프 및 사소한 데이터를 처리 해야하는 즉시 의사 코드가 사용 가능한 최상의 방법이라는 것을 알았습니다. 그래픽 대안으로는 상태 머신 (데이터가 적은 복잡한 제어 흐름에 적합) 및 데이터 흐름 다이어그램 (복잡한 데이터가있는 간단한 흐름에 적합)이 있습니다.
3. 솔루션을 구현할 때 (또는 직전) 일부 프로그래밍 언어는 읽기 어렵습니다 (생각, 조립). 이 경우 다른 표현이 유용 할 수 있습니다. 언어에 익숙하지 않은 경우에도 가치가 있습니다.

실제로는 고급 언어의 적절한 코드 인 의사 코드도 사용되며 일반적으로 프로토 타이핑이라고합니다.

의사 코드는 이해뿐만 아니라 의사 소통에도 좋습니다.

의사 코드를 정기적으로 사용 해야하는지 궁금하다면 개인적으로 모든 종류의 엄격한 규칙에 위배됩니다. 팀의 모든 사람들이 이해하는 사소한 문제에 사용된다면 이것은 지루한 시간 낭비로 쉽게 변할 수 있습니다. 프로젝트 수명 동안 유지 관리하는 사양에 의사 코드를 사용하면 비용이 많이 들며 가치가 거의 없습니다.