대형 프로젝트에 EiffelBuild를 사용할 수 있습니까? 아니면 프로토 타이핑 사용을 제한해야합니까?

Question

Eiffelbuild는 Eiffel 전용 ISE Gui 건설 그래픽 도구입니다.

나는 그것을 시도하고 매우 사용자 친화적이지만, 큰 프로젝트에 그러한 도구를 사용하는 것에 대해 조금 걱정하고 있습니다. GUI 건설 도구의 사용은 제한적 일 수 있습니다.

에펠 상속은 구성 요소를 만들기가 매우 쉽기 때문에 장기적으로는 표준 객체를 사용하는 자체 특수 버전의 그래픽 객체를 사용하는 것이 좋습니다.

대규모 프로젝트의 사용을 피하기 위해 정당화 할 EiffelBuild의 제한을 알고 있습니까?

Answer 1

프로토 타이핑에 EiffelBuild 사용을 제한합니다. 좋은 도구이지만 장기적으로는 EiffelBuild 프로젝트를 관리하는 데 점점 더 복잡해 질 것입니다 (대부분의 디자이너에게는 해당).

• 새로운 버전의 Estudio는 6 개월마다 출시되므로 EiffelBuild 프로젝트가 한 버전에서 다른 버전으로 예상되는대로 여전히 작동하도록해야합니다. 이제 모든 Eiffel 코드는 동일한 과제를받을 수 있지만 EiffelBuild의 프로젝트를 사용하면 언어와 Eiffelbuild (때로는 동시에 ...)의 변경 사항을 처리해야합니다.
• 버전 n+1과 n이 호환되지 않는 경우, 전환 기간 동안에 만 두 버전을 지원하기 위해 EiffelBuild 프로젝트의 지점을 만들어야합니다.
• 여러 EiffelBuild 프로젝트를 통합하기가 어려울 수 있습니다
• 일부 그래픽 구성 요소는 특수 차트 구성 요소 (예 : 클래스 세트)와 같은 EiffelBuild에서 재사용하기가 어려울 수 있습니다. 예를 들어, 특히 해당 구성 요소가 EiffelBuild 프로젝트 자체가 아닌 경우
• 한 EiffelBuild 응용 프로그램으로 만든 부품을 다른 응용 프로그램으로 재사용하기가 어렵다는 것을 알았지 만 상당히 잘 설계된 구성 요소는 문제가 훨씬 적습니다.

도움이 되었기를 바랍니다.

Answer 2

나는 그것을 시도하고 매우 사용자 친화적이지만, 큰 프로젝트에 그러한 도구를 사용하는 것에 대해 조금 걱정하고 있습니다. GUI 건설 도구의 사용은 제한적 일 수 있습니다.

이것은 어떻게 "제한적"입니까? 그리고 프로젝트의 규모는 어떻게 작동합니까?

코드 생성기라는 것을 의미하고 완전히 나오는 코드를 완전히 이해하지 못하면 완전히 동의합니다. 코드 생성은 손으로 차가워지면 코드를 작성하는 경우에만 작동하며 발전기는 Grunt Work를 저장하여 리프트를 제공합니다. 이 경우 생성 된 코드를 수정하고 유지 관리하는 데 전적으로 자신감을 갖습니다.

에펠 상속은 구성 요소를 만들기가 매우 쉽기 때문에 장기적으로는 표준 객체를 사용하는 자체 특수 버전의 그래픽 객체를 사용하는 것이 좋습니다.

추가하는 전문화는 무엇입니까? 나는 페르 페투 암에서 큰 클래스 계층 구조를 쓰고, 디버깅하고, 대규모로 유지하는 것을 의미하기 때문에 이것을하는 것에 대해 신중하게 생각합니다. 이 단계를 밟기 전에 전문화가 필요하고 비용이 가치가 있으며 다른 수단에 의해 불가능하다는 것을 절대적으로 확신하십시오. 결정하기 전에 비용을 정량화하기 위해 정직한 노력을 기울이십시오.

Library GUI 클래스를 사용하여 충분한 손으로 코딩 한 후에는 자신의 코드 생성기를 작성하는 데 투표합니다. 그것은 지속 가능한 솔루션입니다.

업데이트:

나는 90 년대 중반에 이용 가능한 최고의 객체 지향 언어라고 결정한 대학원 프로그램에서 에펠을 배웠습니다. 당시 C ++는 탁월했지만 복잡한 것으로 간주되었지만 Java는 Sun의 실험실에서 벗어나지 않았으며 C#은 Anders의 눈에는 빛나지 않았습니다. 이 시설의 교수진은 계약에 의한 설계와 그것이 암시적인 엄격한 엄격한 규모에 매료되었습니다.

나는 Meyers의 "Object Deriented Software Assruction"을 읽었습니다. 첫 번째 판은 DBC를 소개하고 Meyers를 대상 지향 세계에서 스타로 만들었습니다. 제 생각에, 두 번째 판은 그의 상승을 끝내는 부풀어 오른 것입니다.

솔직히, 당신이 고용주를 위해이 큰 시스템을 쓰고 있다면, 나는 당신에게 에펠을 떨어 뜨리고 그들의 주류와 당신의 주류 언어로 바꾸라고 할 것입니다. Windows 플랫폼을 사용하는 경우 C#이 좋은 선택이 될 수 있습니다. 이질적인 환경이 있거나 Microsoft 스택을 감당할 수없는 경우 Java를 사용하십시오.

에펠에 대한 네 가지 태그가있는 질문도 모두 있습니다. 볼륨이 뭔가를 말하는 것 같아요. 인기가 항상 최고의 품질 지표가 아니라는 것이 옳을 수도 있습니다. 나는 베타가 VHS보다 더 나은 기술 솔루션이라고 들었지만 사실은 시장에서 잃어버린 것이며 오늘날에는 찾을 수 없다는 것입니다. 에펠과 동일합니다. 내가 너라면 떨어질거야.

UPDATE 2:

아주 좋아 - 나는 당신의 원래 게시물에서 다른 언어에 대한 당신의 경험이 무엇인지 알 수 없었습니다.

"품질에 대한 높은 기대"는 에펠이 다른 언어와 복제 할 수없는 방식으로 언어 수준에서 품질을 지원할 것이라고 믿는다는 것을 의미합니다. 나는 그것에 동의하지 않을 것이다. 코드의 품질은 언어 자체보다 개발자의 기술과 관행과 더 관련이 있습니다.

계약에 의한 설계는 완전히 과매도입니다. 나는 그것이 성능 히트를 나타 내기 때문에 생산에서 종종 꺼져 있음을 읽었습니다. 그것이 당신에게 사실이라면, 에펠 펠이 품질에 기여할 것을 어떻게 기대합니까?

나는이 응용 프로그램을 작성하는 고객이 에펠과 함께하기로 결정한 결정에 대한 모든 결과를 이해하도록해야합니다. 제한된 개발자 풀을 유지하기위한 제한된 풀, 죽은 언어를 사용하여 소외된 직원 등. 주관적인 소원 때문에 오버셀하지 않도록하십시오.