이 질문은 웹 기반 프레임 워크 ( Cake PHP, Zend, jQuery, ASP.NET 등) 를 사용할 때의 장단점 을 추출하는 데 중점을 둡니다 . 이 질문은 완전히 언어에 구애받지 않습니다 . "자이언트의 어깨에 서서" 라는 개념으로 시작하겠습니다 .

장점 :

• 개발자 역량 강화 -이전에 100 줄의 코드를 가져 왔던 기능을 하나의 간단한 함수 호출로 압축함으로써 개발자는보다 복잡한 기능을 웹 사이트에 통합 할 수 있습니다.
• 더 빠른 응용 프로그램 개발 허용 – 이것은 매우 작은 창에서 만든 웹 사이트를 필요로하는 사람들과 관련이 있습니다 (예를 들어 본 사람이 있습니까?).
• 비용 절감 -프로그래머가 웹 사이트를 원했지만 이전에는 더 높은 개발 비용을 감당할 수 없었던 완전히 새로운 범위의 고객이 고객에게 비용 절감 효과를 전달할 수 있습니다.

단점 :

• 이해 상실 -개발자는 프레임 워크의 기능에 의존함으로써 일이 어떻게 작동하는지에 대한 이해를 잃어 버릴 위험이 있습니다.
• 구성 절벽-프레임 워크 구성보다 한 단계 더 나아가면 생산성이 떨어지면 프레임 워크 구성 외부에서 기능을 구현하기가 어려울 수 있습니다.
• 개발자 트램 라인 - 개발자 (개발자)는 개발자가 원하는 방식으로 작업을 수행해야합니다.

사람들이 내 요점을 어떻게 생각하는지, 그리고 그들과 동의하지 않는 사람이 있는지 궁금합니다. 또한 사람들이 추가 포인트를 가지고 있다면 감사하겠습니다.

결론은 다음과 같습니다 . 프레임 워크 구성 외부에서 기능을 구현하기가 어려울 수 있습니다.

이 가정을 가정하여 봅시다.

이해 상실-개발자는 프레임 워크의 기능에 의존함으로써 일이 어떻게 작동하는지에 대한 이해를 잃어 버릴 위험이 있습니다.

그릇된. 일이 어떻게 작동하는지 이해하지 못할 것입니다. 프레임 워크는 마법이 아닙니다. 그것들은 당신이 직접 쓸 필요가없는 편리한 코드입니다.

믿거 나 말거나, 당신은 프레임 워크를 사용하여 실수를 할 것입니다. 당신이 잘못한 것을 이해하기 위해 가장 낮은 수준의 HTTP로 바로 디버깅해야합니다.

당신은 후드 아래에서 무슨 일이 일어나고 있는지를 놓치지 않을 것입니다. 물론, 프레임 워크가 너무나 서사적이고 완벽하지 않으면 아무런 문제가 없습니다.

구성 절벽-프레임 워크 구성보다 한 단계 더 나아가면 생산성이 떨어지면 프레임 워크 구성 외부에서 기능을 구현하기가 어려울 수 있습니다.

이것은 귀중한 작은 의미가 있습니다.

먼저. 프레임 워크없이 구축하면 단위 테스트, 디버깅, 진단, 구성 제어 및 프레임 워크에있는 다른 가치없는 작업을 포함하는 다른 모든 값없는 작업을 포함하는 대규모 프로그래밍 작업에 간단한 작업을 수행 할 수 있습니다. "생산성"은 어떻습니까?

둘째. 프레임 워크 외부에서 구현하는 것은 항상 많은 작업이기 때문에 프레임 워크 외부에서 구현하는 것은 항상 많은 작업입니다. 프레임 워크를 배우고 구성하는 데 소요되는 시간과는 아무런 관련이 없습니다. 프레임 워크 외부에서 구현하는 것은 본질적으로 어렵습니다.

개발자 트램 라인-개발자 (개발자)는 [프레임 워크] 개발자가 원하는 방식으로 작업을 수행해야합니다.

옳은. 그리고 이것은 종종 좋은 일입니다. 일관된 방식으로 일하는 것이 자신의 개인적 취향 방법보다 더 가치가 있습니다. "학습"과 "이해"가 필요할 수 있지만 가치가 있습니다.

보안 문제-사람들에게 전문적인 모양의 웹 사이트를 빠르게 개발할 수있는 도구를 제공하는 것은 잠재적 위험이며, 사람들은 사기성 회사를 위해 전문적인 모양의 웹 사이트를 빠르게 만들 수 있습니다.

뭐? 이것은 프레임 워크와 아무 관련이 없습니다. 사기는 사용 된 도구에 관계없이 사기입니다.

단점 : 가능한 지원 중단 / 인기 손실

• 기본적으로 동일한 기능을하는 두 개의 웹 프레임 워크가 있고 이기지 못하면 프로젝트가 종료 될 가능성이 있습니다. 이 상황에서는 프레임 워크를 직접 유지 관리하거나 (오픈 소스) 응용 프로그램을 다시 작성하거나 업데이트없이 (닫힌 소스) 계속해야합니다.
• 프레임 워크에 따라 프레임 워크의 릴리스 스케줄로 애플리케이션을 업그레이드해야 할 수도 있습니다. 너무 멀리 떨어지면 지원을받을 자격이 없습니다. 프레임 워크가 없으면 일정에 따라 작업 할 수 있습니다. (지원이 필요한지 여부에 따라 다릅니다).

프로 : 비즈니스를위한 코드

• 프레임 워크를 사용하면 거친 작업에 대해 걱정할 필요가 없으며 비즈니스에 직접 가치를 제공하는 코드에 집중할 수 있습니다.
• 때로는 프레임 워크 업그레이드 (작동)를 통해 사용자에게 실질적으로 "무료"로 새로운 기능을 제공 할 수 있습니다. 특히 사용자 정의 컨트롤이 포함 된 프레임 워크 (예 : 새 버전에서 일종의 검색 / 필터를 제공 할 수있는 그리드)

장점

• 더 빠른 개발 시간
• 적은 버그
• 빠른 공유 개발
• 도서관 지원
• 손쉬운 DB 상호 작용

단점

• 프레임 워크에 "박스에 넣음"
• 핵심 행동을 확장하거나 수정하려고 할 때 종종 융통성이 없습니다
• "파멸의 오류"– 코어 또는 기본 아키텍처에서 발생하는 오류로, 원래 위치에 대한 추적이 양호하지 않습니다. Grails를 사용할 때 스프링 오류가 완벽한 예입니다.

나는 가장 단순한 프로젝트를 제외한 모든 프레임 워크를 사용하는 것을 옹호합니다. 기존 HTML 사이트에 문의 양식을 추가해야하는 경우 프레임 워크로 이동하는 대신 하나의 PHP 파일을 사용할 수 있습니다.

생각 나는 몇 가지 사항은 ...

장점

• 코드 재사용-프레임 워크를 사용하면 테스트되고 사실 인 코드를 재사용하게됩니다.
• 신속한 개발 / 시제품 제작.
• (종종) 안전한 것으로 추정 될 수있는 통합 입력 검증 (개발자가 올바르게 사용하는 경우)

단점

• 지원 상실. 여기서 생각 나는 것은 Symfony 1.4입니다. Symfony는 1.4를 꽤 오랫동안 지원할 것이라고 생각하지만 2.0이 이전 버전과 호환되지 않는다는 것을 알고 1.4는 향후 수년간 지원 막 다른 골목처럼 보입니다.
• 간접비; 프레임 워크를 사용하면 특정 응용 프로그램에는 적용되지 않지만 다른 응용 프로그램에는 적용 할 수있는 수천 줄을 실행하고 있습니다. 일부는 이것이 합리적인 트레이드 오프로 간주되고 일부는 성능을 위해 코드를 처음부터 작성하도록 선택합니다.
• 특정 요구에 맞는 틀을 사용합니다. 모든 프레임 워크가 똑같이 만들어지는 것은 아닙니다.

모두 사용하는 프레임 워크에 따라 다릅니다.

ASP.NET을 사용하는 경우 단점이 있습니다. 최고의 누출 추상 이며 최악의 경우 다른 프레임 워크에서 사소한 작업을 수행하는 데 어려움을 겪습니다. 웹에서 작업합니다.

ASP.NET MVC는이 문제를 해결하려고 노력하고 있습니다.

프레임 워크가 존재하여 작업을 완료하는 데 더 많은 시간을 할애하고 발판을 만드는 데 더 적은 시간을 할애 할 수 있습니다. 그 점에서 비계를 만드는 데 시간을 보내고 싶지 않다면 단점이 없습니다.

몇 가지 요점을 추가하고 싶습니다.

• 내가 찾은 프레임 워크의 가장 큰 문제 중 하나는 사람들이 생각을 멈추는 것입니다. 그들은 프레임 워크가 멋지거나 항상 프레임 워크를 사용하기 때문에 프레임 워크를 사용하려고합니다. 사용이 정당한지 생각하기 위해 멈추지 않습니다.
• 라이센스, 사람들은 라이센스를 실제로 보지 않고 프레임 워크를 사용하는 것 같습니다. 이것은 그들이 알지 못하는 의미를 가질 수 있습니다. 또는 라이센스가 변경되면 어떻게되는지 생각해보십시오.
• 같은 종류의 프레임 워크를 많이 사용합니다. 때때로 그것들은 실제로 거의 같은 일을하는 많은 프레임 워크 일 수 있습니다. 회사로서 당신은 교육적인 선택을하고 모든 프로젝트에 대해 다른 틀을 가지지 않습니다.
• 새로운 버전을 유지하는 것은 어려울 수 있습니다

여전히 프레임 워크를 평가하고, 라이센스를 평가하고, 사용 당 프레임 워크를 깔끔하게 정리하고, 이점을 고려할 때 스마트 한 버전 관리 전략을 세우는 데 더 많은 노력을 기울이고 있다고 생각합니다.

장점 :

• 지속적으로 프레임 워크를 사용하면 이미 프로젝트를 수행 한 사람들의 프로젝트 학습 시간이 줄어 듭니다.
• 더 빠른 개발
• 자신의 권한 부여 개발자

나는 지난 13 년 동안 개인적인 경험을 통해 이야기합니다. 우리 회사에서는 스트럿을 사용했는데, 짧은 곡선 후에는 훌륭했습니다. 다음에는 대부분 불투명 한 아키텍처를 사용했지만 다소 확장되었지만 확장 할 수는 있었지만 핵심 코드는 단지 항아리였습니다. 등등. 지난 3 년 동안 소규모 회사 (개발자 수 <30 명)에서 일해 왔으며 모두 자체 JSP, 서블릿 및 ejb였습니다. 여러 고객과 jsp의 반복을 살펴보면 2012 년에 struts2의 20 %를 모방 한 j2ee 필터를 만드는 것이 었습니다. 왜 스터드 2를 사용하지 않습니까? 나는 우리가 갖고 싶었지만 : 그것은 우리의 수석 건축가를 통과시키지 못했습니다. 충분한 경험이나 시간이 없습니다.

그래서 우리는 미니 프레임 워크가 사용하는 몇 가지 일반적인 jsp를 인터셉터로 만들었습니다. 이제 스트럿츠 2 책을 통해 갈 시간이 있었을 때 우리는 너무 많이 그리워했습니다.

우리는 훌륭한 알고리즘과 캐시 및 UI를 사용하지만 많은 시간을 잃었고 3 년의 은퇴 계획이있는 많은 코드로 인해 부담이되었습니다.