프레임 워크를 사용하지 않을 때 [폐쇄]

오늘날에는 거의 모든 프로젝트에 적합한 언어에 대한 프레임 워크를 찾을 수 있습니다. 대부분의 최신 프레임 워크는 몇 시간에 걸친 테스트, 동료 검토 코드 및 뛰어난 확장 성을 통해 상당히 견고합니다 (일반적으로 말하면).

그러나 커뮤니티에서 프로그래머가 선택한 프레임 워크에 너무 의존하여 더 이상 기본 작업을 이해하지 못하거나 새로운 프로그래머의 경우 기본 작업을 배우지 않는다는 단점이 있습니다. 로 시작하십시오. 더 이상 'PHP 프로그래머'(예 :)가 아니라 "Drupal programmer"가되어 다른 것을 배제 할 정도로 전문화되기 쉽습니다.

누가 신경 쓰겠어요? 우리는 틀을 가지고 있습니다! "손으로하는"방법을 몰라도됩니다! 권리?

이러한 기본 기술의 상실의 결과 (때로는 프레임 워크를 사용 하지 않는 프로그래머 가 "오래된"것으로 간주되는 정도 )는 필요하지 않거나 적절하지 않은 프레임 워크를 사용하는 것이 일반적 관례가됩니다. 프레임 워크는 기본 언어 의 기능 과 혼동 될 수있는 기능을 제공합니다. 개발자는 프레임 워크를 사용하여 가장 기본적인 작업조차 수행하기 시작했습니다. 따라서 기본 프로세스로 간주되었던 것은 이제 고유 한 단점, 버그 및 종속성이있는 큰 라이브러리를 포함합니다. 한 번 20 줄로 달성 한 것은 이제 20,000 줄 프레임 워크를 포함하고 프레임 워크를 사용하기 위해 20 줄을 작성함으로써 이루어집니다.

반대로, 바퀴를 재발 명하고 싶지 않습니다. 기본적이고 일반적인 작은 작업을 수행하기 위해 코드를 작성하는 경우 프레임 워크 XYZ가 내가 따르는 모든 기능과 그 이상을 제공한다는 것을 알면 시간을 낭비하는 것처럼 느낄 수 있습니다. "더 많은"부분은 여전히 ​​걱정 스럽지만 더 이상 많은 사람들이 그것을 고려하지 않는 것 같습니다.

프레임 워크를 사용하는 것이 적절한시기를 결정하기 위해서는 좋은 지표가 있어야합니다. 임계 값은 무엇 이며 프레임 워크 사용시기 또는 사용 하지 않을 시기 는 어떻게 결정 합니까 ?

"프레임 워크를 사용하는 것이 적절한시기를 결정하기 위해서는 좋은 척도가 있어야합니다."

실제로는 아닙니다. 기술의 적절한 사용을 결정하는 데 유용한 지표가 있다면 언어, 편집자 및 방법론에 대한 전쟁이 보이지 않을 것입니다.

내가 함께 일한 그룹은 모두 같은 일을한다. 비용과 이점을 추측하고, 가장 생산적인 경로를 선택하고 그들이 옳기를 바란다. 매우 과학적이지는 않습니다. 하나의 직관, 세 부분의 경험, 한 부분은 마케팅에 대한 감수성, 한 부분은 교활함, 5 개의 부분은 의견입니다.

프레임 워크는 도구 일뿐입니다. 프레임 워크가 과도하게 사용되면 프레임 워크의 잘못이라고 생각하지 않습니다. "해머가 있다면 모든 것이 못처럼 보인다"는 옛말은 컴퓨터조차도 오래 전에 존재했던 이런 사고 방식을 보여줍니다.

너무 전문화되면 실제로 생물 종뿐만 아니라 개발자에게도 문제가 될 수 있습니다. 장기 생존을 위해서는 여러 영역에서 자신의 기술을 개발하려는 노력을 신중하게 균형을 잡아야합니다.

귀하의 특정 질문에 대답하기 위해 이것에 대한 지표가 있다고 생각하지 않습니다. 문제 해결을 단순화 할 때 프레임 워크를 사용하는 것이 좋습니다. 프레임 워크를 사용하여 20 줄 대신 2 줄의 코드로 문제를 해결하는 데 도움이된다면 분명히 사용할 것입니다. 그러나 20 줄에 20 줄이 있어도 문제 영역에 더 가까운 추상화를 제공하여 코드를 더 쉽게 이해하고 유지 관리 할 수있는 프레임 워크를 사용하기로 결정할 수 있습니다.

일부 상황에서는 프레임 워크가 과도하게 사용될 수 있다고 생각합니다. 프레임 워크는 도구 일뿐입니다. 프레임 워크를 사용하면 무언가를 매우 빠르게 실행할 수 있으며 훌륭한 프로토 타이핑 도구입니다.

어딘가에서 응용 프로그램이 어느 정도 수준의 복잡성에 도달하면 프레임 워크에 내재 된 제한이 추가 성장을 방해하기 시작합니다. 요령은 그러한 티핑 포인트를 만났을 때이를 인식하고 이에 대해 무엇을할지 결정하는 것입니다.

나는 웹 응용 프로그램에서 가장 잘 작동하는 경향이 있으며 일반적으로 노력하고 있지만 내 대답 은 프로그래밍 영역에 적용 되지 않을 수 있습니다 .

또한 "라이브러리"와 동의어 인 "프레임 워크"를 사용할 것입니다.

프레임 워크를 구현하기 전에 몇 가지 사항을 고려해야합니다. 여기 몇 가지 일반적인 예가 있습니다.

#1. 프레임 워크가 시간과 노력을 절약 해 줍니까?

이 질문에 대한 대답은 거의 항상 그렇습니다 . 프레임 워크는 특정 문제 를 해결하고 잘 해결하는 경향이 있습니다 . 예를 들어 EntityFramework와 같은 프레임 워크를 사용하면 SQL 코드 작성 을 완전히 줄일 수 있습니다 . 프로그래밍 팀이 SQL에 유창하지 않은 경우 환상적 일 수 있습니다.

프레임 워크는 하나에 내장되어 a)는 다른 복잡한 구성 요소 나에게 프로그래머 친화적 인 인터페이스를 추가 ) 나 이미 잘) 알려진 (또는 설치 구성 요소에 추상화를 추가합니다.

후자 (또는 경우에 따라 전자)는 실제로 개발에 방해 가 될 수 있습니다 . 이것은 특히 당신이나 당신의 프로그래밍 팀이 새로운 프레임 워크를 구현하려고 할 때 적용됩니다 .

이로 인해 개발 프로세스 속도가 느려져 비용이 많이들 수 있습니다.

# 2 응용 프로그램의 규모

있다고한다 "아무것도 가치가하고 가치 무리가있다" , 그러나 보통 그런 경우가 아니다. 응용 프로그램의 포인트가 "potato" 를 인쇄하는 것이라면 초대형 프레임 워크를 구현할 이유가 없을 것 입니다.

응용 프로그램을 개발할 때 (웹, 데스크톱, 모바일 또는 기타 생각할 수있는 다른 유형의 응용 프로그램 일 경우) – 프레임 워크의 크기로 인해 (미래의) 구현이 "지워질"느낌이 들면, 이는 클 수 있습니다 프레임 워크가 애플리케이션을 부 풀릴 수 있다는 경고 표시. jQuery를 포함 시키면 문서가 준비 될 때 "로드 된"클래스를 본문 태그에 추가하기 만하면됩니다. 네이티브 자바 스크립트로하는 것이 조금 더 어려울 수도 있지만, 애플리케이션을 부 풀리지는 않습니다.

반면에 프레임 워크가 내부 (예 : 데이터베이스 프레임 워크)에서 많은 작업을 수행하는 경우 프레임 워크를 "부분적으로"사용하더라도 프레임 워크를 구현하는 것이 가능할 수 있습니다. 전체 라이브러리를 사용할 필요가 없기 때문에 자체 ADO.NET 또는 MongoDB 드라이버 를 작성 하지 않는 것이 좋은 일화입니다 .

때로는 프레임 워크가 오픈 소스로 제공됩니다 (및 '원하는대로'라이센스가 있음). 이것은 프로그래밍 팀이 프레임 워크의 일부만 선택할 수있는 새로운 가능성을 열어줍니다.

이것은 궁극적으로 질문 1과 3에 연결됩니다.

# 3 영향.

때때로 프레임 워크를 구현 하면 최종 사용자에게 직접적인 영향을 줄 수 있습니다 . 클라이언트 측 프레임 워크가 크면 최종 사용자의 경험에 부정적인 영향을 줄 수 있으므로 웹 응용 프로그램의 경우 특히 그렇습니다. 머신 속도가 느린 사용자는 렌더링 속도 저하, 자바 스크립트의 성능 문제 또는 하위 수준 머신으로 인한 유사한 문제가 발생할 수 있습니다. 연결 속도가 느린 사용자는 로딩 시간이 느릴 수 있습니다 (최소한 초기).

다른 유형의 응용 프로그램에서도 최종 사용자는 응용 프로그램 종속성에 의해 부정적인 영향을받을 수 있습니다. 프레임 워크는 항상 약간의 디스크 공간을 차지하며 , 모바일 앱 (또는 데스크톱 앱)을 개발하는 경우이를 고려해야합니다.

서버 측 프레임 워크 (보다 웹에 특화된)는 최종 사용자에게는 영향을 미치지 않지만 인프라 에는 영향을줍니다 . 어떤 프레임 워크 의존성이 스스로 당신이 당신의 웹 서버 중 단지 서비스 나 전체 서버를 다시 시작해야 할 수 있습니다.

일부 프레임 워크는 리소스 가 매우 많은 경우 도 있습니다 .

이것은 물론 1 번과 2 번 지점에 연결됩니다.

그것은 모두 "고려 사항의 원"일 뿐이며, 프레임 워크를 구현해야하는지 여부를 결정하는 실제 과학적 방법은 없습니다.

코빈 3 월은 그것을 매우 잘 요약했다.

내가 함께 일한 그룹은 모두 같은 일을한다. 비용과 이점을 추측하고, 가장 생산적인 경로를 선택하고 그들이 옳기를 바란다. 매우 과학적이지는 않습니다. 하나의 직관, 세 부분의 경험, 한 부분은 마케팅에 대한 감수성, 한 부분은 교활함, 5 개의 부분은 의견입니다.

엘리트가되지 않는 것도 중요 합니다. 프레임 워크는 사용되는 도구입니다. 나는 두 극단의 사람들을 안다. 한쪽에는 자신을 위해 인생을 매우 힘들게하는 사람이 있고 다른쪽에는 느리고 부풀린 응용 프로그램을 만드는 사람이 있습니다.

모든 프레임 워크에는 유스 케이스가 있으며 올바른 목적으로 구현하기 만하면됩니다.

다른 개발자가 프레임 워크를 알고 있습니까?

모든 개발자가 프레임 워크 X를 알고 있다면 프레임 워크를 사용하는 다른 모든 이유를 고려할 수 있다면 그렇게하십시오! 나에게, 개발 시간의 대부분이 프레임 워크의 복잡한 학습에 소비 될 때 특정 프레임 워크를 학습하도록 강요하는 것은 말이되지 않는다.

기초를 모르는 새로운 프로그래머에 대한 당신의 진술에 관해서는, 당신은 나보다 훨씬 더 동정심이 많습니다! 예, 부끄러운 일이지만 다른 사람의 부적합에 대해 걱정하면서 시간을 보낼 것입니까? 응 (이 새로운 커뮤니티 회원이 귀하와 즉시 협력하고 있지 않다는 가정을 기반으로합니다.)

다음 조건이 충족되는 경우 (그리고 경우에만) 프레임 워크를 사용합니다.

이 프레임 워크는 한동안 지원 될 것 같습니다. 나는 그들이 전에 나에게 인생의 끝을 가도록했다. 그리고 그것은 정말로 성가신 일이다. 특히 프로젝트에 9 개월이 걸리고 전환이 더 이상 옵션이 아닌 경우. 프레임 워크가 이미 더 이상 지원되지 않으면 해당 프레임 워크를 사용하여 새로운 것을 작성하기 전에 세 번 생각하십시오. 아무리 잘 알고 있더라도

프로젝트는 실제로 프레임 워크와 일치합니다. 아주 오래된 예로써, MFC의 기능을 보았습니까? 사람들은 그저 말이 안되는 유형의 앱에서 작동하도록 이상한 일을 끝내지 않았습니다. 일반적으로 원하는 앱을 작성하는 것보다 MFC에서 더 많은 시간을 소비합니다.

프로젝트 팀은 프레임 워크 내에서 작업 할 수 있습니다. 어떤 사람들은 주어진 프레임 워크에서 앱을 작성하는 방법을 이해하지 못하거나 시간을 내서 대신 프레임 워크가 필요로하는 방식 대신에 평소와 같이 물건을 작성합니다. 코드와 프레임 워크 사이의 이러한 불일치는 일반적으로 모든 사람에게 많은 시간과 노력이 들게됩니다.