프로토 타입과 프로덕션 레벨 솔루션의 차이점은 무엇입니까?

이 질문은 순전히 배우고 기술적 인 이해를 높이기위한 것입니다. 완벽한 솔루션이 없다는 것을 알고 있으며이 질문으로 솔루션 목록을 끝낼 수는 없지만 모든 건축가가 데모와 실제 프로젝트의 차이점을 이해하는 것이 매우 중요하다고 생각합니다.

과거에 .Net에서 많은 데모 솔루션을 만들었습니다. 저는 이제 프로덕션 레벨 웹 솔루션을 설계하고 구현하도록 지정되었으므로 데모를 프로덕션 레벨 솔루션으로 변환하는 데 필요한 사항을 매우 높은 수준으로 묻고 싶었습니다. 내 이해에서, 이것은 (고객의 요구 사항을 기능적으로 구현하는 것 이외) 필요합니다.

1. 모든 방법의 단위 테스트
2. ~ 100 % 코드 적용 보장
3. 모든 예외 및 가능한 포인트 컷 기록-AOP로 가능
4. 인터페이스 디자인 패턴, 의존성 주입 사용, spring.net과 같은 프레임 워크 사용
5. 계측에 성능 카운터 및 프로파일 러 사용
6. 적절한 보안 적용 – 즉, Windows 인증 (클라이언트가 요구하는 경우).
7. 모든 단일 방법에 대한 트랜잭션 관리
8. 솔루션을 새로 배포하기 전에 웹 응용 프로그램 파일 백업

또 뭐요?

내 질문은 기능 / 문서 대신 기술 측면과 관련이 있습니다. 그렇지 않으면 우리는 다른 길로 갈 것입니다 :-)

감사합니다.

가장 중요한 차이점은 프로토 타입의 목표는 다음과 같습니다.
1. 문제가 특정 방식으로 해결 될 수 있음을 증명하기 위해 또는
2. 고객 / 관리자에게 제품의 모양과 느낌에 대한 느낌을줍니다.

라이브 시스템의 목표는 다음과 같습니다.
1. 특정 문제를 해결하고 문제를 해결합니다.

이 둘의 목표는 완전히 다릅니다 .
따라서 제 생각 에는 라이브 시스템을 개발하기 전에 프로토 타입을 버려야합니다 .

프로토 타입은 일반적으로 '빠르고 더러운'프로젝트이기 때문에 테스트, 성능, 보안 등과 같은 질문에서 올바르게 지적한 사항없이 함께 던져집니다.
따라서 나쁜 프로젝트를 개선하는 것보다 새롭고 적절한 프로젝트를 시작하는 것이 좋습니다.

요구 사항에 따라 이러한 사항이 모두 필요한 것은 아니며 더 많은 방법이 필요할 수도 있습니다. 내가 무슨 뜻인지 안다면;) 단위 테스트와 코드 적용은 좋은 일이지만, 프로세스의 다른 부분에 대한 방법에 따라 필요하지 않을 수도 있습니다. 어떤 사람들은 성능 프로파일 링보다 더 중요한 것은 잘 문서화 된 코드 또는 교육 매뉴얼이라고 말합니다. 그건 다양하다!

나는 당신이 기술적 인 측면을보고 있다는 것을 알고 있지만 내 요점을 이해할 것입니다. 기술적이지 않은 측면에 따라 다릅니다. 아니면 적어도 그래야합니다.

인스 트루먼 테이션에 성능 카운터 및 프로파일 러를 사용하는 것이 적합하지만 과도하게 과도 할 수 있습니다. 필요하지 않을 수 있습니다.

여기서 누락 된 것은 프로젝트의 컨텍스트, 범위 및 비즈니스 요구 사항을 설명하지 못했습니다.

맥락과 범위에 따라 내 비즈니스에서 사용할 무언가를 만들고 있습니까? 고객 대면? 최종 사용자가 사용합니까? 실제로 재즈 버전의 메모장입니까, 아니면 새로운 RDBMS입니까? 포함해야 할 것은 당신이보고있는 프로젝트에 따라 엄청나게 다양합니다.

비즈니스 요구 사항에 따라 소프트웨어의 사용 사례가 아니라 프로젝트 관리 / 생산 프로세스의 요구 사항을 의미합니다. 생산 프로젝트에 필요한 모든 것을 요구하면 비용이 그에 따라 반영됩니다 (매우 높음). 그것은 예산을 초과했거나, 늦었거나, 개발을 시작하라는 신호를받지 않았 음을 의미 할 수 있습니다.

고정 된 기준을 갖는 것보다 더 중요한 것은 단순히 좋은 생산 / 개발 프레임 워크, 높은 가시성 및 정기적 인 릴리스를 갖는 것이므로 품질을 그런 식으로 평가할 수 있습니다. 관련된 사람 중 누구도 코드 범위에 대해 불만을 가질 수 있습니다.

흥미롭게도, 1, 2, 4 및 7 지점은 프로토 타입 개념 중에 이미 수행되어야한다고 생각합니다 . 단 , 모든 클래스의 모든 방법을 테스트해야한다고 생각하지는 않습니다 . get / set 메소드가 올바르게 작동하는지 여부가 아니라 중요한 코드를 테스트하십시오.

보안이 큰 문제인 응용 프로그램의 목적에 따라 포인트 6은 프로토 타입에서이를 달성하기에 충분히 중요 할 수 있습니다. 성능이 핵심 인 애플리케이션의 목적에 따라 포인트 5가 중요 할 수 있습니다. 내 의견은 3, 5 및 6 포인트가 프로토 타입에서 중요하다고 간주되는 경우 프로토 타입에 필요할 수 있다고 생각합니다 (포인트 8은 실제로 프로덕션 애플리케이션에 유효 함)

편집 : 프로토 타입이 미래 개발의 기초 / 쉘 / 골격이라고 생각하기 때문에 내 의견은 sJhonny의 의견과 완전히 다른 것 같습니다.

이미 언급 한 것 외에도 프로덕션 프로젝트에는 다음이 필요합니다.

0- 구현 방법론 선택

1-주요 요구 사항 (사용 사례 등 포함)을 최종화하고 게시

2- 아키텍처를 바로 잡으십시오

올바른 도구를 선택하십시오

성능을위한 4- 디자인 데이터베이스

5 급 디자인 및 워크 플로우 디자인 제작

6-백업 된 데이터베이스 / 데이터 소스 / 피드를 통합하기위한 전략 결정 및 구현

7- 정의 및 보안 요구 사항 구현

물리적 구현을위한 8- 배열 (서버, 연결, 라이센스 등)

저장 요구 사항을위한 9 계획 및 성능 측정 결정

10- 모든 아티팩트 생성 및 프로덕션 환경에 설치

11 테스트

12- 최종 솔루션 제공 및 피드백 구현

생산 품질 솔루션의 가장 중요한 특징은 견고성 입니다.

어떤 일이 발생하든, 솔루션은 상황을 현명하게 처리하고 알아야 할 사람들에게 알리고 계속 진행합니다 (오류가 복구 가능한 경우).

두 종류의 프로토 타입이 있습니다 :

• "정리"되고 생산 코드가되는 신속하고 더러운 "개념 증명"애플리케이션. "정리"단계는 악몽 인 경향이 있거나 실제로 "양탄자 아래에서 문제를 휩쓸고"단계로 막대한 기술적 부채를 초래합니다.

• "모의 품"프로토 타입 또는 "와이어 프레임". 이것들은 종이와 연필 UI 스케치 일 수도 있고, 어떻게 어울리는 지에 대한 많은 생각없이 이러한 종류의 물건을 빨리 던질 수있는 언어로 된 대화 형 모형 일 수도 있습니다. 가짜 데이터, 실제 아키텍처 등을 사용하지 않아야합니다. 요점은 이해 관계자에게 시스템의 상태에 대한 아이디어를 제공하여 요구 사항을 세분화 할 수 있지만 최종 솔루션의 일부로 사용할 수는 없다는 것입니다 .

나는 두 번째 종류를 선호합니다. 그들은 실제로 선택의 여지가 없기 때문에 밖으로 던져집니다.

데모가없는 프로젝트처럼 빌드한다고했지만 이제는 데모에서 배운 내용을 디자인에 포함시킬 수 있습니다. 생산을 시작한 후에도 초기 코딩이 나쁠 수 있습니다. 어쨌든 당신은 그것의 많은 부분을 리팩토링해야 할 것입니다.

해결해야 할 실제 문제는 시간 제약입니다. 의사 결정자가 데모를 계속 진행하기를 원하면 많은 응용 프로그램이 준비되었다는 인상을 받고 있으므로 시간이 오래 걸리지 않습니다. 다른 사람들이 지나치게 사실적인 모형 대신 고객에게 스케치를 표시하는 것을 선호하는 이유에 대해이 논리를 사용한다고 들었습니다. 데모 코드는 생각하지 않았고이 프로세스에서 문서화하지 않은 문제를 발견했을 수도 있으므로주의하십시오. 이제이를 고려해야합니다 (과도하게 단순화되었지만 예를 들어 데이터베이스에 액세스 할 수 없을 수도 있습니다).

모든 프로토 타입과 데모는 동일하지 않습니다. 전체 코드가 가치가 없거나 특정 부분이 잘 수행되었을 수 있습니다. 차이를 알아야하는 데모인지는 중요하지 않습니다. 당신은 단순히 legacay 앱을 버리고 다시 시작하지 않습니까? 내가 물었던 걸 잊어 버려