기존 프레임 워크를 사용하는 것보다 자신 만의 프레임 워크를 구축하는 것이 언제 더 생산적인가? [닫은]


22

회사에서 자체 프레임 워크를 구축하기로 결정한 이유 를 알고 싶습니다 .

프레임 워크에 따르면 자주 사용하는 라이브러리가 거의 없습니다. 기본 클래스, 컨벤션 등을 사용하여 애플리케이션을 빌드하는 특정 방법을 의미합니다.

그렇다면 자신 만의 프레임 워크를 구축 했습니까? 당신을 고용 한 사람에게 어떻게 정당화 할 수 있습니까? 긍정적이고 부정적인 영향을 측정 했습니까?

귀하의 경험과 관련하여, 어떤 경우에는 회사 프레임 워크가 실질적인 이점을 얻었거나 다른 한편으로 개발 비용 (학습 곡선, 디버깅, 유지 관리 등)이 증가했음을 알았습니까?


6
나는 결정하지 않았다. 그것은 스스로 만들어졌습니다 ...
Mchl

답변:


16

이유에 대한 답변 :

  • 라이센스 문제
  • 현재 프레임 워크에 존재하지 않는 회사 별 요구 사항
  • 회사는 프레임 워크의 지원 및 유지 관리를 제어하려고합니다.
  • 건축가는 더 잘 몰랐습니다! 특정 프레임 워크가 존재한다는 사실을 몰랐으므로 휠을 재발 명하기로 결정했습니다.

최신 정보:

기업은 "작은"프레임 워크를 사용하는 대신 휠을 재창조하는 것을 선호합니다. 작은 의미로는 미래가 불확실한 프레임 워크를 말합니다. 예를 들어 .NET 프레임 워크는 소규모 커뮤니티에서 만든 프레임 워크보다 기업에 더 안전한 선택입니다. 많은 응용 프로그램이 업무상 중요 하기 때문에 기업은 보안이 필요합니다 하고 오래 지속. 휠을 재창조하는 비용은 더 짧은 기간 일 수 있습니다. 그러나 회사 응용 프로그램에 사용 된 프레임 워크가 더 이상 사용되지 않고 더 이상 지원되지 않거나 라이센스가 변경되면 비용이 더 많이들 수 있습니다. 여기서 회사는 현재 프레임 워크를 버리고 다른 프레임 워크를 넣어야 할 수도 있습니다. Visual Basic은 더 이상 Microsoft에서 지원하지 않는 언어의 좋은 예입니다. 그리고 이로 인해 회사는 새로운 개발로 시작해야하므로 수십억 달러가 소요됩니다.


8

왜 자신 만의 것을 만드나요?

  1. 그것은 전에 빌드되지 않았기 때문에 (희귀하지만 가능성은 있음)
  2. 모든 권한을 원하기 때문입니다.
  3. 약간의 기능 만 필요하므로 직접 구축하는 것이 더 저렴합니다.

자신 만의 것을 만들어 보시지 않겠습니까?

  1. 그렇게 할 시간이 없어
  2. 기존 프레임 워크를 구입하면 훨씬 저렴할 것입니다
  3. 많은 시간을 절약하고 생산성을 크게 높일 수 있습니다

7

에서 가 바퀴를 재발견하는 것이 적절한시기에 내 게시물 나는 다시 구현의 장점을 나열합니다. 이러한 장점은 특히 프레임 워크 라이브러리에 적용됩니다. 예를 들어, 응용 프로그램의 작은 부분에서 프레임 워크 라이브러리 사용을 분리하는 것은 종종 불가능합니다. 대신 클라이언트 소스 코드의 구조를 지시하는 경향이 있으므로 라이브러리를 완전히 제어 하는 것이 바람직합니다 .


3

휠을 재발 명하는 유일한 이유는 비즈니스 핵심 애플리케이션 인 경우입니다. 당신의 회사가 앞으로 한동안 사용한다면. 이 응용 프로그램 / 프레임 워크 등 기존의 상용 프레임 워크가 제공하는 것 이상으로 발전 할 가능성이 높으며, 회사 코더가 구현을 확실히 허용하도록 허용합니다.

이것에 대한 유일한 실제 이유는 다음과 같습니다.

  1. 기존 프레임 워크는 잘 유지 관리되고 작업에 완전히 적합하며 미래에도 잘 맞습니다.

  2. 이것은 단지 ' 여기에 발명되지 않았습니다 '증후군의 경우에 해당합니다

  3. 현재 설정에서 합리적인 비용으로 합리적인 시간 내에이 프레임 워크를 만들 수 없습니다.

: Spolsky 조엘은이 문제에 아주 좋은 기사 작성 하지-발명 된-여기 증후군의 방어를


2

기본적으로 다른 사람의 작업을 사용할 때는 보이지 않는 고용주 또는 "추가 손"으로 추가합니다.

그들이 좋은 경우 그들은 당신을 도울 것입니다. 그렇지 않은 경우 자신의 작업 외에도 작업을 수행해야합니다. 즉, 코드를 유지 관리하십시오. 이는 용납 할 수없는 위험 일 수 있지만 매우 드물다고 생각합니다.

키워드는 인터페이스로 코딩하여 프레임 워크를 교환 할 수 있도록하는 것입니다. Java 세계에서 가장 엄격한 인터페이스는 서블릿 API에 의해 입증 된 Sun 사양입니다.

그런 다음 프레임 워크를 사용하지 않는 이유는 없습니다.


1
채택한 프레임 워크의 개발 프로세스를 살펴 보는 것이 도움이됩니다. 강력한 커뮤 티티와 개방형 프로세스를 갖춘 프레임 워크로, 사용자는 진행중인 모든 것을보고 영향을주기 위해 투표 할 수 있으며 특히 소스 코드와 함께 제공되는 경우 위험이 적습니다 (코드를 피하려고합니다. ). 이 경우 프레임 워크 주위에 추가 래퍼를 개발할 필요가 없습니다.
Joeri Sebrechts

2

우리는 내가 일하는 꽤 성숙한 틀을 가지고 있습니다. 다음은 Foundations 프레임 워크 요약입니다.

그것을 사용하는 주요 이유 중 하나는 안정성입니다. 우리는 매년 새로운 기능과 복잡한 기능을 추가해야하는 Microsoft 나 다른 공급 업체에 얽매이지 않습니다.

(나의 고용주 등이 아닌 내 자신의 견해)


2

기존 프레임 워크에서 다루지 않은 요구 사항을 충족시키기 위해 여러 번 수행했습니다.

대부분의 경우, 자체 개발 한 프레임 워크는 나중에 완전히 새로 개발 된 프레임 워크에 의해 제거되었습니다. 예를 들어, 2000 년에 저는 몇 가지 형태로 복잡한 주문 입력 시스템을 만드는 데 사용되는 Java 웹 프레임 워크를 Rails와 비슷한 측면에서 만들었습니다. 그것은 잘 작동했지만 물론 몇 년 후 Struts 및 JSF와 같은보다 성숙한 프레임 워크는 더 이상 사용되지 않습니다. 그러나 당시에는 옳은 일이었고 잘 작동했으며 개발 속도가 인상적이었습니다.

내가 개발 한 또 다른 프레임 워크는 여전히 사용 중이며 활발한 개발 중에 있습니다. 첫 번째 버전은 2004 년에 작성되었습니다.이 버전은 주로 물류 응용 프로그램에 사용됩니다. 그것을 사용하는 회사는 여전히 그것을 구별되는 기능으로 간주합니다. 그것을 만드는 주된 이유는 모바일 바코드 스캐너를위한 데이터베이스 연결 응용 프로그램을 쉽게 만들 수있게하기위한 것입니다 (Windows CE의 일부 특징을 실행). 상사는 PC 소프트웨어에도 동일한 개념을 사용하기로 결정했으며 여전히 만족합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.