학교 프로그래밍과 산업 프로그래밍의 차이점은 무엇입니까? [닫은]

많은 학생들이 졸업하고 첫 직장을 구할 때, 대학에서 좋은 프로그래머 였을지라도 실제로 어떻게 프로그래밍해야할지 모른다고 생각합니다.

학업 환경에서의 프로그래밍과 '실제 세계'에서의 프로그래밍의 차이점은 무엇입니까?

전통적인 학부 컴퓨터 과학 프로그램에서는 프로그래밍 만 배웁니다 . 그러나 실제 세계는 단지 프로그래머 인 사람들을 원하지 않습니다 . 실제 세계는 실제 소프트웨어 엔지니어를 원합니다. 나는 많은 직업 설명이이 구별을 표현하지 않는 것으로 알고 있습니다. 현실에서는 다음을 수행 할 수 있어야합니다.

• 직접 제공되지 않은 요구 사항 수집 및 분석
• 거의 무한한 가능성으로 아키텍처 설계 및 분석
• 테스트 계획을 작성 하고 시스템 품질을 평가하고 개선 하기 위해 조치를 취하십시오.
• 배경과 경험 수준이 다른 사람들로 구성된 팀 에서 공동 작업
• 무엇을 제작해야할지 정확히 모르더라도 작업을 추정하고 계획
• 꼭 맞지 않아도되는 다양한 요구를 가진 이해 관계자와 효과적으로 의사 소통
• 이해 관계자를 실망시키지 않으면 서 일정, 예산, 품질 및 기능 협상

예, 소프트웨어 엔지니어 시간의 평균 40-60 % 만 걸리지 만 코드도 작성할 수 있어야합니다.

따라서 신입생 컴퓨터 과학 학부생들이 프로그래밍 방법을 모른다는 것은 아닙니다 (많은 사람들이 실제로는 훌륭한 프로그래머입니다). 그들 중 많은 사람들이 다른 일을하는 방법을 모른다는 것입니다.

대학교에서...

선생님이 제공합니다 :

• 짧고 명확하게 정의 된 시간 범위 내에 솔루션을 제공 할 수있는 잘 정의 된 격리 된 문제 (그리고 나중에 폐기 됨)
• 할당하기 전에 소개 된 잘 정의 된 도구 세트
• 솔루션의 품질에 대한 잘 정의 된 측정 값으로 솔루션이 충분한 지 여부를 쉽게 확인할 수 있습니다.

"실제 세계"에서 ...

• 문제는 모호하고 복잡하며 상황에 따라 달라집니다. 시간이 지남에 따라 변하는 모순적인 요구 사항이며, 솔루션은 수용 가능한 시간 내에 해당 변경 사항에 대응할 수있을 정도로 유연하고 강력해야합니다.
• 도구는 반드시 선택해야합니다. 팀의 10 살짜리 코드베이스에 이미 사용 가능한 것이 있거나, 오픈 소스 프로젝트가 있거나, 상업용 라이브러리가 있거나, 직접 작성해야 할 수도 있습니다.
• 소프트웨어의 현재 반복이 개선인지 여부를 확인하려면 ( 소프트웨어 프로젝트로 는 거의 수행 하지 않기 때문에 ) 회귀 테스트 및 사용성 테스트를 수행해야합니다. 후자는 일반적으로 모호하고 복잡하며 모순됨을 의미합니다 컨텍스트 임베디드 요구 사항이 다시 한 번 이동합니다.

결론

학교에서의 프로그래밍과 현실에서의 프로그래밍은 본질적으로 겹치는 부분이 거의 없다는 점에서 본질적으로 다릅니다. CS는 육상 훈련이 군대를 준비시키는 것처럼 "실제"소프트웨어 개발을 준비 할 것입니다.

그들은 문제의 다른 측면에 직면합니다.

학계는 주로 "프로그래밍 과학"에 중점을 두어 효율적인 특정 알고리즘을 만들거나 특정 패러다임을 더욱 표현하기위한 언어를 개발하는 방법을 연구합니다. 산업은 주로 판매해야하는 제품을 생산하는 데 중점을두고 있습니다. 언어와 알고리즘뿐만 아니라 라이브러리, 프레임 워크 등의 "도구"에 의존해야합니다.

"포커스"의 이러한 차이는 C의 학계 마스터가 Windows 응용 프로그램을 실제로 작성할 수 없게 만드는 이유입니다 (Windows API가 C99 표준에 없기 때문에!). 그러나 실제로 그는 자신이 잃어버린 것을 스스로 배울 수있는 모든 기능을 갖추고 있습니다. 적절한 학문적 연구가 없다면 (아카데미아에서 만들어 질 필요는 없음) 찾기가 매우 어렵습니다.

좋은 답변입니다. 제가 덧붙이 자면, 아카데믹 프로그래밍은 규모가 거의 장난감 같은 경향이 있습니다. 이것은 가르치기에 좋습니다. 교사로서 아이디어를 가장 효율적으로 전달하려고합니다. 단점은 현실적인 프로그래밍이 질적으로 다르다는 점입니다. 격차를 해소하기는 어렵습니다.

차이점 중 하나는 성능 분석에 있습니다. 나는 이것을 지적하려고 많은 게시물을 작성했습니다. 성능 분석은 알고리즘 및 측정에 대한 피상적입니다. 실제로 효과적으로 수행하려면 디버깅 프로세스로 접근해야합니다.

다른 차이점은 유지 보수성입니다. 여기에는 스타일에서 도메인 별 언어 디자인에 이르는 모든 것이 포함됩니다. 실제로 최소화하려는 것을 모르지 않으면 효과적으로 수행 할 수 없습니다.

이런 것들을 가르치지 않고 생산성에 엄청난 차이를 만듭니다.

학계에서는 대부분의 사람들이 컴퓨터 과학 또는 관련 과정을 공부합니다. Dijkstra는 한때 "컴퓨터 과학은 천문학이 망원경에 관한 것보다 컴퓨터에 관한 것이 아닙니다"라고 말했습니다. 컴퓨터 과학을 공부하는 사람은 프로그래머가 아닌 과학자가되는 것을 가장 먼저 배우는 것입니다. 프로그래머로서 그는 아마추어를 유지하게되므로 전문 프로그래머로의 전환은 어렵습니다.

업데이트 : 누군가 내 마음을 읽는 것처럼 : 대학원 기대와 현실 ...

내 두 가지 다른 요소 :

문제 규모 : 학계에서 나는 주로 "처음부터"소프트웨어를 개발해야했는데, 이는 내가 만난 가장 큰 프로그램이 내가 쓴 가장 큰 프로그램이라는 것을 의미했다. 이는 서로 상호 작용하는 서로 다른 소프트웨어에서 발생하는 복잡성을 처리하고 처리하는 데 필요한 기능을 강조하지 않습니다. 복잡성을 이해하는 데 필요한 노력을 알고 있다면 전혀 업계에 있지 않기로 선택했을 수 있습니다.

Reading VS Writing : 문제 크기의 또 다른 부작용은 종종 "실제 세계"에서 유지 보수 목적 (어디서나 학계에서 유지 보수를하지 않은), 확장 또는 단순히 다른 사람들이 작성한 작업에 노출된다는 것입니다. 분업. 따라서 코드를 읽는 것보다 코드를 읽는 것이 여러 번 중요해집니다.

프로그래밍 교육 개선 제안 : 학계는 직업 훈련으로 돌아 가지 않고 실제 상황에 더 많이 노출되어야합니다. 의사는 어떤 시점에서 시체를 대면하여 "만들기"인지 확인해야합니다 (이 경험이 끝난 후 사람들이 강의를 중단한다는 이야기를 들었습니다). 20 대 초반에 다른 프로그래밍 스타일로 구성된 20K LOC 프로젝트를 본 적이 있다면 언젠가 이해하고 3 일 안에 버그를 수정해야했을 것입니다.

내가 학문과 산업 프로그래밍에서 찾은 가장 큰 차이점은 견고성입니다. 대부분의 사람들은 자신의 경력에서 "그것은 저에게 효과적"이라는 역설을 경험했으며, 이것은이 조건의 확장입니다. 학계에서는 알고리즘과 기능에 중점을두고 있으며 일상적인 조건에서 소프트웨어의 유용성과 안정성에 대한 관심은 거의 없습니다.

예를 들어, 내 사무실에는 소프트웨어를 가져와 코너 상황에서 충돌을 일으킨 엔지니어가 있습니다. 그는 무언가가 충돌 할 때까지 최대한 빨리 버튼을 클릭합니다 ... 작업이 너무 오래 걸리면 화면 주위를 무작위로 클릭하기 시작합니다 (절망이 없습니까? IDK ....).

프로그래밍 철학을 변경하여 "스티브 증거"를 만들면 일반적으로 응용 프로그램의 안정성이 향상됩니다.

저는 학교에서 프로그래밍 교육에 대한 개인적인 경험이 없습니다. 저는 영어 전공이었습니다. Keats와 Byron에 대해 물어보세요!-하지만 저는 몇 가지 새로운 졸업생을 받아 전문 소프트웨어 개발 분야에서 멘토링했습니다. 그래서 저는 그런 관점에서 말할 수 있습니다.

내 경험은 그들이 학교에서 얻은 모든 것이 프로그래밍에 관심이 있다는 것입니다. 그들의 기술은 0에서 무시할 정도로 다양했습니다. 자기 지시 능력은 가장 능숙한 사람들에게도 존재하지 않았습니다. 그들의 생각은 소규모가 아니었다. 그들은 실제로 미니어처로 생각했습니다. 수십 줄 이상의 코드로 구성된 시스템으로 인해 코드가 완전히 무너졌습니다.

그러나 당신은 무엇을 알고 있습니까? 그들은 관심 을 얻었고 그것은 큰 문제입니다. 관심은 많다 . 관심있는 사람과 함께 일할 수 있습니다 . 그들이 저에게 관심이 있다면 개발자 로 바꿀 수 있습니다 . 지옥, 그게 내가 시작한 전부 입니다. 현대 미국 소설가들에게 감사의 말을 전합니다.

학계에서는

결점

• 우리는 주로 점수를 올리는 마감일이 있습니다.
• 대부분의 프로젝트는 실제 응용 프로그램에서 사용되지 않으므로 버그는 실제로 문제를 일으키지 않습니다.

플러스

• 연구 할 시간이 충분합니다.
• 초기 목표에서 흔들리는 것은 큰 문제를 일으키지 않습니다.

업계에서는

• 우리는 실제로 회사에서 사용할 프로젝트를 진행합니다.
• 우리는 끊임없이 변화하는 고객 요구 사항을 강조하고 있습니다.
• 소프트웨어 회사와 고객 모두에게 막대한 재정적 손실을 초래할 수 있기 때문에 마감일은 거의 유연 하지 않습니다 .

이것 좀 봐:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

아카데믹 프로그래밍은 직접 코딩하는 것에 관한 것입니다. 작동 방식을 배우는 데 중요합니다. 코드 품질 및 개정 관리는 그다지 중요하지 않습니다. 주목할만한 예외가 있지만 코드는 할당을 초과하는 수명이 없습니다. 프로젝트의 범위는 상당히 제한적인 경향이 있으며 크립 가능성이 낮습니다.

현실에서는 가능한 한 원래 코드가 거의 없어야합니다. 많은 코드가 팀에 의해 개발되었습니다. 직접 코딩하는 것보다 라이브러리 루틴을 사용하는 것이 좋습니다. 코드 품질 및 개정 관리가 더욱 중요해졌습니다. 코드는 원래 예상했던 것보다 훨씬 긴 수명을 갖는 경향이 있습니다. 프로젝트 범위는 일반적으로 상당히 넓으며 관리하지 않으면 크게 영향을받는 경향이 있습니다.

사실은,

학문적 수준의 프로그래밍과 실제 프로그래밍을 완전히 구별하는 것은 불가능합니다.

가장 큰 차이점은 다음과 같습니다. 실제 프로그래밍에서는 프로그래밍 이상의 것을 알아야하며 빠르게 적응할 수 있어야합니다.

업무를 수행하는 부문에 따라 해당 법률을 준수해야합니다.

Michael은 프로그래밍 관련 작업을 말함으로써 빙산의 일각에 손을 대었습니다. 나는 쉬운 물건으로 분류 할 것입니다 (당신이 반죽의 가치가 있다면 지불되고 있습니다).

일반적으로 업계에서 주제 당 최소한 두 가지 과제에 직면하게됩니다.

• 준거법 (예 : 의료에 대한 고객 기밀 유지)
• 주제 노하우 (예 : 송장 세 시스템, 재고, 자원 관리, 의료 제도, 산업 표준)
• 산업 표준 / 정부 법률이 없거나 존재하지 않거나 다른 고객 요구 사항

연구 박사 수준의 프로그래밍 프로젝트와 실제 프로젝트를 비교하면 어려움, 입학 수준의 노하우 등이 매우 유사 할 수 있습니다.

유일한 실제 차이점은 실제 프로젝트는

• 의뢰인이있다
• 예산이있다 (시간, 돈, 인적 자원)

다른 사람이 규칙을 만들 때 다른 볼 게임입니다. :)

학계의 IT에서 공부 한 과목을 살펴보면 수학, 과학, 선택 과목 등에서 소요되는 시간의 약 절반은 컴파일러 디자인, 알고리즘 이론, 컴퓨터 아키텍처, 최적화, 운영 체제, 디지털 전자 공학 및 C 프로그래밍 및 웹 프로그래밍과 같은 산업과 관련된 몇 가지 다른 코스.

위에서 언급 한 주제의 대부분은 알기 쉽지만 일상적인 IT에 필요한 사항에 대한 강력한 배경 지식을 제공하지는 않습니다.

Microsoft 웹 프로그래밍 요구 사항 (즉, 조직에서 생산적인 팀 구성원이되는 데 필요한 영역)을 가져옵니다.

1- C # .NET 또는 VB.NET

2- ASP.NET

3- HTML과 CSS

4- SQL Server (또는 다른 데이터베이스)

5-OO 애플리케이션 프로그래밍 및 디자인

6-자바 스크립트

7- MVC 프레임 워크

8- 소스 제어 툴에 대한 노출

9- 자동화 된 테스트 툴에 대한 노출

10 버그 추적 도구

11 전자 상거래 개념 (선택 사항)

12-ORM

13- 일부 비즈니스 분석 기술

14 가지 의사 소통 기술

15- 아마도 일부 클라우드 컴퓨팅 기본 사항

당신이 볼 수 있듯이, 위의 요구 사항의 대부분은 대학 / 대학에서 거의 초점을 맞추지 않습니다 (일부 과정은 최대 1 개를받을 수 있음).

그러한 많은 기술들이 존재하고 계속 변화하고 있기 때문에 기관을 완전히 비난 할 수는 없습니다.

Microsoft의 위의 대부분은 Java로 응용 프로그램을 개발하려는 사람에게는 도움이되지 않습니다.

실제 문제는 오늘날 비즈니스에 필요한 기술 스택 중 하나가 완전히 포함되지 않는다는 것입니다.

위의 내용은 졸업생이 비즈니스 환경에서의 프로그래밍과 같은 비즈니스 직종에 대한 적합성 문제를 다룹니다. 실험실 등을 연구 할 필요성은이 답변에서 다루지 않습니다. 또한 게임 개발, 임베디드 개발, 실시간 시스템 개발 등과 같은 다른 영역에서도 위의 기술보다 더 많은 기술이 필요합니다.

규모 및 초점
내 경험, 학업 환경에서 일반적으로 작업하는 응용 프로그램의 규모는 훨씬 작습니다. 하루 또는 주에 완료 할 수있는 것, 또는 한 두 명의 프로 게 머가 한 학기 동안 일반적으로 작성하는 모든 것은 용어 뒤에 버려진 폐기 코드입니다. 실제로는 더 큰 팀이 몇 년이 아니라 몇 달이 걸리더라도 완전히 개발하는 응용 프로그램을 개발하고 있다고 생각할 수 있습니다. 더 많은 시간을 보내고 다른 사람들의 코드를 디버깅하고 코드베이스의 구조를 이해하려고 노력하면서 기존 부품을 손상시키지 않고 새로운 요구 사항이나 수정 된 요구 사항을 추가하지 않습니다.

요구 사항, 통합, 고객
또한, 요구 사항 분석, 통합 테스트 등과 같이 학술 프로젝트에서 덜 대표되는 경향이있는 코드 개발 측면이 있습니다. 공정한 채점을 위해 일반적으로 요구 사항은 강사에 의해 이미 설정되어 있으며 회의에서 공동으로 결정되지 않습니다. 고객이 원하는 것이 아닌 특정 접근 방식에 대해 "고객을 판매"할 필요는 없지만 기술적 인 관점에서 실제로는 원하는 바와 달리 가능합니다. 학업 환경에서 고객 (학년 또는 강사)은 자신이 원하는 것을 매우 구체적으로 생각하는 경향이 있습니다. 실제 세계에서는 자신이 원하는 것을 실제로 알지 못하고 무엇을 이해하기 위해 두뇌를 선택해야하는 고객을 만날 수 있습니다 구축해야합니다.

유지 관리 및 유지 관리

학계 (적어도 학부 수준)에서는 소프트웨어가 단기 목표를 염두에두고 개발되며 대개 숙제 나 과제 프로젝트를 완수합니다. 과제가 완료되면 코드가 삭제되고 다시 표시되지 않습니다.

전문적인 환경에서 대부분의 소프트웨어는 장기간 사용하도록 작성되었습니다. 소프트웨어는 최소 몇 년 동안 사용되도록 고안되었으며 시간이 지남에 따라 쉽게 유지 관리 및 업데이트 할 수 있도록 구축해야합니다.

이것과 관련하여 유지 보수 작업입니다. 전문 프로그래밍 작업의 대부분은 기존 소프트웨어 업데이트 또는 유지 관리와 관련이 있습니다. 소위 "그린 필드"프로젝트는 표준이 아니라 예외입니다.