먼저 명령줄 개발을 어떻게 생각하시나요?

https://stackoverflow.com/questions/18984

09-06-2019
|

문제

먼저 명령줄용으로 개발한 다음 단순히 명령줄 메서드를 호출하여 나중에 GUI를 추가하는 것에 대한 귀하의 의견은 무엇입니까?

예.

W:\ todo AddTask "John과의 회의, re:로그인 피어 리뷰" "John의 사무실" "2008-08-22" "14:00"

잔뜩 todo.exe 그리고 다음과 같은 함수를 호출합니다. AddTask 그것은 몇 가지 검증을 수행하고 데이터베이스에 회의를 던집니다.

결국에는 이에 대한 화면을 추가합니다.

============================================================

Event:    [meeting with John, re: login peer review]

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

============================================================

제출을 클릭하면 동일한 AddTask 함수가 호출됩니다.

이것이 고려됩니까?

좋은 코딩 방법
그냥 뉴비들을 위한
끔찍하다!.

부록:

"GUI 및 CLI 실행 파일이 모두 호출 한 공유 라이브러리"에 대한 트렌드를 주목하고 있습니다. 바이너리 자체의 크기를 제외하고는 분리되어야하는 이유가 있습니까?

동일한 실행 파일을 다른 방식으로 호출하면 어떨까요?

"todo /G" 완전한 그래픽 인터페이스를 원할 때
"todo /I" 대화형 프롬프트의 경우 이내에 todo.exe (스크립팅 등)
평범한 오래된 "todo <function>" 한 가지 일만 하고 끝내고 싶을 때.

부록 2:

"[제가] 설명한 방식으로는 GUI가 뭔가를 해야 할 때마다 실행 파일을 생성해야 합니다."라고 언급되었습니다.

다시 한번 말하지만, 이것은 내 의도가 아니었습니다.내가 예제 GUI가 "동일하다"고 언급했을 때 AddTask 함수"라는 말은 GUI가 매번 명령줄 프로그램을 호출한다는 뜻은 아닙니다.나는 그것이 완전히 불쾌한 것이라는 데 동의합니다.나는 이 모든 것이 작은 예제이기 때문에 단일 실행 파일에 보관되도록 의도했지만(첫 번째 부록 참조) 내 표현이 반드시 공유 라이브러리를 배제한다고 생각하지는 않습니다.

또한 귀하의 의견에 감사드립니다.이것은 내 마음 속에 계속해서 떠오르는 것이며 귀하의 경험의 지혜에 감사드립니다.

해결책

나는 라이브러리에 연결되는 명령줄 응용 프로그램을 사용하여 라이브러리를 구축할 것입니다.그런 다음 동일한 라이브러리에 연결되는 GUI를 만들 수 있습니다.GUI에서 명령줄을 호출하면 각 명령에 대한 외부 프로세스가 생성되며 OS에 더 지장을 줍니다.

또한 라이브러리를 사용하면 기능에 대한 단위 테스트를 쉽게 수행할 수 있습니다.

그러나 기능 코드가 명령줄 해석기와 분리되어 있는 한 작업을 수행하기 위해 두 종류를 동시에 사용하지 않고도 GUI용 소스를 재사용할 수 있습니다.

다른 팁

공유 기능을 라이브러리에 넣은 다음 이를 위한 명령줄과 GUI 프런트엔드를 작성하세요.이렇게 하면 레이어 전환이 명령줄에 연결되지 않습니다.

(또한 이 방법은 또 다른 보안 문제를 추가합니다.GUI는 먼저 호출되는 것이 올바른 todo.exe인지 확인해야 하지 않나요?)

Joel은 몇 년 전에 이("unix 스타일") 개발을 GUI 우선("Windows 스타일") 방법과 대조하는 기사를 썼습니다.그는 그것을 불렀다 이중문화주의.

Windows에서는 논리를 .NET 어셈블리로 래핑하는 것이 (아직 그렇지 않은 경우) 일반적인 일이 될 것으로 생각합니다. 그런 다음 GUI와 PowerShell 공급자 모두에서 액세스할 수 있습니다.그렇게 하면 두 세계의 장점을 모두 얻을 수 있습니다.

명시적인 UI가 필요 없이 먼저 백엔드 기능을 프로그래밍하는 기술은(특히 UI가 아직 내 작업이 아닌 경우, 예를 들어 아직 디자인 단계에 있는 웹 애플리케이션을 디자인하는 경우) 단위 테스트를 작성하는 것입니다.

이렇게 하면 백엔드 코드의 출력을 모의하기 위해 콘솔 애플리케이션을 작성할 필요조차 없습니다. 모든 것이 테스트에 포함되어 있으며 콘솔 앱과 달리 테스트용 코드를 버릴 필요가 없습니다. 나중에 유용합니다.

어떤 유형의 애플리케이션을 개발하고 있는지에 따라 다르다고 생각합니다.명령줄을 설계하면 Alan Cooper가 "구현 모델"이라고 부르는 것에 대한 빠른 경로를 얻을 수 있습니다. 수감자들이 정신병원을 운영하고 있다.그 결과, 직관적이지 않고 사용하기 어려운 사용자 인터페이스가 탄생했습니다.

37signals는 또한 사용자 인터페이스를 먼저 디자인하는 것을 옹호합니다. 현실화하기.모든 의도와 목적을 위해 대부분의 애플리케이션에서 사용자 인터페이스는 ~이다 프로그램.백엔드 코드는 이를 지원하기 위해 존재합니다.

기능이 올바른지 확인하려면 먼저 명령줄로 시작하는 것이 더 나을 것입니다.주요 사용자가 명령줄을 사용할 수 없거나 사용하지 않을 경우 작업 위에 GUI를 추가할 수 있습니다.

이렇게 하면 앱이 스크립팅에 더 적합해지고 선불 금액이 제한됩니다. 자전거 타기 실제 솔루션에 더 빨리 도달할 수 있습니다.

앱의 명령줄 버전을 유지할 계획이라면 이 방법으로 수행하는 데 문제가 없을 것입니다. 시간 낭비가 아닙니다.여전히 명령줄에 대한 앱의 주요 기능을 코딩하게 되므로 많은 작업이 완료됩니다.

나는 이런 방식으로 작업하는 것이 멋진 UI에 대한 장벽이라고 생각하지 않습니다. 아직 하나를 추가하고 사용할 수 있도록 만들 시간이 있습니다.

이 작업 방식은 완성된 앱에 명령줄과 GUI 변형이 모두 포함되도록 하려는 경우에만 실제로 작동할 것 같습니다.UI를 흉내내고 거기에 기능을 구축한 다음 나중에 UI를 아름답게 만드는 것은 충분히 쉽습니다.

스튜의 말에 동의하세요:기본 기능은 명령줄 및 GUI 코드에서 호출되는 라이브러리에 있어야 합니다.UI에서 실행 파일을 호출하는 것은 런타임 시 불필요한 오버헤드입니다.

@jcarrascal

왜 이것이 GUI를 "나쁘게" 만들어야 하는지 모르겠습니다.
내 생각에는 그것이 예쁘다는 것에 대해 너무 걱정하지 않고 "비즈니스" 논리가 실제로 달성해야 하는 것이 무엇인지 생각하게 만들 것이라고 생각합니다.무엇을 해야 하고 무엇을 할 수 있는지 알게 되면 가장 적합한 방식으로 인터페이스를 구축할 수 있습니다.

참고 사항:별도의 주제를 시작하는 것이 아니라 질문에 대한 답변/의견을 처리하는 데 선호되는 방법은 무엇입니까?나는 이것을 모두 고려하고 질문 자체를 편집했습니다.

제가 작성한 도구 중 하나에서 정확히 이 작업을 수행했는데 훌륭하게 작동했습니다.최종 결과는 GUI를 통해서도 사용할 수 있는 스크립트 가능한 도구입니다.

GUI를 사용하기 쉽고 직관적으로 만들어야 한다는 생각에는 동의합니다. 따라서 두 가지를 동시에 개발하는 것이 현명할 수도 있습니다.직관적으로 작업을 수행할 수 있도록 GUI 래퍼가 뒤따르는 작은 명령줄 기능입니다.

두 가지를 동일하게 구현하는 데 충실하다면 자동화된 방식으로 사용할 수 있는 앱이 탄생할 것이며, 이는 고급 사용자에게 매우 강력하다고 생각합니다.

나는 보통 클래스 라이브러리와 별도의 정말 형편없고 기본적인 GUI로 시작합니다.명령줄에는 명령줄 구문 분석이 포함되므로 불필요한 오버헤드가 많이 추가되는 것 같습니다.

보너스로 모든 "실제" 코드가 클래스 라이브러리에 있으므로 MVC와 유사한 접근 방식을 제공합니다.물론 이후 단계에서는 라이브러리를 실제 GUI와 함께 하나의 EXE로 리팩터링하는 것도 옵션입니다.

개발을 올바르게 수행했다면 나중에 프로젝트에서 GUI로 전환하는 것이 상대적으로 쉬울 것입니다.문제는 그걸 제대로 하기가 좀 어렵다는 겁니다.

프로그램에 대한 목표에 따라 다르지만, 예, 저는 때때로 이것을 합니다. 코딩이 더 빠르고, 디버그가 더 쉽고, 빠르고 더러운 테스트 케이스를 작성하기가 더 쉽습니다.그리고 코드를 적절하게 구성하기만 하면 나중에 큰 작업을 하지 않고도 다시 GUI에 접근할 수 있습니다.

이 기술을 사용하면 끔찍하고 사용할 수 없는 UI가 발생할 것이라고 제안하는 사람들에게:네가 옳아.명령줄 유틸리티를 작성하는 것은 GUI를 디자인하는 끔찍한 방법입니다.주목하세요, 거기 있는 모든 사람들은 다음과 같은 UI 작성을 생각하고 있습니다. 그렇지 않다 CLUI - CLUI로 프로토타입을 만들지 마세요.

하지만, UI에 의존하지 않는 새로운 코드를 작성하는 경우, 그럼 가보세요.

더 나은 접근 방식은 잘 정의된 API를 사용하여 논리를 lib로 개발하는 것이며, 개발 단계에서는 인터페이스(또는 하드 코딩된 인터페이스) 없이 나중에 CLI 또는 GUI를 작성할 수 있습니다.

나는 몇 가지 이유로 이것을하지 않을 것입니다.

설계:

GUI와 CLI는 기본 구현에 액세스하는 데 사용되는 두 가지 다른 인터페이스입니다.이들은 일반적으로 다양한 목적으로 사용되며(GUI는 실제 사용자를 위한 것이고 CLI는 일반적으로 스크립팅을 통해 액세스됨) 요구 사항이 다를 수 있는 경우가 많습니다.두 가지를 함께 결합하는 것은 현명한 선택이 아니며 앞으로 문제를 일으킬 수밖에 없습니다.

성능:

설명했던 방식대로 GUI가 작업을 수행해야 할 때마다 실행 파일을 생성해야 합니다.이것은 정말 추한 것입니다.

이를 수행하는 올바른 방법은 CLI와 GUI 모두에서 호출되는 라이브러리에 구현을 넣는 것입니다.

John Gruber는 GUI용으로 설계되지 않은 프로그램에 GUI를 추가하는 개념에 대한 좋은 게시물을 올렸습니다. Ronco 스프레이 온 유용성

요약:작동하지 않습니다.유용성이 처음부터 응용 프로그램에 설계되지 않은 경우 나중에 추가하는 것은 누구보다 더 많은 작업입니다.

@Maudite

명령줄 앱은 매개변수를 미리 확인하지만 GUI는 그렇지 않습니다. 하지만 여전히 매개변수를 확인합니다. 같은 매개변수를 사용하여 일부 일반 작업자 함수에 입력합니다.

여전히 같은 목표입니다.GUI 품질에 영향을 미치는 명령줄 버전은 보이지 않습니다.

웹 서비스로 노출되는 프로그램을 수행하십시오.그런 다음 GUI와 명령줄을 사용하여 동일한 웹 서비스를 호출합니다.또한 이 접근 방식을 사용하면 웹 GUI를 만들 수 있고, 엑스트라넷 파트너에게 SaaS 기능을 제공하거나 비즈니스 로직을 더욱 안전하게 보호할 수도 있습니다.

또한 이를 통해 프로그램이 SOA 환경에 보다 쉽게 참여할 수 있습니다.

웹 서비스의 경우 너무 지나치지 마십시오.yaml 또는 xml-rpc를 수행하십시오.간단하게 유지하세요.

무엇 외에도 스투 공유 라이브러리가 있으면 웹 애플리케이션에서도 사용할 수 있습니다.또는 IDE 플러그인에서도 가능합니다.

이런 식으로 하는 것이 좋지 않은 데에는 몇 가지 이유가 있습니다.많은 내용이 언급되었으므로 구체적인 사항 하나만 언급하겠습니다.

명령줄 도구는 일반적으로 전혀 대화형이 아니지만 GUI는 대화형입니다.이것은 근본적인 차이점입니다.예를 들어 이는 장기 실행 작업의 경우 고통스럽습니다.

명령줄 도구는 기껏해야 일종의 진행 정보(개행, 텍스트 진행률 표시줄, 여러 출력 등)를 인쇄합니다.모든 종류의 오류는 콘솔에만 출력될 수 있습니다.

이제 그 위에 GUI를 추가하고 싶으면 어떻게 합니까?장기 실행 명령줄 도구의 출력을 구문 분석하시겠습니까?해당 출력에서 WARNING 및 ERROR를 검색하여 대화 상자를 표시하시겠습니까?

기껏해야 이런 방식으로 구축된 대부분의 UI는 명령이 실행되는 동안 진동하는 사용 중 표시줄을 표시한 다음 명령이 종료되면 성공 또는 실패 대화 상자를 표시합니다.안타깝게도 이것은 많은 UNIX GUI 프로그램이 함께 사용되는 방식이므로 끔찍한 사용자 경험이 됩니다.

여기에 있는 대부분의 응답자는 프로그램의 실제 기능을 라이브러리로 추상화한 다음 명령줄 인터페이스와 GUI를 동시에 작성해야 한다고 말하는 것이 맞습니다.모든 비즈니스 로직은 라이브러리에 있어야 하며 UI(예, 명령줄은 UI입니다)는 비즈니스 로직과 UI 간 인터페이스에 필요한 모든 작업만 수행해야 합니다.

나중에 GUI를 사용할 수 있을 만큼 좋은 라이브러리를 개발하기에는 명령줄의 UI가 너무 열악합니다.처음부터 둘 다 시작하거나 GUI 프로그래밍으로 시작해야 합니다.GUI용으로 개발된 라이브러리에 명령줄 인터페이스를 추가하는 것은 쉽지만, GUI에 필요한 모든 대화형 기능(보고, 진행, 오류 대화 상자, i18n 등) 때문에 그 반대의 경우가 훨씬 더 어렵습니다. )

명령줄 도구는 GUI 앱보다 적은 수의 이벤트를 생성하며 일반적으로 시작하기 전에 모든 매개변수를 확인합니다.GUI의 경우 프로그램이 작동할 때나 그 이후에 매개변수를 요청하는 것이 더 합리적일 수 있으므로 GUI가 제한됩니다.

GUI에 관심이 없다면 걱정하지 마십시오.최종 결과가 GUI인 경우 먼저 GUI를 만든 다음 명령줄 버전을 수행하세요.아니면 동시에 두 가지 작업을 모두 수행할 수도 있습니다.

--대규모 편집--

현재 프로젝트에 시간을 보낸 후, 이전 답변에서 완전한 원점으로 돌아온 것 같은 느낌이 들었습니다.내 생각에는 먼저 명령줄을 수행한 다음 그 위에 GUI를 래핑하는 것이 더 낫다고 생각합니다.필요하다면 나중에 훌륭한 GUI를 만들 수 있다고 생각합니다.명령줄을 먼저 수행하면 모든 인수를 먼저 내려놓을 수 있으므로 UI/UX를 수행할 때 (요구 사항이 변경될 때까지) 놀랄 일이 없습니다.

이것이 바로 코딩에 관해 내가 깨달은 가장 중요한 깨달음 중 하나이며, 더 많은 사람들이 그러한 접근 방식을 취하기를 바랍니다.

한 가지 사소한 설명:GUI는 명령줄을 감싸는 래퍼가 되어서는 안 됩니다.대신 GUI나 명령줄에서 프로그램의 핵심을 구동할 수 있어야 합니다.최소한 처음에는 기본적인 작업만 수행합니다.

언제 이것이 좋은 생각입니까?

도메인 구현이 GUI 프레임워크와 독립적인지 확인하려는 경우.코딩을 원하시나요? 약 프레임워크가 아닌 ~ 안으로 프레임 워크

이것이 언제 나쁜 생각입니까?

프레임워크가 결코 죽지 않을 것이라고 확신할 때

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow