풍부한 프레임 워크가 프로그래머를 무너 뜨리는가? [닫은]

요즘에는 ORM , DI ( 종속성 주입 ), IoC ( Inversion of Control ) 등의 모든 프레임 워크를 사용할 수 있기 때문에 많은 프로그래머가 어려운 문제를 해결하는 데 필요한 문제 해결 기술을 잃거나 잃어버린 것으로 나타났습니다. 여러 번, 예상치 못한 동작이 응용 프로그램으로 들어오고 개발자가 실제로 문제를 찾아 낼 수없는 것을 보았습니다. 후드에서 무슨 일이 일어나고 있는지에 대한 깊은 이해가 사라지고있는 것 같습니다.

잘못 이해하지 마십시오. 이 프레임 워크가 좋지 않고 업계를 발전시키지 않았으며 의도하지 않은 결과로 개발자가 깊이 이해하는 데 필요한 지식과 기술을 얻지 못하고 있는지 묻기 만하지 않습니다. 시스템.

동의했다. 저는 현재 프레임 워크에 의해 방해를받는 소프트웨어 패키지로 작업하고있어 비즈니스를 이해하는 것이 거의 불가능합니다. 일단 프레임 워크가 MVC를 해결하는 대신 실제로 비즈니스 문제를 해결하지 못하게되면 너무 멀어졌습니다. IMO는 많은 프로그래머들이 ORM과 MVC를 해결하기 위해 시도하고 설계 / 프로그래밍하려고 노력하고 있으며, 실제로 소프트웨어가 문제를 해결하는 데 어떤 식 으로든 도움이되는지 거의 묻지 않습니다.

예, JSP 페이지 에서 일부 원시 SQL을 보는 것은 "아니요"이지만 현장 컨설턴트라면 특정 솔루션에 적합한 것은 무엇입니까? 그렇다고해서 프레임 워크가 옳지 않다는 것은 아닙니다. 모든 고객이 매 페이지마다 2 천만 달러를 지불하는 것은 아닙니다.

이것은 많은 분야와 여러 형태로 정기적으로 나타나는 논쟁입니다.

이 인수의 일반적인 형태는 다음과 같습니다.

[x : 도구 / 기술]을 사용하면 [x의 영향을받는 y : 기능]에서 사람들이 더 악화됩니까?

예를 들면 다음과 같습니다.

• CAD 소프트웨어는 엔지니어를 더 악화 시키나요?
• 고등학교의 계산기로 학생들이 수학을 더 악화 시키나요?
• 소셜 소프트웨어는 사람들의 대면 소셜 기술을 방해합니까?
• 회계 소프트웨어는 더 나쁜 회계사를 생산합니까?

기억에서 유비쿼터스 해답은 거의 항상입니다. 실제로는 아닙니다. 당신은 항상 [y]에 능숙하고 나쁜 사람들을 갖게 될 것입니다. 그러나 지금 그들은 다른 기술면에서 나빴습니다.

어떤 작업을 수행하더라도 기본 사항에 대한 더 깊은 이해는 무엇을하든, 심지어 '치료'로 간주되는 작업까지 도움이 될 것입니다. 지식은 항상 도움이됩니다.

추상화는 프로그래머가이를 달성하는 데 도움이되는 컴퓨터 프로그래밍 및 프레임 워크의 핵심 개념입니다. 이것은 좋은 일입니다. 많은 사람들이 어셈블리 언어로 복잡한 시스템을 개발하고 싶다고 생각합니다! 프로그래머가 추상화 레이어가 마스킹하는 것에 대해 거의 알지 못하는 경우 문제가 발생합니다. 다시 말해, 직접 상호 작용하거나 인터페이스하지 않더라도 후드에서 어떤 일이 벌어지고 있는지에 대한 아이디어가 필요합니다.

C와 CGI를 사용하여 90 년대 중반에 최초의 동적 웹 사이트를 개발 한 것을 기억 합니다 (대부분의 웹 사이트는 여전히 정적 HTML 임). PHP 나 ASP와 같은 성숙한 서버 측 스크립팅 언어와 라이브러리는 거의 없었으므로 모든 페이지와 함께 서버에 전체 HTTP 응답 스트림을 작성해야했습니다. GET 및 POST 매개 변수를 구문 분석하려면 자체 라이브러리를 작성해야합니다. 지루하고 느리고 열심히 일했으며 오류가 발생하기 쉽습니다. 나는 그것을 조금 놓치지 마세요!

그러나 ASP.NET 웹 양식과 같은 프레임 워크는 많은 새로운 웹 개발자가 실제로 무슨 일이 일어나고 있는지 전혀 알지 못하는 시점까지 웹의 상태 비 저장 특성을 추상화합니다. 이는 개발자가 HTTP 수준에서 무슨 일이 일어나고 있는지 알지 못하고 "드래그 앤 드롭"방식을 사용하여 구성 요소를 함께 연결하기 때문에 성능이 저하되고 부풀어 오른 코드로 이어집니다.

따라서 프레임 워크는 고급 소프트웨어를 개발하는 데 필수적이라고 생각하지만 추상화되는 내용을 이해하는 개발자를 배제하지는 않습니다. 예, 프레임 워크를 사용하면 바보가 될 수 있지만 이해하지 못하는 경우에만 가능합니다.

자동 변속기 또는 레인 센싱 윈드 실드 와이퍼가 운전자를 더 악화 시키는가?

프레임 워크가없는 코딩이 기본 시스템에 대한 더 나은 이해를 의미한다고 생각하지 않습니다. 이것은 응시자가 후보자가 일관된 방법을 함께 사용할 수 있도록하기 위해 인터뷰에서 간단한 코딩 질문을해야한다는 증거입니다.

궁극적으로 배우는 것은 개발자의 몫입니다. 좋은 사람은, 나쁜 사람은 그렇지 않습니다.

비슷한 맥락에서, 실제로 기능과 장단점을 분석하지 않고 프레임 워크가 존재하기 때문에 프레임 워크를 고르는 것도 열악한 개발 관행의 징조입니다.

문제는 새로운 프로그래머가 점점 더 높은 추상화 수준에서 시작하여 '후드'아래의 비트와 바이트에 노출되지 않는다는 것입니다. 따라서 그들은 몇 년 전에 가장 먼저 배워야 할 기본 코딩 기초를 배우지 않습니다.

나는 분명히 새로운 프로그래머가 데이터를 저장하는 것에 대해 무언가를 요구할 때마다 항상 머리를 흔든다. 모든 사람이 즉시 ORM 도구 를 사용하라고 말한다 . 아니요, 아니요, 아니요, 아니요, 아니요. 먼저 스스로하는 방법을 배워야합니다.

아마도 "멍청함"의 분포는 실제로 바뀌지 않았으며, 개발자가 발을 딛을 수있는 더 크고 복잡한 방법을 제공하고 있습니까?

프로그래머를 바보로 만드는 것은 프레임 워크가 아닙니다. 벙어리 프로그래머는 프레임 워크 사용 여부에 상관없이 바보입니다.

도구 또는 프레임 워크가 간소화하는 데 도움이되는 하위 수준의 작업을 이해하면 도구 및 프레임 워크를 더 잘 사용할 수 있습니다. 또한 문제를보다 쉽게 ​​디버깅 할 수 있으며 기능의 불가피한 차이를 해결할 수 있습니다.

예를 들어, 나는 대학의 Compiler Design에서 lex와 yacc와 같은 파서 생성기를 사용하는 법을 배우기 전에 C에서 LR 파서를 처음부터 코딩했습니다. 그것은 매우 교육적이었고 그 이후로 내가 사용한 모든 프로그래밍 언어에 대해 더 잘 이해하고 감사했습니다.

그러나 나는 모든 프로그래머가 미야기 씨의 차를 왁싱하여 고수준으로 일하기 전에 수년 동안 수고해야한다고 말하지는 않습니다. 많은 프로그래밍 작업은 지적 언어이며 소프트웨어 가 특정 언어 나 도구로 코딩하는 기계적인 작업이 아니라 소프트웨어에서 필요한 작업을 결정합니다 .

그 지적 작업은 똑똑 함과 멍청함이 더 중요한 곳입니다.

James Larus의 탁월한 "Spending Moore 's Dividend" 에서 인용 한 내용 (강조 추가) :

30 년 전 Bill Gates는 5 바이트의 메모리를 절약하기 위해 Altair Basic의 프롬프트를“READY”에서“OK”로 변경했습니다. 오늘날 개발자는 프로그램에 대해 걱정할 필요없이 이러한 수준의 프로그램 세부 사항을 알고있을 것입니다. 당연히이 규모의 변화는 눈에 띄지 않기 때문에 오늘날의 시스템을 만들 수있는 방법 은 없습니다 4K의 메모리를 가진 머신에서 가능하고 (필요한) 숙련 된 수공예를 사용합니다.

프레임 워크를 통해 어려운 문제를 해결하는 데 필요한 기술을 피하거나 깊은 이해를 피할 수 있다고 말하는 것은 오해의 소지가 있습니다. 대신 오늘날 복잡한 시스템을 구축 할 수 있는 유일한 이유 (복잡성이 어려운 문제를 생성하고 깊은 이해를 거부 할 수있는)는 프레임 워크 (및 고급 OO 가비지 수집 언어 및 상황에 맞는 도움말 및 즉각적인 구문 검사 및 때로는 프로그래머를 바보로 비난하는 다른 모든 소프트웨어 개발 발전).

프레임 워크가 훌륭합니다. 그러나 후드 아래에 무엇이 있는지 알아야합니다. 문제는 프로그래머가 기본 시스템에 대한 충분한 지식이 없어도 프레임 워크에 너무 의존한다는 것입니다.

다소 오래된 예는 MFC입니다 . 프로그래머는 Windows API 대신 MFC를 사용하여 많은 시간을 절약 할 수 있지만 API에 대한 지식이 없으면 (원시 API에 대한 실제 작업 배경이 있음) 종종 멈출 것입니다 . 일반적인 MFC 프로그래머는 Windows API 지식을 가지고 있기 때문에 거의 발생하지 않았습니다.

그러나 함께 윈도우 폼 에 .NET 더 나은 캡슐화 및 더 나은 개체 모델, 감사, 프로그래머는 거의 그는 단지 다른 Windows API 래퍼를 사용하고 있음을 무시할 수 있습니다. 따라서 막힐 가능성이 적지 만 발생하면 다칠 수 있습니다.

불행히도, 출시 시간은 항상 짧고 프로젝트는 점점 복잡해 지므로 프로그래머는 깊이 갈 시간이 없습니다. 그것은 소프트웨어 산업의 슬픈 상태입니다 ...

필요한 곳에 스마트를 배치합니다. 건물 꼭대기에서 공을 떨어 뜨리는 메커니즘을 설정하기 위해 양자 역학과 뉴턴 물리학을 이해할 필요는 없습니다. 소프트웨어의 모든 새로운 계층 은 마지막 에 구축하고 유용한 응용 프로그램의 구성 에서 상용구 를 제거 해야 합니다.

프레임 워크 뒤에있는 "재료"를 필요로하거나 알고 싶은 사람들은 후크 또는 도둑으로 연구하고 조사 할 것입니다.

아뇨, 절대 아닙니다 기본적으로 프레임 워크는 서브 루틴 라이브러리와 템플릿, 두 가지 시도되고 진정한 프로그래머 도구의 조합입니다. '가난한 노동자가 그의 도구를 비난합니다 ...

... 그리고 프레임 워크를 사용하고 비난 하는 많은 가난한 노동자들이 있습니다.

소프트웨어를 구축 할 때 프레임 워크는 시간을 절약합니다. 소프트웨어 구축을 배울 때 프레임 워크는 이해하는 데 방해가됩니다.

문제는 주로 너무 강력한 컴퓨터 중 하나라고 생각합니다. 대부분의 프로그래머에게는 더 이상 "기본에 도달"해야 할 합리적인 이유가 없습니다. 동일한 작업을 수행하는 데 더 많은 시간이 걸리며 런타임에는 의미있는 차이가 없습니다. 이를 해결하는 유일한 방법은 js1k와 같은 경쟁 방식과 같은 인공적인 제한을 도입하는 것입니다.

어쩌면 학교는 시간과 공간의 제약이 큰 프로그램을 만들어야하는 "최적화 된 디자인"이라는 주제를 가지고 있어야합니까?

아닙니다. 프레임 워크를 배우면 프로그래머의 기술이 향상됩니다. 프레임 워크는 프로그래밍 언어의 확장입니다. 일부 언어는 이미 프레임 워크 기반입니다. PHP와 Java 모두에서 작업합니다. PHP는 템플릿 엔진과 같은 프레임 워크가 필요합니다 (때로는). Java는 프레임 워크가 필요하지 않으며 (대부분) 이미 많은 메소드와 라이브러리가 있습니다.

대부분의 프레임 워크에는 프로그래머가 반복해서 사용하는 기능이 있습니다.

여기서 악마의 옹호자 역할을하는 것처럼, 프레임 워크 ( "좋은"프레임 워크)는 실제로 프로그래머의 교육 을 발전시키는 데 먼 길을 갈 수 있다고 생각 합니다. 잘 설계된 프레임 워크는 많은 문제를 해결하며, 프레임 워크를 사용함으로써 프로그래머는 어떤 문제가 어떻게 해결되는지 이해할 수 있습니다. 내 마음에, 프레임 워크는 프로그래밍 모범 사례의 결정화 (/해야 함)이며 프로그래머가 예를 들어 가르 칠 수 있습니다.