플로우 차트 대신 의사 코드를 언제 사용합니까?

Fl owchart와 의사 코드는 종종 표현 수준이 같지만 선형화가 다릅니다. 의사 코드는 선형 (예 : 명령이있는 일련의 줄)이지만 순서도는 그렇지 않습니다. 따라서 플로우 차트는 의사 코드를 작성하기 전이나 문서화에 사용되는 더 높은 추상화 수준입니다.

플로우 차트는 의사 코드에 비해 두 가지 강력한 장점이 있습니다. 첫째, 그래픽입니다. 기술에 익숙하지 않은 많은 사람들은 구조화 된 텍스트에 대해 강한 두려움을 가지고 있지만 그래픽 설명에 대해서는 두려워하지 않으므로 순서도는 훨씬 더 잘 어울립니다. 둘째, 플로차트는 분기가 아닌 주요 실행 라인을 표시하는 것과 같은 메타 고려 사항을 훨씬 더 잘 표현합니다.

자세한 질문 :

1. 정말 복잡한 경우 문제는 먼저 플로차트를 사용한 다음 의사 코드를 사용합니다. 충분히 안전하다고 생각되면 둘 다 선택 사항입니다.
2. 예, 의사 코드는 실제 코드와 병합 할 수 있다는 장점이 있습니다. 예를 들어, Steve McConnell은 먼저 의사 코드로 메서드를 작성한 다음 코드에 의사 코드를 주석으로 남겨 둘 것을 강력히 권장합니다.
3. 나는 항상 디자인 중에 플로차트를 그려야 할 때 문제의 분할이 불충분하다는 것을 느꼈습니다. 사소하지 않은 플로차트는 복잡한 논리를 나타내므로 큰 비용으로 피해야합니다.

댓글

• 플로 차트도 좋은 방법입니다. 모든 결정 지점이 가장 일반적인 경로뿐만 아니라 덜 일반적인 경로에 대한 작업을 정의하는지 확인합니다. 이렇게하면 승인이 거부되거나 주문이 취소 될 때해야 할 일을 알 수 있습니다. 사람들이 버그를 잊거나 QA 중에 테스트에서 발견 할 때 서두르 기 때문에 엣지 케이스에 더 많은 버그가 있습니다.

의사 코드

솔직히 저는 의사 코드를 많이 사용하지 않습니다. 일반적으로 코드를 작성하는 것이 더 빠르기 때문에 작업이 완료되면 내 코드는 실제 코드입니다. 의사 코드가 도움이 될 수 있지만 일반적으로 매우 복잡한 작업을 수행하고 메서드의 구조를 분해하려고하는 경우가 있습니다. 이러한 경우 IDE에서 주석을 사용하여 구조를 배치합니다. 그런 다음 댓글에 실제 코드를 작성합니다. 이렇게하면 몇 가지 작업을 수행하는 데 도움이됩니다.

• 내가 가지고 있고 구현하지 않은 영역을 볼 수 있습니다. 주석을 읽고 그 사이에 명백한 차이가 있는지 확인합니다.
• 실제 코드를 입력 할 때 내가하는 일을 영어로 설명하는 주석이 있습니다. (그렇게 복잡하다면 아마 필요할 것입니다. 먼저 의사 코드를 작성해야합니다).

플로차트

코드가 일반적으로 너무 많이 변경되어 더 크고 시스템 전체 아키텍처를 제외하고는 플로차트가 도움이되지 않습니다. 설계 또는 문서. 그런 경우에는 다이어그램을 화이트 보드로 작성하여 요점을 파악하거나 팀의 다른 사람에게 보여줄 것입니다. 이해하는 데 도움이되는 플로차트가 정말로 필요하지 않으면 소프트웨어를 “실행”하는 데 실제로 필요하지 않습니다. 권리. 요즘에는 코드 자체는 물론 클래스 다이어그램 및 기타 (및 iv id = “bcffb6d975”)에서 플로차트를 생성하는 많은 IDE 용 플러그인 이 있습니다. >

일반적으로 개인 프로젝트를 진행하는 동안에는 플로차트를 작성하지 않습니다 (프로젝트가 크지 않기 때문에). 대부분의 입력, 출력 및 프로세스는 명확합니다.

하지만 다른 입력 소스를 사용하여 복잡한 대규모 프로젝트 작업을 시작할 때 플랫 파일, 데이터베이스, 수동 인터페이스 등의 순서도가 편리합니다.

추천합니다. 이러한 도구는 더 나은 클래스, 메서드 등을 만드는 데 도움이되므로 의사 코드와 UML 다이어그램을 작성합니다. 때로는 의사 코드를 작성하는 동안 프로그램을 해결하는 다양하고 효율적인 방법을 찾을 수 있습니다.

의사 코드는 최소한 코드의 기본 사항을 이해하는 사람들에게 아이디어를 신속하게 표현하기위한 것입니다. 순서도는 다른 모든 사람에게 예쁜 그림을 그리는 것입니다. 동일한 내용을 이해합니다.

많은 사람들이 문서화와 순서도를 사용하는 것이 더 쉽기 때문에 순서도는 문서화 목적으로 자주 사용됩니다. 프로그래머가 아닌 경우 의사 코드보다 따르십시오. 자신을 위해 작업하는 프로젝트에서 의사 코드를 고수하는 것은 텍스트 편집기 만 있으면되기 때문에 훨씬 더 유용하고 만들기가 훨씬 쉽기 때문에 괜찮습니다.

순서도는 작업 진행 방식을 계획 할 수있는 높은 수준의 추상화입니다. 예를 들어

x dies y wins

클래스와 메서드, 반면에 의사 코드 측면에서 프로그램을 설계하는 방법에 의존 할 필요가 없습니다. 더 낮은 수준의 추상화를 제공합니다 (실제로는 다름)

if (isdead (s)) y.win ()

이제 사용중인 언어에 따라 의사 코드를 실제 프로그램으로 변환 할 수 있습니다.

게임의 경우 먼저 플로차트를 사용한 다음 디자인하는 것이 좋습니다. 클래스와 메서드, 의사 코드를 작성하고 마지막으로 프로그램으로 변환

d 작성중인 코드의 특성을 고려하십시오. 해당하는 경우 :

1. 매우 반복적 / 재귀 적
2. 복잡한 방식으로 분기
3. 여러 시스템에 구현되어 표시하려는 시스템

처음 두 경우에서 의사 코드는 큰 그림 다이어그램보다 점점 더 읽기 어려워집니다. 반면에 대부분 선형 인 코드는 프로세스가 얼마나 부풀려 지느냐에 따라 프로세스를 실제로 이해하기 어렵게 만드는 엄청나게 지루한 다이어그램을 만듭니다.

세 번째 경우에는 플로우 차트가 다음과 같은 프로세스를 더 잘 표현합니다. 시스템 경계를 넘고 전체 프로세스를 나타냅니다.

1. 편안하다고 느끼는 모든 것을 사용해야합니다. 즉, 요즘에는 플로차트가 프로그램 제어를 스케치하는 데 많이 사용되지 않는다는 느낌이 듭니다. 한 가지는 의사 코드에 비해 일반적으로 구조화되지 않았습니다. UML과 같은 클래스 종속성 다이어그램을 사용하여 아키텍처를 훨씬 더 높은 수준에서 설명하는 것이 더 일반적입니다. 또한 애플리케이션에 상태 머신이있는 경우 (순서도와 같은) 상태 머신 다이어그램을 그리는 것이 중요합니다.
2. 여기에서 맞다고 생각합니다. 작업하는 한 가지 방법은 소스 파일의 주석으로 의사 코드를 작성하고 그 사이에 실제 구현 행을 삽입하는 것입니다.
3. 다시, 편안하게 느끼는 것을 사용하십시오. 확실하지 않다면 두 가지를 모두 시도해보십시오. 귀하의 연습이 귀하에게 가장 유용한 것으로 빠르게 수렴 될 것으로 기대합니다. 특히 복잡한 실행 순서를 풀려고하지 않는 한 개인적으로 유용한 순서도를 찾지 못합니다.

Java를 작성할 수 있는데 의사 코드를 작성하는 이유는 무엇입니까? 저는 좋은 IDE 인 Java를 찾았습니다. Javadoc은 프로그래밍 문제 (최소한 객체 지향 문제)를 파악하는 가장 쉬운 방법입니다. (그리고 아케이드 게임은 OO이어야합니다.) 언어는 처음부터이를 위해 설계되었습니다. 간단하고 간단합니다. (여러 목적으로는 너무 간단하지만 내가 본 것 중 가장 좋은 점입니다.) Javadoc의 하이퍼 텍스트와 IDE를 통한 코드 자체는 사용자가 그릴 수있는 것보다 더 이해하기 쉬운 “다이어그램”을 만듭니다. 자바 코드는 의사 코드만큼 간단하고 훨씬 더 엄격합니다. “다이어그램”및 “의사”코딩을 마치면 프로그램이 실제로 실행됩니다!

댓글

• 자바 및 기타 파일은 오래 걸릴 수 있습니다. ” public static void main .. ” 또는 ” system.out.println ” 또는 카멜 백 표기법이있는 긴 식별자, 여기에 길게 감습니다 .n 다음 예외 have 2b catch .. 그리고 도서관을 호출하는 것은 오래 걸리지 않을 수 있습니다. 10 년 전 파일을 열었던 것을 기억합니다. new BufferedReader (new InputStreamReader (System.in)); 지금은 분명히 더 쉬워졌습니다. mkyong.com / java / … 그러나 실제로 호출하는 모든 라이브러리는 상상할 수있는만큼 간결한 의사 코드와는 달리 오래 걸릴 수 있습니다.
• 또한 Java 또는 모든 언어에서 컴파일 오류가 발생합니다. 의사 코드로는 해당되지 않습니다. 산만 함없이 디자인에 집중할 수 있습니다. 의사 코드에 대한 주석은 의사 코드가 생각에서 더 명확 해 지므로 ‘ 훨씬 더 간단 할 수 있습니다. 당신은 ‘ 하나의 언어로만 생각하는 것에 제한을받지 않으며, 다른 언어를 사용할 것임을 알 수 있습니다 ‘. 작성하는 것이 ‘ 빠르고 덜 고통스럽고 (컴파일이 필요하지 않습니다. 매우 유창한 경우에도 컴파일 오류가 발생 함) 작성 시간이 줄어들어 재 설계가 더 쉽습니다.
• @barlop : 나에게는 효과가 있지만 모든 사람에게 효과가있는 것은 아닙니다. 코드가 필요하거나 알 필요가있을 때까지 많은 코드 (예 : ” BufferedReader “)를 수업에서 제외합니다. 작동시킬 수 있습니다. 내가 가지고 있어도 ‘ 전체를 고려할 때 살펴볼 필요가없는 ‘ 수업에서 멋지게 숨겨져 있습니다. 디자인. 컴파일러 오류는 쉽게 수정할 수 있으며 ‘의 인스턴스를 가져올 수없는 지점에서 잘못된 클래스를 사용하는 등의 주요 설계 결함을 방지 할 수 있습니다. 올바른 수업. 인정합니다. 저는 오직 할 수있는 소프트웨어를 설계 ” ” Java로 작성되지만 OP는 Java를 사용하고 있습니다 .
• 파일을 열고 싶다고합시다. openfile (” c : \ blah \ file “)는 자바보다 짧습니까? 또는 인쇄 ” dfdfd “가 자바보다 짧습니까? 저는 ‘ 아직 의사 코드 및 여러 클래스 페이지를 수행 한 적이 없습니다. 부분적으로 ‘ Cos ‘ 대규모 프로그램을 작성하지 않았습니다. b) 부분적으로 ‘ cos 저는 ‘ 그럴 것이라고 생각하지 않습니다. ‘ 몇 가지 의사 코드를 작성한 다음 구현할 것이라고 생각합니다. 다른 의사 코드가 있으면 더 높은 수준이됩니다. 생성자를 포함한 모든 클래스 및 메서드 목록이있을 수 있습니다. 그래서 나는 어떤 클래스가 무엇인지 그리고 그 인스턴스를 얻을 수 있다는 것을 알고 있습니다.
• 그래서 저는 ‘ 잘못된 클래스를 사용하는 상황에 있지 않을 것입니다. 하지만 어쨌든, 그것이 ‘ 내 프로그램이라면, 나는 ‘ 내 노트에 어떤 수업이 무엇인지 적었을 것입니다. 높은 레벨. 기억할 수 없다면 ‘ 그에 대한 메모를 ‘ 알겠습니다. 의사 코드는 의미에 관한 것입니다. 따라서 blah 클래스의 인스턴스를 만들려고하고 bleh를 작성했다면 ‘ 그냥 오타이지만 그렇지 않습니다. ‘ 디자인을 방해하지 마십시오. (‘ 자신을 위해 글을 쓰고있는 경우 ‘ 당신이 의미하는 바를 알고 있고 그것을 엉망처럼 사용한 것입니다).

if 문으로 인해 혼란스럽고 이해하려고하는 경우 플로차트를 사용할 수 있습니다. 그. 또는 루프를 이해하려는 경우 카운터의 효과를 확인하십시오. 학습하는 경우 많은 도움이 될 수 있습니다.

약간 제한적이라고 느낄 수 있습니다. “간단한 문장을 상자에 넣어야하기 때문입니다. 그리고 프로그램이 매우 선형적이고 루프와 ifs가 사소한 경우에는 쓸모가 없다고 생각합니다.

의사 코드는 프로그램을 설계하는 데 유용합니다. 구문을 올바르게 작성해야하는주의가 산만하지 않고 일부 언어가 포함 할 수있는 장황함이 없습니다. 작성 속도가 빠르기 때문에 재 설계가 더 쉬워집니다. 암호. 그리고 마음이 원하는대로 간결하게 작성할 수 있고, “작성하는 것이 즐겁고, 작동하는 데 정신적 노력을 덜 필요로하며 (디버깅이 없거나 훨씬 적음) 큰 그림과 디자인에 더 집중할 수 있습니다.

자신에게 유용합니다.

다른 사람과 의사 소통하는 데에도 사용할 수 있습니다.