GUI로 시작하는 응용 프로그램을 작성하는 것이 유용 할 수 있습니까?

응용 프로그램 디자인 및 개발 트렌드는 도메인, 데이터 액세스, 인프라 등 "거트"로 시작하는 것 같습니다. GUI는 일반적으로 프로세스의 후반에 나오는 것 같습니다. GUI를 먼저 빌드하는 것이 유용 할 수 있는지 궁금합니다.

저의 이론적 근거는 최소한 프로토 타입 GUI를 구축함으로써이면에서 어떤 일이 발생해야하는지 더 잘 이해할 수 있으며 도메인 작업과 코드 지원 작업을 시작할 수있는 더 나은 위치에 있다는 것입니다.

지원 코드가 아직 작성되지 않은 경우 GUI 계층에서 실제로 수행 할 작업이 많지 않다는 점에서이 방법의 문제점을 볼 수 있습니다. 아마도 모의 객체 또는 클래스를 빌드하는 것 (단위 테스트에서 수행되는 것과 같은 것)은 처음에 GUI를 구축하기에 충분한 기초를 제공했을 것입니다.

이것이 실제 프로젝트에 적합한 아이디어 일 수 있습니까? 어쩌면 우리는 약어에 GDD (GUI Driven Development)를 추가 할 수 있습니다 ...

빠른 GUI 프로토 타입을 작성하는 것이 좋은 생각이며, 많은 프로젝트에서 사용되는 것을 들었습니다. 조기 피드백은 실제로 가치가 있습니다. 그러나 다음과 같은 위험이 있습니다.

• 프로토 타입 코드를 더 사용하고 최종 응용 프로그램을 빌드하는 것이 매우 유혹적입니다. 장기적으로 나쁜 결과를 초래할 수 있습니다 (실제로 내가 작업 한 프로젝트 중 하나에서 발생하여 결과 존재하지 않는 아키텍처와 많은 유지 관리 문제가있는 "작동하는"제품)
• 일반 사용자의 경우 GUI는 응용 프로그램 입니다. 따라서 멋진 GUI를보고 나면 대부분의 실제 작업이 완료되었다고 생각하는 경향이 있으므로, "남은 작업이 거의 없습니다"라는 말로 너무 화가 날 것입니다.

이러한 위험을 완화하려면 사용자 및 / 또는 관리자에 대한 적극적인 토론과 교육이 필요합니다.

내가 볼 수있는 문제는 목표가 완전히 역전 된 것 같습니다.

"나의 이론적 근거는 최소한 프로토 타입 GUI를 구축함으로써이면에서 어떤 일이 발생해야하는지에 대한 더 나은 아이디어를 얻을 수 있으며 도메인에서 작업하고 코드를 지원할 수있는 더 나은 위치에 있다는 것입니다."

제 생각에 이것은 비즈니스 계층을 보는 잘못된 방법과 열악하고 확장 불가능한 디자인을 찾는 훌륭한 방법입니다. 데이터를 완벽하게 표현하도록 설계된 데이터 계층은 모든 UI에서 사용할 수 있습니다. 특정 UI의 요구에 맞게 작동하도록 설계된 데이터 계층은 다른 UI에는 적용 할 수 없으며 해당 UI에 사소한 기능 추가조차 포함되지 않을 수 있습니다.

말하는 방식으로 설계된 시스템을 사용한 경험을 통해이 방법론을 사용하는 대부분의 디자인은 수명이 짧고 복잡하다는 결론을 내릴 수 있습니다. 또한 UI와 데이터 계층간에 커플 링을 생성하는 경향이 있습니다.

데이터 계층과 UI 계층의 독립성을 권장해야합니다. 이것이 바로 특정 UI를 대상으로하는 것이 아니라 전체 데이터를 나타 내기 위해 데이터 계층을 구축하는 것이 장기적으로 더 잘 작동하는 이유입니다.

프로토 타입 제작은 요구 사항 수집 및 동의에 적합하지만 폐기해야합니다. 실제 제품의 프로토 타입 코드에서 실제로 아무것도 사용하지 마십시오.

@ Péter는 GUI 프로토 타입 제작이 좋은 아이디어라고 제안하는 것이 옳다고 생각합니다. 나는 온톨로지, 아키텍처 및 인프라에 먼저 초점을 맞추고 즉각적인 사용자 경험에 중점을 두어 사용자 경험을 제공하는 잠재적 인 함정을 보완하고 싶습니다.

• 개발 타임 라인의 끝까지 밀었던 사용자는 데이터 추정 및 응용 프로그램 사용 방식을 무효화합니다.
• 조기에 개발 한 정교한 디자인은 결국 거의 사용하지 않거나 거의 사용하지 않는 자체 용도의 기계 가공임을 입증합니다.
• 사용자 환경이 열악한 상태로 응용 프로그램이 표준이 될 수 있습니다.

당신은 내장을하고 나서 사용자는 당신의 가정에서 나온 것을 얻습니다. 반면에, 사용자가 필요로하는 것에 관심을 갖고 그에 따라 내장을 구축해야합니다. 사람들이 다른 방식으로 그것을 사용하는 이유는 단순히 응용 프로그램의 동작이 자연스럽게 거품이 나는 곳에서 사용자와 상호 작용하는 프레젠테이션이 완전히 탐색되지 않거나 사람들이 느끼는 가장 복잡한 시스템의 부분이기 때문입니다. 그들이 왜 / 무엇을 / 누구를 위해 그것을 건설하고 있는지 실제로 생각 해야하는 것을 피하면서 물건을 짓는 것에 대해 행복합니다. 구조적으로 건전한 거대한 구조물을 세우는 것은 어린이의 놀이이며, 모든 사람의 기능적 (미적) 요구를 충족시키는 것이 가장 어려운 부분입니다.

각 craptastic 경험을 위해, 제대로 배치 정보 흐름 기발한 명백한 기능의 그냥 일반 잘못된 것들, 당신은 "단지 어떤 천재 해낸 물어달라고 애원했습니다 때마다 인스턴스 부족 이 무시 부정 또는?"거짓말 뭔가를 개발 노력의 최전선으로 사용자를 공개했습니다.

일반적으로 모델은보기 전에 개발해야합니다. 응용 프로그램의 논리적 기반을 갖추면 해당 모델의 뷰를 하나 이상 만들 수 있습니다 (예 : 테이블 또는 그래프로 데이터를 표시 할 수 있음). 일반적으로 모델이 GUI보다 중요합니다. GUI가 일반적으로 표준 방식으로 수행되는 엔터프라이즈 개발의 경우 특히 그렇습니다.

그러나 때로는 GUI가 실제로 응용 프로그램에서 가장 중요한 부분입니다. 때로는 새롭고 구체적인 방식으로 데이터를보고 싶어서 데이터를 가져 와서 모델을 개발하기도합니다. 예를 들어, CashCurve 는 포인트가 GUI에있는 응용 프로그램이며 데이터 모델 자체는 누구나 몇 분 안에 모델링 할 수있는 표준 지루한 작업입니다. (면책 조항 : 저는 CashCurve와 제휴하지 않으며 매우 만족스러운 사용자입니다.)

이것은 웹 서비스 또는 다른 API 디자인과도 관련이 있으며 " 계약 우선 "디자인 으로 만 알려져 있습니다.

따라서 모든 것에 관해서는 먼저 무엇을 디자인해야하는지에 대한 규칙은 없습니다. 때로는 모델이고 때로는 GUI입니다. 경험상, 나는 "가장 중요한 부분을 먼저 디자인"하는 것으로 진행합니다.

GUI를 처음 디자인 할 때 고려해야 할 경고가 있습니다. 예를 들어 GUI 프로토 타입 만 존재하는 경우 응용 프로그램이 완료되지 않았다는 것을 이해하는 데 어려움을 겪을 수 있지만 다른 답변은이 부분을 잘 다루므로 자세한 내용은 다루지 않겠습니다.

특히 민첩한 개발 환경에서 응용 프로그램 디자인에 접근하는 매우 좋은 방법이라고 생각합니다. 내가 작업 한 성공적인 프로젝트의 대부분은 결국 실제가 된 프로토 타입으로 시작되었습니다.

GUI는 시스템 (예 : 데이터베이스, 파일 시스템 등)의 창이라는 것을 이해해야합니다. 프로젝트 요구 사항이 슬러시 파일처럼 모호한 상황에서는 백엔드에서 시작하여 올바른 솔루션을 얻는 데 희망이 없습니다. 거의 항상 잘 계획된 백엔드 개발자는 사용자 상호 작용과 관련이없는 많은 API를 개발합니다.

GUI에서 시작하면 고객이 원하는 것을 더 잘 이해할 수 있습니다. 이 단계가 진행됨에 따라 (모의와 스텁을 사용하여) GUI의 개발은 도메인 모델을 낳습니다. 그런 다음이 도메인 모델을 백엔드로 전송할 수 있으며 백엔드 개발자는 지속성 및 트랜잭션 논리 개발을 시작할 수 있습니다.

그리고 왜 protoype를 버리고 싶습니까? 우리는 성냥개비로 지어진 경기장을 다루지 않습니다. 빌어 먹을 것을 좋은 것으로 리팩터링하십시오.

GUI를보고있는 사람이 그것이 단지 쉘이고 문자 그대로 버튼과 프로세스가 작동하지 않는다는 것을 이해하면 전혀 나쁘게 들리지 않습니다 (새로운 NotImplementedException ();;)).

MVC 스타일 아키텍처를 고집한다면, "보기"가 그런 종류의 것을 전혀 정의하지 않기 때문에 향후 유지 보수 또는 구성 문제를 예측하지 않습니다. "컨트롤러"및 "모델"은 확장 성 / 디자인 요구 등에 필요한 모든 인프라와 함께 나중에 제공 될 수 있습니다.

관리와 관련하여 3 부분으로 된 큰 원형 차트를 그려 "M", "V"및 "C"로 레이블을 지정하십시오. V에 약 20 %를주고 나머지 파이는 "TBC"라고 설명합니다.

합리적인 규모의 시스템에서 장면 뒤에서 발생해야하는 것은 GUI의 모양과 거의 관련이 없습니다. GUI는 일부 요구 사항 만 제공합니다. GUI가없는 많은 구성 요소가 있습니다.

시스템이 개발 된 후 추가 인터페이스 (새 GUI 포함)가 필요할 수 있습니다. 이를 위해서는 비즈니스 요구 사항을 이해하고 구현하는 것이 중요합니다.

GUI 및 기타 입력 및 출력 메커니즘을 설계하면 모델을 검증 할 수 있습니다. 출력되지 않는 속성은 필요하지 않을 수 있습니다. 이를 유지해야하는 이유가있을 수 있지만 감사 또는 규제 기관 요구 사항 일 수 있습니다.

다른 사람들이 언급했듯이 일단 GUI를 사용하면 많은 클라이언트가 당신이 끝났다고 생각할 것입니다. 그러나 그 뒤에는 인프라가 없을 수도 있습니다. 종이 프로토 타입은 GUI의 레이아웃과 내용을 검증하는 좋은 옵션 일 수 있습니다.

개발 후에 인터페이스를 조정해야 할 수도 있다는 것을 간과하지 마십시오. 5 단계 체크 아웃 프로세스에서 실패한 체크 아웃 인터페이스 교체에 대한보고를 들었습니다. 훨씬 간단한 인터페이스는 사용자에게 적절한 보안 느낌을주지 않았으며 완료율이 훨씬 낮았습니다. 스피드 범프 : 마케팅의 마법 성분을 들어보십시오 .