프레임 워크가 너무 많은 추상화를 적용합니까? [닫은]

나는 1 년이 조금 넘도록 프로그래밍을 해 왔으며 시스템 응용 프로그램, 웹 응용 프로그램 및 비즈니스 / 조직 용 스크립트 작성 경험이 있습니다. 그러나 내가 실제로 한 적이없는 것은 Django, Rails 또는 Zend와 같은 프레임 워크를 사용하는 것입니다.

장고 프레임 워크를 살펴보면 프레임 워크에서 추상화되는 양이 약간 실망 스럽습니다. DRY의 핵심 목표와 최소한의 코드를 이해하지만 다른 모듈에 대한 과도한 의존과 핵심 기능에 대한 추상화는 다음과 같습니다.

1. 끊임없이 변화하는 모듈 / 프레임 워크의 특성으로 인해 프로그램이 정말 빠르게 업데이트됩니다.

2. 다양한 프레임 워크 및 모듈과 모든 고유 한 특성으로 인해 코드를 이해하기 어렵게합니다.

3. 모든 문서를 읽지 않으면 코드를 덜 논리적으로 만듭니다. 즉, 일부 목록 이해와 조건부 논리를 읽고 프로그램이 수행하는 작업을 파악할 수 있지만 임의의 문자열과 사전을 전달 해야하는 함수를 볼 때 이미 전문가가 아닌 한 상황을 이해하기가 조금 어려워집니다. 주어진 모듈; 과:

4. 프레임 워크 간 전환이 어렵고 지루합니다. 언어 간 전환은 이미 어려운 일이지만 핵심 기능 / 철학에 대해 충분히 이해하고 있다면 관리가 가능합니다. 프레임 워크 간 전환은 암기의 문제로 보이며, 어떤 방식으로 이러한 프레임 워크가 제거하도록 설계된 비 효율성을 장려하는 것으로 보입니다.

MySQL 쿼리처럼 단순한 것 위에 50 개의 추상화 계층을 배치해야합니까? 준비된 명령문 / 입력 테스트는 처리되지만 보편적으로 이해할 수있는 SQL 쿼리는 여전히 함수의 일부인 PHP의 PDO 인터페이스와 같은 것을 사용하지 않는 이유는 무엇입니까?

이러한 추상화가 실제로 유용합니까? 부풀려 기능이 없어 쓸모없고 프레임 워크를 사용하지 않고 작성된 유사한 응용 프로그램에 비해 응용 프로그램이 더 어려워 집니까?

프레임 워크는 실제로 까다로울 수 있습니다. 프레임 워크가 너무 "견해"된 경우, 즉 하나의 특정 응용 프로그램 스타일을 실제로 선호하고 모든 부품이이 특정 스타일을 지원하도록 조정 된 경우 문제가 쉽게 발생할 수 있습니다.

예를 들어, 프레임 워크에서 구성 요소를 하나만 추가하고 로그인 템플릿을 추가 할 수 있도록하여 사용자의 인증 프로세스를 완전히 추상화 한 경우 사용자 인증은 무료입니다. 쿠키, 세션 저장, 비밀번호 해싱 및 기타 사항에 대해 걱정하면서 반복적 인 작업을 많이 절약했습니다.

프레임 워크 인증 코드의 기본 동작이 필요하지 않다는 것을 인식하면 문제가 시작됩니다. 최신 보안 모범 사례를 따르지 않을 수 있습니다. 어쩌면 프로세스에서 사용자 지정 후크가 필요할 수도 있지만 프레임 워크는 제공하지 않습니다. 설정중인 쿠키의 세부 사항을 변경해야 할 수도 있지만 프레임 워크는이를 사용자 정의 할 방법을 제공하지 않습니다.

프레임 워크가 제공하는 추상화를 통해 처음에는 며칠이 아닌 몇 분 안에 사이트에 중요한 기능을 추가 할 수 있었지만 결국에는 필요한 작업을 수행하기 위해 프레임 워크와 싸워야 할 수도 있습니다. 어쨌든 필요에 따라 기능을 처음부터 다시 개발해야합니다.

이것은 프레임 워크 추상화가 나쁘다는 것을 말하는 것이 아닙니다. 이것은 항상 당신이 명심해야 할 가능성이라고 말합니다. 일부 프레임 워크는이를 위해 명시 적으로 맞춰져 있으며 매우 구체적이고 제한된 유형의 앱에 대한 프로토 타입 또는 프로덕션 프레임 워크로 매우 빠르게 무언가 를 얻을 수있는 방법을 제공합니다 . 다른 프레임 워크는 사용할 수있는 느슨한 구성 요소 모음과 비슷하지만 나중에 변경하는 데 많은 융통성을 제공합니다.

추상화를 사용할 때는 항상 추상화 된 내용을 대략적으로 이해해야합니다. 쿠키와 인증 시스템을 이해하지 못하면 추상화에서 시작하는 것은 좋지 않습니다. 당신이하려는 일을 이해하고 자신을 직접 작성하는 대신 이미 코드를 작성 해야하는 경우 추상화는 시간 절약에 큰 도움이됩니다. 잘못 작성된 추상화는 나중에 문제를 일으킬 수 있으므로 양날의 칼입니다.

또한 기술 추상화와 "비즈니스 규칙" 추상화를 구별해야합니다 . 더 높은 수준의 언어로 프로그래밍하는 것은 놓치고 싶지 않은 추상화입니다 (Python, PHP, C # vs. C vs. 어셈블러; Less vs. CSS). "비즈니스 규칙 추상화"는 그렇지 않으면 어려울 수 있습니다 사용자의 요구를 정확히 충족하십시오 (원 클릭 인증 및 핸드 코딩 쿠키).

기술적 인 추상화는 거의 "누설"되지 않기 때문이다. 즉, 파이썬으로 애플리케이션을 작성할 때 머신 코드를 디버깅 할 필요가 거의 없다. 비즈니스 규칙 추상화는 동일한 기술 수준에서 작동하며 실제로는 "코드 번들"입니다. 설정된 쿠키 또는 특정 시점에 생성 된 비밀번호 해시를 디버깅해야 할 것 입니다 . 이는 많은 타사 코드를 통해 다이빙을한다는 것을 의미합니다.

추상화와 코드 재사용을 오해하는 것 같습니다.

전체 소프트웨어 개발 산업은 추상화를 기반으로합니다. 프레임 워크, 라이브러리 및 사내에서 작성되지 않은 일반 코드를 사용하지 않는 것만으로도 소프트웨어를 생산하는 데 드는 비용이 수십만 대, 그 이상으로 증가 할 수 있습니다.

다른 항공기를 제작할 때 수년간 개발 한 엔지니어링 지식을 사용하지 않고 처음부터 점보 제트기를 만들지 않는 것처럼 비즈니스 소프트웨어를 처음부터 작성하지 않습니다.

우선 PHP 나 Ruby를 사용하여 얻을 수 있습니다. 이미 많은 추상화가 있습니까? 가장 명백한 것 :

1. 운영 체제, 프로그래밍 언어 및 컴파일러는 어셈블러 및 하드웨어에 대한 거대한 추상화를 제공합니다.

2. 웹 서버는 소켓, 페일 오버, HTTP 프로토콜 등의 추상화를 제공합니다.

3. SQL은 데이터가 영구 스토리지 지원에 저장되고 더 빠른 액세스를 위해 메모리에 보관되는 방법에 대한 추상화를 제공하며 ACID, 미러링 등을 보장합니다.

운영 체제 나 웹 서버, 데이터베이스 또는 고급 프로그래밍 언어를 사용하지 않고도 웹 응용 프로그램을 만들려고 할 수 있습니다. 당신은 신속 즉 다시, 바퀴를 개혁 년을 보낸 것을 찾을 수 있습니다 당신의 프로그래밍 언어, 귀하의 웹 서버와 사용자의 품질은 우리가 실제로 사용하는 제품의 품질에서 멀리 될 것이라고 주어진 데이터베이스를.

프레임 워크는 그것과 다르지 않습니다. 그들이하는 일을 할 수 있습니다. 동일한 기능을 다시 실행하는 데 시간을 낭비하고 프레임 워크가 더 잘 수행한다는 점과 코드가 테스트보다 더 잘 문서화되는 경우가 많습니다.

전자 상거래 웹 사이트의 장바구니를 예로 들어 보겠습니다. 당신은 자신의 것을 발명하고 그것을 개발하는 데 몇 주를 소비 할 수도 있고, 프레임 워크 안에있는 많은 사람들에 의해 수년간 개발 된 것을 가질 수도 있습니다. 그들의 개발자는 몇 년 동안 개발자가 자신의 카트를 개발할 때 상상할 수없는 많은 버그를 발견하고 패치했다는 사실을 고려하지 않고 테스트 될 것으로 예상됩니다.

더 많은 사용자 사례가 있기 때문에 더 복잡하다고 대답 할 수 있습니다. 예를 들어 웹 사이트에 리베이트가없고 장바구니에이 기능이 필요하지 않은 반면, 리베이트를 처리해야합니다. 글쎄, 당신은이 기능을 사용하도록 강요되지 않으며 웹 앱의 성능을 훼손하지 않을 것입니다.

기존 카트를 사용하는 대신 직접 카트를 개발하는 것이 훨씬 쉬운 경우 매우 기본적인 시나리오가있을 수 있습니다. 같은 방식으로, 앱에 필요한 유일한 것은 숫자 목록을 저장하는 것 외에는 아무것도 필요하지 않습니다. 데이터베이스가 필요하지 않습니다. 간단한 텍스트만으로 충분합니다. 이 경우 앱을 과도하게 엔지니어링하지 마십시오. 간단한 시나리오에는 간단한 솔루션이 필요합니다.

또 다른 요소는 코드의 가독성입니다. 전자 상거래 웹 사이트를 만들었다 고 상상해보십시오. 나중에 프로젝트를 종료하면 다른 개발자가 프로젝트를 유지 관리해야합니다.

• 프레임 워크에서 제공하는 카트를 사용한 경우 동료는 안심할 수 있습니다. 즉, 신뢰할 수 있고 문서화가 잘 된 프레임 워크에 의존하는 작은 코드를 유지해야합니다. 더 좋은 점 :이 개발자는이 프레임 워크를 다루는 데 익숙했을 것입니다. 그렇지 않은 경우 Stack Overflow에 대해 질문 할 수 있습니다. 누군가 이미 프레임 워크를 사용한 적이 있습니다.

• 자신의 카트를 가지고 있다면, 동료는 어디서나 도움을 얻을 수없이 문서화되지 않은 사용자 정의 코드를 유지해야 할 것입니다.

프레임 워크를 사용하면 다음과 같은 코드를 사용하게됩니다.

• 숙련 된 개발자가 작성한

• 종종 쌍 검토,

• 단위 테스트,

• 광범위한 문서화

• 수천 명의 개발자가 수년 동안 사용했으며

• 종종 지원되므로 버그를보고하고 실제로 수정 된 것을 확인할 수 있습니다.

• 가능한 경고 및 문제를 알고 있으며 스택 오버플로와 같은 사이트에서 도움을 줄 수있는 많은 개발자들에게 알려져 있습니다.

• 지금 무료로 제공됩니다.

동의합니다. 대부분의 프레임 워크는 부풀린 독재자가됩니다. 그들은 자유를 약속하지만 당신은 종으로 끝납니다. 도구와 같은 프레임 워크를 살펴보십시오. 가장 좋은 도구는 방해가되지 않는 도구입니다. PHP에서 나는 Codeigniter 프레임 워크를 확인하는 것이 좋습니다. 컨벤션과 자유 사이의 우아한 균형과 훌륭한 커뮤니티가 있기 때문입니다. 그리고 전자 상거래 카트의 예를 사용한 포스터에게-나는 당신에게 동의 할 수 있기를 바랍니다. 그러나 많은 전자 상거래 솔루션의 코드를 살펴보고 몇 가지를 디자인 한 것은 귀하의 예에 정중하게 동의하지 않습니다.

Hmmm 많은 작업을 한 LedgerSMB의 한 가지 측면은 프레임 워크에 대한 접근 방식이었습니다. 그러나 이런 종류의 추상화에는 두 가지 근본적인 문제가 있습니다. 이것들은:

1. 의존성 폭발

2. 잘못된 추상화

첫 번째는 실제로 바퀴를 재발 명하는 대안보다 낫습니다. 두 번째는 잘못 정의 된 문제의 경우 또는 더 자주 의도 된 용도 이외의 것을 사용하는 사람들로부터 나올 수 있기 때문에 라벨을 붙이기 어려운 것입니다.

예를 들어 ORM을 보자. ORM을 사용하는 것은 피하는 것이 좋습니다. db는 누출되는 추상화 계층이기 때문에 응용 프로그램의 객체 모델에 맞게 설계되는 경우가 많습니다. 반드시 그런 것은 아닙니다. ORM을 사용하는 동안 좋은 DB 디자인과 좋은 앱을 유지 관리하는 개발자를 만났지만 업데이트 가능한 뷰 뒤에 db의 관계형 API를 캡슐화하는 것과 같이 orm hype가 필요하지 않은 많은 것들에 의존합니다.

물론 가장 큰 문제는 코드의 자동화 수준이 높을수록, 특히 불투명 할 때 무엇이 ​​잘못되었는지 알기가 어렵다는 것입니다. 이것은 @jhewlett이 위의 ORM에 대한 요점입니다 ( /software//a/190807/63722 참조 ).

항공기를 조종하기위한 프레임 워크로서 고급 항공 전자 기술이 좋은 대안이 될 수 있습니다. 신뢰성을 높이기 위해 고도로 설계되었으며 비행 안전성을 향상시키는 요소입니다. 그러나 IEEE Spectrum의 많은 기사 에서 지적했듯이 자동화 관점에서 허용되는 것으로 간주되는 범위를 벗어나는 오류로 인해 복구 비용이 발생합니다. 디버깅도 마찬가지입니다. 프로그램에서 SQL 코드를 디버깅하는 것이 한 가지입니다. 프로그램이 사용할 SQL 코드를 작성하는 프로그램의 일부를 디버그하는 것은 매우 다른 것입니다.

처음 시작할 때 LedgerSMB 프레임 워크를 처음부터 작성했습니다. 왜냐하면 원하는 시점에 실제로 수행 한 프레임 워크가 없었기 때문입니다. 실제로 매우 만족스럽고 프로젝트의 새로운 개발자에 따르면 응용 프로그램의 사용자 정의가 매우 간단합니다. (실제로 우리는 SQL 코드 생성을 최소로 유지하고 대신 직접 작성하는 사용자 정의 함수에 중점을 둡니다. 즉, SQL 작성 부분은 매우 얇습니다.) 그렇습니다. 일부 프로그래머에게는 익숙한 것보다 많은 추상화가 있습니다 (특히 "저장된 프로 시저의 인수에 객체 속성 매핑"을 통해 때때로 푸시 백 할 수 있음). 그러나 우리는 모든 일을 단순하고 일관되게 유지하여 무엇이 잘못되었는지를 쉽게 판단 할 수 있도록 노력합니다. 이것은 꽤 잘 작동합니다.

결국 "너무 많이"는 약간 주관적이지만 객관적인 수준에서 그것은 또한 당신이하고있는 일에 달려 있습니다. 프레임 워크가 의도 한대로 정확하게 수행하는 경우, 잘 설계된 프레임 워크는 완벽한 추상화를 제공합니다. 적합하지 않은 작업을 수행하는 경우 추상화가 너무 많이 유출되고 누수가 발생합니다.

예, 유용합니다. 그들은 당신에게 해결해야 할 문제를 해결하기 위해 노력하는 다른 많은 숙련 된 개발자의 이점을 제공합니다. 테스트 한 이점, 많은 버그 수정 및 걱정할 필요가없는 까다로운 문제에 대한 솔루션 제공 프레임 워크를 사용하여 자신을.

그들은 과도하게 부풀려 질 수 있습니까? 확실한. 이것은 모두 필요한 것과 프레임 워크가 테이블에 가져 오는 것에 달려 있습니다. 간단한 웹 응용 프로그램을 사용하는 경우 Rails가 과도 할 수 있으므로 Sinatra와 같은 간단한 솔루션을 솔루션으로 고려해야합니다.

모든 프레임 워크에는 학습 곡선이 있으며, 더 많은 작업을할수록 더 가파 릅니다. 그러나 프레임 워크를 학습하면 애플리케이션을 처음부터 다시 작성하는 대신 시간을 절약하고 다음 프로젝트에서 모든 지식을 활용할 수 있습니다.

그러나 이전 프로젝트에서 코드를 복사하면 새 프로젝트의 시작점으로 사용할 수 있습니다. 나는 다른 것을 바꾸고 내 객체 / 함수 중 일부를보다 일반적으로 만들고 까다로운 코드를 해결하는 더 좋은 방법을 생각할 것입니다! 축하합니다. 방금 프레임 워크를 만들었습니다. 이것을 수천 번 더하면 장고, 레일즈 또는 젠드와 같은 것이 있습니다.

프레임 워크는 일반적으로 생산성을 높이지만 (약간의 학습 곡선 후), 종종 트레이드 오프가 발생합니다. 예를 들어 성능 저하로 인해 프로그래머의 생산성이 향상되는 경우가 있습니다.

ORM (Object-Relational Mapper)을 고려하십시오. 그들은 당신을 위해 많은 지루한 매핑 코드를 관리한다는 점에서 훌륭합니다. 그들은 당신을 위해 물건을 만들 수도 있습니다. 그러나 SQL을 추상화 할 때는 성능에 대해 추론하고 병목 현상을 최적화하기가 훨씬 어렵습니다.

많은 데이터 나 복잡한 쿼리가없는 응용 프로그램을 구축하는 경우 성능이 문제가되지 않을 수 있습니다. 실제로 프로그래머 시간은 많은 프로젝트의 병목이며 프레임 워크, 라이브러리 및 고급 언어는이를 완화하는 데 도움이됩니다.

"당신은 라이브러리를 사용하지만 프레임 워크는 당신을 사용합니다"에 동의합니다. 그것은 매우 깔끔한 방법입니다. 코드 재사용을 시작하자마자 프레임 워크를 구축하기 시작한다는 데 동의하지 않습니다. 일반적으로 코드를 다시 사용하기 위해 빠른 복사 및 붙여 넣기 이상을 수행 할 필요가 없습니다. 당신이 만들고있는 도서관; 코드를 사이트 나 앱으로 가져 오는 방법에 대해 이상하게 생각할 필요가 없습니다.

저에게있어 중요한 점은 내가 투자하는 것보다 더 많은 자원을 활용해야한다는 것입니다. 또는 다른 각도에서, 프레임 워크의 요구가 사용 가능한 보상보다 큰 즉시 모든 이점이 없다고 말할 수 있습니다. 그래서 '예! 부디! 그리고 감사합니다! ' 내 자신의 html / CSS / PHP 및 SQL 내에서 필요에 따라 똑바로 떨어지고 작동하는 자산을 만드는 모든 사람에게.

내가 이해할 수없는 것 중 하나는 프레임 워크가 유지 보수를 쉽게한다고 말합니다. 인터 워킹 부품의 복잡한 메시가 의도 한대로 작동하지 않으면 해당 프레임 워크에 대해 알아야 할 모든 것을 더 잘 알고있을 것입니다. 또는 새로운 구문을 많이 입력 할 준비를하십시오.

어떤 사람들은 이것이 프레임 워크 의 할리우드 원칙 이라고 말합니다 . "우리를 부르지 말고 전화하겠습니다." 대조적으로, 라이브러리를 사용할 때마다 코드 는 반대 방향이 아닌 라이브러리를 호출합니다 .

보시다시피 중요한 점은 누가 통제를 하는가, 즉 통제의 흐름을 통제하는 것입니다. 누가 어느 명령문이 어떤 명령문 이후에 실행되는지를 누가 결정합니까?

찬반론과 반대론이 있으며, 이러한 끝없는 토론을 볼 때마다 나는 이것이 객관적으로 결정할 수있는 질문이 아니라 취향의 문제라고 생각하는 경향이 있습니다. 그렇지 않으면 이미 결정되었을 것입니다.

내 관점에서, 프레임 워크 또는 라이브러리 사용을 선호하는지 여부는 어떤 종류의 개발자인지에 대한 정보를 제공하며 두 가지 방법 중 하나가 우수하고 궁극적으로 우위에 있는지 여부가 아닙니다.

프레임 워크를 선호하는 경우 보안을 위해 자유를 교환하는 것을 선호합니다. 아마도 더 실용적이고 다른 사람들이 자신의 작업을 올바르게 수행하는 것을 신뢰하는 경향이 있습니다. 도서관을 선호한다면 자유를 위해 보안을 교환하는 것을 선호합니다. 당신은 아마도 이상 주의자 일 것이고 다른 사람들의 아이디어와 주장에 의문을 가질 것입니다.

나는 전자와 후자가 더 낫다고 결정하는 것이 현명하다고 생각하지 않습니다.

질문에 대답하기 : 프레임 워크가 너무 많은 추상화를 적용합니까? 그것은 당신이 누구인지, 특히 당신이 편안하게 느끼는 첫 번째 원칙으로부터의 거리에 달려 있습니다.

...

더 구체적으로, Django와 같은 프레임 워크가 마음에 들지 않으면 Flask와 같은 "microframeworks"를 검색하십시오. :)