그건 그렇고, 흥미로운 아이디어. 개발 과정에서 문제는 다음과 같습니다. 각각의 새 빌드가 출시될 때 시장에서 판매 가능한 모든 제품을 자동으로 재컴파일하고(표준 설정을 고려하여) 이러한 재컴파일된 제품을 충분히 테스트할 수 있도록 하는 것이 현실적입니까? 깊은 역사(각 제품의 표준 설정도 동일하게 고려)? 자동 버그 감지 기능을 사용하면 새 빌드 릴리스가 일시 중단되고 "매우 깊숙이 숨겨진" 버그만 구매자에게 전달됩니다. 결과적으로 구매자 입장에서는 빌드 버그가 나타날 가능성이 급격히 감소했을 것입니다.
또 다른 요점이 있습니다. 때때로 새로운 MT 빌드에는 지표/EA를 다시 컴파일해야 합니다.
예, 하나가 있습니다. 하지만 이 과정이 곧 진정되기를 바랍니다.
그리고 그건 그렇고, 아마도 시장 자체가 재편집을 수행할 것입니다. 결국 시장에 출시될 때 ex5에 보호 기능이 꿰매어져 있습니다. 따라서 이론적으로 새 빌드를 위해 다시 컴파일하지만 ... 확실하지 않습니다.
아마도 시장 자체가 재편집을 수행할 것입니다.
그건 그렇고, 흥미로운 아이디어. 개발 과정에서 문제는 다음과 같습니다. 각각의 새 빌드가 출시될 때 시장에서 판매 가능한 모든 제품을 자동으로 재컴파일하고(표준 설정을 고려하여) 이러한 재컴파일된 제품을 충분히 테스트할 수 있도록 하는 것이 현실적입니까? 깊은 역사(각 제품의 표준 설정도 동일하게 고려)? 자동 버그 감지 기능을 사용하면 새 빌드 릴리스가 일시 중단되고 "매우 깊숙이 숨겨진" 버그만 구매자에게 전달됩니다. 결과적으로 구매자 입장에서는 빌드 버그가 나타날 가능성이 급격히 감소했을 것입니다.
그게 다야, 시장은 신속하게 모든 것을 제자리에 둘 것입니다. 물론 MK가 부정적인 고객 리뷰를 덮어 쓰지 않는 한, 상품을 동반하지 않는 판매자가 시장에서 어떻게 날아가는지 보게 될 것입니다.
시장은 조정되지만 당신이 생각하는 방식은 아닙니다.
서비스는 사용자에게 간단하고 편리해야 합니다. 구매자와 판매자를 위해.
판매자가 날아가나요? 5%라고 생각하는 거, 젠장. 95% 날아갑니다. 상품 원가, 판매 횟수 및 소요 시간을 계산하십시오. 아무도 보지 않을 것입니다. 비용 효율적이지 않을 뿐입니다.
이 말에 100% 동의합니다.
주제에 대한 내 IMHO.
제 생각에는 문제가 과장되었습니다. 예, 현재로서는 어느 정도 관련이 있습니다. 그러나 모든 빌드가 불가항력이라는 것은 아닙니다. 그리고 재미있는 빌드가 나오면 MQ는 몇 주가 아니라 며칠 안에 새 빌드를 출시할 것입니다.
MQ, 판매자 및 구매자의 책임은 규칙에 설명되어 있습니다. "시장" 서비스의 각 참가자는 이러한 규칙의 프레임워크 내에서 자신의 위험(평판 위험 포함)을 감수합니다.
이 상황의 솔루션은 양쪽에 하나씩 있습니다.
시장의 측면에서 결정할 필요가 있습니다. 커미션을 올리는 대가를 치르더라도.
미샤, 이것은 시장 측에서 해결되지 않습니다. 글쎄, 직원이 모든 제품을 확인합니까? 재미있는.
아니요, 유일한 옵션은 사용자 - 프로그래머 - 지원 - 수정입니다. 유일한 질문은 이 계획을 더 효율적으로 만드는 방법입니다.
미샤, 이것은 시장 측에서 해결되지 않습니다. 글쎄, 직원이 모든 제품을 확인합니까? 재미있는.
아니요, 유일한 옵션은 사용자 - 프로그래머 - 지원 - 수정입니다. 유일한 질문은 이 계획을 더 효율적으로 만드는 방법입니다.
커미션을 올립니다.