사용자 인터페이스 클래스를 명령 행 인터페이스로 대체 할 수 있다고 생각하는 아키텍처를 설계하는 것이 좋습니다.

코드 완성 페이지 25에서 일반 사용자 인터페이스 클래스를 명령 행 1로 쉽게 대체 할 수있는 것이 좋습니다.

테스트의 장점을 알고 있으면 어떤 문제가 발생할 수 있습니까?

이 추가 작업이 웹 및 모바일 프로젝트에 실제로 도움이됩니까? 중소 프로젝트는 어떻습니까? 동일한 규칙이 적용됩니까? 디자인이 더 복잡해지면 어떨까요?

다른 인터페이스 (예 : GUI vs CLI vs REST)에서 기능을 재사용 할 수있는 것은 항상 필요하지는 않지만 다른 사람들이 시스템과 상호 작용하는 새로운 방법을 찾을 때 시스템에 대한 재사용 을 활성화하고 활성화 하는 것이 좋습니다.

여기에는 가중치가 필요한 몇 가지 단점이 있습니다.

1. 추가 추상화 계층 (때로는 계층)이 필요합니다. 이러한 계층을 갖추는 것이 좋은 엔지니어링 관행이지만 개발, 추가 비용이 들기 때문에 다른 영역 (예 : 유지 관리, 재사용, 테스트)에서 노력을 줄일 수 없으므로 이해해야합니다.
2. 매체에 최적 인 흐름은 다른 사람에게는 끔찍할 수 있습니다. 기능이 GUI를 지원하도록 설계 되었으면 웹에 너무 번잡 할 수 있습니다 . 모든 매체에서 모든 기능이 가치있는 것은 아닙니다.
3. 서비스와 사용자 인터페이스 사이에 일반 변환기를 정의하려는 함정이 있으므로 서비스 계약을 정의하고 모든 매체의 UI를 자동으로 (또는 가능한 많이) 파생시킬 수 있습니다. 많은 프로젝트가 그러한 프레임 워크를 구축하고 요구 사항이 변경됨에 따라 가능한 모든 사용자 정의를 추가하는 데 너무 많은 노력을 낭비했습니다.

그러나 이러한 계층을 구현 한 경험에서 항상 노력을 기울였습니다. 몇 가지 경우에 만기일 몇 주 전에 미디어 (예 : 웹 서비스 통합에서 UI로)를 교체해야했기 때문에 제 시간에 시스템을 배포했습니다.

테스트와는 별도로,이 접근 방식의 확실한 장점은 프로젝트를 자동화 하고 스크립팅 할 수 있다는 것입니다 . 명령 행 명령을 프로그램에 보낼 수 있으면 GUI에서 동일한 것을 자동화하는 매크로를 작성할 수있는 것보다 복잡한 작업을 훨씬 더 쉽고 안정적으로 수행하는 스크립트를 작성할 수 있습니다.

물론 실제로 가치가 있는지 여부는 전적으로 프로그램을 자동화하려는 많은 사용자가 있는지 여부에 달려 있습니다.

추가 작업이 아니라 다른 작업입니다. 올바르게 수행하면 더 복잡하지 않을뿐만 아니라 디자인을 분리해야하기 때문에 더 단순 해집니다. 실제로 CLI를 구현하는지 여부에 관계없이 디자인을 수행하는 것이 더 좋습니다.

언급되지 않은 한 가지 주요 이점은이 작업을 수행 할 수 있다는 것이 기본 코드에서 UI를 엄격하게 분리 한다는 것입니다. 이것의 한 가지 주요 장점은 GUI를 크게 변경해야하는 경우 (예 : iOS 표준을 OSX 표준으로 또는 그래픽 엔진을 다른 것으로 변경), 기본 코드가 종속되어 있지 않기 때문에 변경해야하는 모든 것입니다. UI의 레이아웃 그것은 할 수없는 것이 있다면, 명령 줄 도구가 작동하지 않기 때문에, 수.

그 외에 테스트를 자동화 할 수 있다는 것이 주요 이점입니다.

예, 거의 항상 좋은 생각입니다.

이 접근 방식을 따르는 경우 GUI와 동일한 스레드에서 일부 GUI 처리기 뒤에 비즈니스 로직 또는 데이터 액세스 권한이 없을 수 있습니다. 이 이유만으로도 투자 가치가 있습니다.

나는 그것이 좋은 생각이라고 생각합니다. 또한 두 번째 명령 줄 프런트 엔드를 작성할 수 있으므로 궁극적으로 비즈니스 논리가 특정 응용 프로그램 서버 아키텍처와 완전히 분리되어 있음을 증명합니다.

이 작업에서 내가 볼 수있는 유일한 위험은 UI의 특정 부분에 도달하려면 사용자가 일반적으로 UI의 다른 부분을 통과해야한다는 것입니다.

개발자는 UI를 직접 실행할 수 있습니다. 개발자가 실제로 제품을 사용할 때까지 사용자 문제를 재현 할 수없는 상황을 보았습니다.

따라서 테스트를 만들 때도 고려해야합니다.

끔찍한 충고

약간 yagni입니다 (필요하지는 않습니다).

명령 줄 인터페이스를 노출하는 것은 단위 테스트를 지원하거나 SOLID의 일부 또는 권장하는 프로그래밍 방법을 준수하는 방식으로 앱을 구성하는 것과 다릅니다.

커맨드 라인 인터페이스에 적합하지 않은 UI에서는 작동하지 않습니다. MS Paint는 정말 간단한 앱이지만 어떤 상황에서 명령 줄에서 제어 할 수있는 이점이 있습니까?

스크립팅을 구현하는 데 도움이되지 않습니다. 실제로 그 방향으로 진행되는 것을 방해합니다.

유일한 긍정적 인 점은 25 페이지에 나타나기 때문에 적어도 책의 나머지 부분이 냄새가 날 수 있다는 경고가 나타납니다. 나는 오래 전에 그것을 읽었고 그것을 좋아하지 않았기 때문에 편견이 있습니다.

Mason Wheeler의 말을 바탕으로 명령 줄을 통해 응용 프로그램과 상호 작용할 수있어 작업을 매우 쉽게 자동화 할 수 있습니다.

이것은 테스트에 특히 유용합니다.

실제 예제를 제공하기 위해 응용 프로그램에서 자동 테스트를 실행하려면 응용 프로그램을 자동으로 설치하고 싶을 수 있습니다. 이를 위해 "myApplication.exe / silentinstall"매개 변수를 전달할 수 있습니다.

이 명령 행 스위치를 지정할 때 GUI 설치 프로그램없이 백그라운드에서 자동으로 설치가 수행되도록 프로그래밍 할 수 있습니다. 설치 프로그램에 대한 입력 (예 : 설치 디렉토리)은 XML 파일에서 선택할 수 있습니다.

다른 예를 들어 보자. Visual Studio와 함께 제공되는 Microsoft Test Manager GUI를 사용하면 GUI 인터페이스에서 테스트 실행을 시작할 수 있지만 명령 줄 스위치와 입력 조합을 사용하여 동일한 작업을 수행 할 수있는 명령 줄 인터페이스도 제공합니다. 즉, 테스트 실행을 자동화하기 위해 PowerShell 또는 DOS 스크립트를 함께 채울 수 있으며 스크립트가 매일 밤 실행되도록 예약 된 작업을 만들 수 있습니다.

일부 응용 프로그램에는 특정 옵션으로 응용 프로그램을 열도록 지정하는 명령 줄 스위치가 있습니다 (예 : '/ maximize'를 사용하여 응용 프로그램을 최대화 된 창에서 열 수 있음).

명령 행 인터페이스를 사용할 수있는 시나리오가 많이 있습니다. 이것들은 몇 가지 예일뿐입니다.

"일반 사용자 인터페이스 클래스를 명령 행 1로 쉽게 대체 할 수있는 것이 좋습니다"라는 문구를 다시 한 번 주목하십시오. 그렇다고 CLI를 작성해야한다는 의미는 아니며 쉽게 수행 할 수 있다는 것입니다.

즉, UI가 나머지 코드에서 분리되어야한다는 것입니다.

그것은 의존 하고 내가 의존한다고 말할 때, 그것은 단지 몇 가지 우연한 사례를 갖는 것의 문제 일뿐 만 아니라 응용 프로그램과 대상 청중에 크게 의존합니다. 우리가 방정식에서 게임을 제거한다고 가정하면, 같은 명령이 거의 없거나 전혀 구현되지 않는 곳에 작성하는 응용 프로그램이 여전히 많이 있습니다. 내 머리 위에는 모바일 (예 : iOS, Android 등) 환경을 대상으로하는 모든 응용 프로그램이이 제목에 해당 할 수 있습니다.

이를 염두에두고 일반적인 소프트웨어 공간에서 시각화 (예 : PowerPoint, Maya 등)에 크게 의존하는 응용 프로그램 은 명령 줄 교체가 구현되지 않을 것입니다. 실제로 Maya와 같은 그래픽 소프트웨어의 경우, 완전하고 적절한 명령 행 버전이 작동하는 방식을 결정하는 것이 바람직한 정신 운동 일 수 있으며 사용자 관점에서 그렇게하지 못할 수도 있습니다. 따라서, 인터페이스와 같은 명령이 보이지 않을 수 있거나 응용 프로그램의 스크립팅이 바람직한 경우에도 바람직한 공통적 인 응용 프로그램이있을 수 있음이 분명합니다.

다음으로 일반적인 소프트웨어 아키텍처의 관점을 제안 양식에서 살펴보면 "사용자 인터페이스없이 어떻게이 기능에 액세스 할 수 있습니까?" 일반적으로 수행 할 방법이없고 사용자와 직접 상호 작용하지 않는 경우 (예 : 제스처 입력) 전체 아키텍처를 개선해야하는 상황이있을 수 있습니다. 테스트를 쉽게하기 위해 명령 행을 통해 호출되지 않더라도 사용자 인터페이스를 통하지 않고 명령에 직접 액세스 할 수 있어야합니다. 이것은 일반적으로 견고한 API가 있어야하며 이론적으로는 우수한 API가 명령 줄 또는 사용자 인터페이스를 통한 액세스를 허용해야한다는 것을 의미합니다. 또한 장기적으로

하루가 끝나면 제안이 이해하려고하는 것이 의미가 있다고 생각합니다 (예 : 좋은 API를 가지고 사용자 인터페이스를 구축하십시오). .

따라 다릅니다.

종종 프로그램을 모델 / 뷰 / 컨트롤러 또는 모델 / 뷰 / 뷰 / 모델로 분할합니다. 모델이 명령 줄 액세스를 허용 해야하는 것처럼 보이지만 컨트롤러에 대해서는 확실하지 않습니다. 당연히, 시야가 대체되고 있습니다.

툴 체인에 따라 약간의 차이가있을 수 있습니다. Code Complete는 Microsoft Press 서적이므로이 GUI에 Microsoft 기술을 사용하고 있습니까? 그렇다면 COM 또는 DCOM을 통해 인터페이스를 노출하기위한 앱을 만들 때 확인란이있을 수 있습니다. 일부 Microsoft 기술의 경우, 리소스 테이블과 메시지 전달은 마법사가 신속하게 프로토 타입을 만드는 데 도움이되는 모든 것과 매우 집중적으로 결합됩니다. 점점 나아지고 있다고 생각하지만 MFC 또는 양식을 유지 관리하면 약간 다칠 수 있습니다.

경우에 따라 GUI 기반 프로그램은 관리 인터페이스를 둘러싼 래퍼이거나 자체 로직이 거의 없어서 명령 행 인터페이스로 제어 할 것이 많지 않을 수 있습니다. 별도의 콘솔 앱을 구축하는 것이 더 빠르지 만 여전히 중요한 것을 스크립트, 테스트 또는 사용할 수 있습니다.

내가 생각하는 핵심은 제안이 규칙이 아니라는 것입니다. 이를 따르는 경우, 사용자 또는 고객이 클릭 대신 입력을 선호 할 수있는 더 쉬운 단위 및 승인 테스트 또는 대체 인터페이스가 제공됩니다. 그것이 스스로를 지불한다면 그렇게하십시오. 행운을 빕니다.

명령 행 프로그램의 유용성에 따라 다릅니다. 지도에 경로를 플롯하거나 3D 게임을하는 것과 같은 일부는 명령 행 인터페이스에 적합하지 않습니다. 그러나 시스템 도구와 같은 다른 것들은 GUI를 사용하는 것보다 명령 줄을 사용하는 것이 훨씬 더 좋습니다.

Richard Hipp 박사는 자신의 이상적인 GUI 운영 체제는 명령 창을 여는 아이콘과 웹 브라우저를 여는 다른 아이콘이있는 빈 데스크탑이라고 말했습니다. 거의 같은 느낌입니다. 명령 줄 프로그램으로 유용하고 그렇게 만드는 것이 어렵지 않다면 그렇게 할 것입니다. GUI는 완전히 다른 프로그램 일 수도 있고 다른 누군가가 만들 수도 있습니다!

요즘 (적어도 Java의 경우) 조만간 모든 프로그램이 조만간 웹 서비스 (SOAP 또는 Ajax 또는 둘 다)를 추가하는 것처럼 보입니다. 따라서 일반적으로 그렇습니다.하지만 더 나은 정신적 은유를 원한다면 웹 서비스 프론트 엔드가 명령 줄보다 가능성이 높습니다.

사물을 보는 다른 방법이 있습니다. 명령 행이 유일한 방법이라고 가정하는 대신, 음성 제어를 대신 사용할 수 있다고 가정하지 않겠습니까? 그러면 완전히 다른 패러다임이 필요합니다.

Jobs가 Apple을 인수하기 전에 매우 정교한 음성 제어 메커니즘을 탐색했습니다. 애플은 시리 (Siri)와 같은 것들을 위해 이것을 제압했다.

한숨.

대중적이고 명백한 것이 항상 "최고"인 것은 아닙니다.

이것은 일반적으로 좋은 생각입니다.

비 유적으로 사람들은 이것을 RESTful 디자인의 한 형태로 생각할 수 있습니다. .... 그 자체로는 전형적인 (G) UI가 계정 생성과 같은 복잡한 다단계 트랜잭션을 포함 할 수 있기 때문에 아닙니다.

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

브라우저에서 드래그 앤 드롭 UI 비유를 한 번 프로그래밍했습니다. UX가 자연스럽게 느껴지도록 백엔드에서 매우 복잡한 상호 작용 규칙 사이트를 API로 만들어이 문제를 해결했으며 GUI는 작업시 이벤트를 생성하는 전체 앱이었습니다. 모듈은 이러한 이벤트를 포착하고 타이머에서이를 'API 호출'(네트워크 효율성을 위해)으로 묶었습니다.

결과는 완전히 RESTful 핵심 시스템이었습니다. 두 번째 결론은 비즈니스 모델에 따라 제휴 프로필을 사용하여 노출 할 수있는 타사 인터페이스가 있다는 것입니다.

한 가지 장점은 사용자 관점에서 UI의 흐름에 대해 생각해야한다는 것입니다. (무엇을 달성하려고합니까? 어떤 컨텍스트를 설정해야합니까? 해당 컨텍스트가 주어지면 어떻게 목표를 달성합니까?)

"은행 계좌 만들기"와 "MS 워드 문서 쓰기"에는 큰 차이가 있습니다. CLI를 작성하지 않더라도 필요한 "CLI 컨텍스트"를 고려하기 위해 값을 추가 할 수 있습니다. 모델은 비즈니스 객체 모델에만있는 것이 아닙니다!