왜 학교에서 이런 것들을 가르치지 않습니까?

왜 학교에서 이런 것들을 가르치지 않습니까? [닫은]

---

여름 동안 저는 Google Summer of Code에 들어갈 수있을만큼 운이 좋았습니다. 나는 많은 것을 배웠습니다 (아마도 모든 대학 교과 과정에서 배운 것보다 더 많은 것). 나는 그들이 왜 학교에서 빨리 배운 것들을 가르치지 않는지 정말 궁금합니다. 몇 가지 예를 들면 다음과 같습니다.

• 단위 테스트
• 버전 관리
• 민첩한 개발

데이터 구조 및 알고리즘과 같은 다른 것을 가르치는 데 많은 시간을 소비하는 것으로 보입니다. 나는 아직도 이것들이 조기에 배우는 것이 매우 중요하다고 생각하지만, 왜 그들보다이 세 가지를 더 많이 가르치지 않습니까? 아니면 이런 것들을 많이 가르치지 않는 학교일까요?

내가 틀리지 말아라, 나는 대학이 항상 최신 유행의 유행을 가르치는 것이 바람직하지 않다고 생각하지만, 교수가 "코딩을 시작하기 전에 다이어그램을 그리는 것"이외의 것을 가르쳐서는 안된다.

---

귀하의 질문에 대한 가장 간단한 답변은 컴퓨터 과학 및 소프트웨어 개발 분야가 매우 새롭고 잘 이해되지 않는다는 것입니다. 모든 과학 및 공학 분야가 현대에서 더 빠르게 발전하고 있지만 다른 분야에서는 더 많은 경험을 쌓을 수 있으며 작동 방식에 대한 광범위한 이해가 있습니다.

예를 들어, 최근 재료 과학의 발전에도 불구하고 토목 기술자는 약 2000 년 동안 쓰러지지 않는 아치를 만드는 방법을 알고 있으며, 이것은 비교적 논쟁이 적은 대학에서 가르치고 배울 수있는 것입니다. 소프트웨어 개발자가 배워야 할 기술에 대해 전적으로 동의하지만이 계약은 개인적인 경험과 비공식적 인 추론에 근거합니다. 사회적으로 받아 들여지는 "모범 사례"가 되려면 수집 비용이 매우 많이 드는 정량적 데이터가 필요합니다. 버전 관리가 얼마나 도움이됩니까? 어떻게 도움이 되나요? 단위 테스트? 우리는 다양한 기술의 효과에 대해 추론 할 수 있지만 실제로 그 효과를 결정적으로 증명하는 것은 매우 비쌀 것입니다. 처음부터 끝까지 완전하고 현실적인 소프트웨어 프로젝트를 실행해야합니다. 다른 기술을 사용하여 동등한 전문 지식을 가진 프로그래머 그룹과 함께 여러 번. 최소한 기존 프로젝트에 대해 발표하지 않으려는 기존 프로젝트에 대한 많은 데이터가 필요합니다.

토목 기사들은 수많은 정보와 함께 수천 년의 다리를 볼 수 있습니다. 반면에 소프트웨어 개발자는 수십 년에 불과한 정보를 보유하고 있으며 대부분의 정보는 비밀로 유지됩니다. 조직이 개발자의 효율성에 관한 정보를 수집하고 게시하더라도 (대부분의 '티).

필드가 혼동되기도합니다. 소프트웨어 개발 또는 소프트웨어 "엔지니어링"은 실제로 컴퓨터 과학과는 다릅니다. 소프트웨어 개발자는 컴퓨터 과학에 대한 실무 지식이 필요하지만 알고리즘 복잡성의 경계에서 작업하거나 병렬 처리에 대한 추론은 실제 프로그래머가 매일하는 일이 아닙니다. 마찬가지로, 실제 "컴퓨터 과학자"는 작동하지 않거나 흥미로운 작업을 수행하지 않는 수많은 버리기 코드를 작성하며 실제 소프트웨어 제품이 제공하는 엄밀한 이점을 얻지 못할 것입니다.

인터넷과 오픈 소스 커뮤니티의 등장으로 이러한 질문에 대한 답을 결정적으로 내릴 수있는 충분한 데이터가 제공 될 수 있지만, 내일 답변을받을 수 있다고해도 모든 사람이 학교에서 가르쳐야합니다.

마지막으로 몇 가지 경제적 고려 사항이 있습니다. 소프트웨어 개발에 참여하는 거의 모든 사람들이 원하는 개발 도구를 실행하기 위해 전용 시스템에 저렴하고 쉽게 액세스 할 수 있었기 때문에 비교적 짧은 시간이었습니다. 수십 년 전, 테스트를 실행하거나 무한한 소스 코드 히스토리를 저장하기 위해 기계를 완전히 헌신하는 것은 많은 사람들에게 엄청난 비용이 들었을 것입니다.

---

우리 선생님들은 :

1. 단위 테스트를 시도한 적이 없습니다.
2. 버전 관리를 사용하는 방법을 모른다
3. "민첩한 개발"에 대해 들어 본 적이 없습니다.

학생들은 스스로 문제를 해결해야합니다. 우리는 그렇게했고, 우리는 그렇게하지 않았습니까?

---

Leonardo da Vinci는 다음과 같이 썼습니다.

과학이없는 연습에 매료 된 사람들은 방향 타나 나침반없이 배를 타고 가고 어디로 가는지 확신 할 수없는 조종사와 같습니다. 연습은 항상 이론에 대한 건전한 지식을 바탕으로해야합니다.

좋은 학교는 이론 (데이터 구조, 알고리즘 등)과 실습 (단위 테스트, 버전 관리 등)을 모두 가르칩니다. 이를 위해서는이 동전의 양쪽을 제대로 가르 칠 수 있도록 적절한 교수진 조합이 필요합니다. 실제 경험이없는 이론적 유형으로 구성된 교수진은 그렇지 않습니다. 마찬가지로 전적으로 실무자로 구성된 교수진은 그렇지 않습니다. 당신은 혼합이 필요하고 좋은 학교가 있습니다.

---

컴퓨터 과학은 항상 다소 모순되었습니다. 컴퓨터에 관한 부분은 과학이 아니며, 과학에 관한 부분은 컴퓨터에 관한 것이 아닙니다.

대학은 '과학'의 끝 (알고리즘, 데이터 구조, 컴파일러 등)에 더 의존하는 경향이 있습니다. 왜냐하면 이러한 것들이 매년 진화하고 변화하는 경향이있는 현재 업계 모범 사례보다 훨씬 '시간이 지나지 않기'때문입니다. 예를 들어 Version Control은 지난 5 년에서 10 년 사이에 놀라운 변화를 겪었지만 big-O는 여전히 큰 O이며 해시, btree 및 재귀는 여전히 40 년 전만큼 유용합니다. 그들의 아이디어는 일반적으로 git와 같은 도구를 선택하고 기본 데이터 구조가 SHA-1 해시의 비순환 지향 그래프이며 개발자가 열심히 일했다는 것을 알 때 의미를 이해하는 데 충분한 기초를 제공하는 것입니다. io-bound되도록 syscall 수를 최적화합니다.

이제 마지막 문장을 이해하기 위해 알아야 할 모든 것을 어디서 배웠는지 생각해보십시오. 답이 '대학'이라면 괜찮은 일을하고 있습니다.

---

오리건 공과 대학 (Oregon Institute of Technology)에서 보조 교사 였을 때 이런 것들을 가르쳤다. 그들은 드물게 배웁니다.

---

모든 것이 지나가는 유행입니다. 대학에 다니는 첫 해보다 대학에서 첫 해에 더 많은 것을 배우게됩니다. 컴퓨터 과학은 컴퓨터와 아무 관련이 없습니다.

College는 도구로 가득 찬 도구 상자를 제공합니다. 이 드라이버는 초승달 모양의 렌치입니다. 당신은 대학에서 한 번 각 도구를 사용할 수 있습니다. 당신이 현실 세계에 들어갈 때가 당신이 가진 것을 정말로 찾을 때입니다. 당신은 나머지를 위해 유용한 것들을 분류합니다. 당신이 원하는 경우를 대비하여 작업대에서 집에두고 싶은 것들과 매일 주머니에 넣는 것들을 정리하십시오.

Tqm, Iso, Cmm, Agile 등. 이들은 모두 사라질 것이며 사라질 것입니다. 성공적인 것들은 상식 이상의 것이 아닙니다. 모든 성공적인 엔지니어와 회사는 상식의 풍미를 사용합니다. 그것이 성공을 거두었으므로 그 이름은 거의 필요하지 않았습니다. 문제는 상식을 팔 수 없다는 것입니다. 관리자는 눈에 띄지 않는 이름없이 상식을 훈련하고 구매함으로써 회사에 가치를 입증 할 수 없습니다. 뉴스 기사 나 잡지에서 상사들이 읽은 이름을 적어두고 관리자는 직무를 유지하고 당신은 자신의 일을 유지합니다. 이러한 관행을 따른다고 주장하는 회사는 거의 없습니다. 대부분 컨설턴트에게 수표를 작성하고, 연차 및 / 또는 평생 증명서를 일부 클럽에 가져 와서 웹 사이트에 그래픽이나 제품 상자에 라벨을 붙일 수 있도록합니다. 많은 사람들은 이것이 드물다고 주장 할 것입니다. 이것은 사업의 모든 부분이며, 때로는 수익성을 유지하고 문을 열어 놓고 조명을 켜려면 모서리를 잘라야합니다. 이 모든 관행의 하드 코어 추종자들은 모두 마지막 것이 유행이라고 말했고, 이것이 마지막이 아니며, 마지막 것은 너무 비싸서이 것이 아닙니다. 마지막은 당신이 컨설턴트를 고용 한 가짜 였어요. 이건 진짜입니다. 프로그래밍 언어와 마찬가지로 이것도 진화 할 것입니다. 마지막은 당신이 컨설턴트를 고용 한 가짜 였어요. 이건 진짜입니다. 프로그래밍 언어와 마찬가지로 이것도 진화 할 것입니다. 마지막은 당신이 컨설턴트를 고용 한 가짜 였어요. 이건 진짜입니다. 프로그래밍 언어와 마찬가지로 이것도 진화 할 것입니다.

비즈니스의 현실, 대학 시스템 및 그에서의 역할을 이해하는 능력이 핵심입니다. 인생의 어떤 것과 마찬가지로 전투를 선택하십시오. 대학이나 사업체, 정부 또는 다른 사람이 당신에게 필요하거나 알고 싶어하는 것을 가르치는 것은 아닙니다. 번호 하나를 찾는 것이 당신의 일입니다. 마찬가지로 당신은 당신에게 이것을 할 시간을 제공한다고 다른 사람을 비난 할 수 없습니다. 당신은 그것을해야합니다. 당신은 말에서 떨어지고, 당신은 희생자가 아니며, 일어나서 다시 변명하지 않으며, 삶은 그것에 공평하지 않습니다. 유인물을 이용하고 독립적 인 척하지 마십시오. 그리고 회비를 지불하고 회사에 유인물을 말리지 말고 대가로 무엇이든 (당시에 최고입니까?)주지 마십시오.

사람들이 왜 CMM 또는 민첩한 또는 다른 어떤 것이 유행이라고 생각합니까? 그들이 왜 그렇지 않다고 생각합니까? 교수는 왜 그렇게 프로그램을 가르쳤습니까? 고 토스를 피하거나 상수를 피하거나 이것을 피하기 위해? 더 안정적인 코드를 생성하기 때문입니까? 더 나은 성능의 코드? 인적 오류를 줄입니까? 아니면 논문 / 프로그램의 등급을 매기는 것이 더 쉬워서 연구에 더 많은 시간을 할애하고 있습니까? 프로그래밍 방법을 모르고 주제에 대해 다른 사람의 책을 따르기 때문입니까? 유지 관리 가능하고 신뢰할 수있는 고성능 코드를 가질 수 없다고 가르쳤습니까? "두 가지 중 하나를 선택"해도 유지 보수가 안정적이고 고성능을 방해 할 수 없습니까? 때로는 성능의 안정성을 희생합니다. 때로는 안정성이나 성능에 신경 쓰지 않고 버전 117.34에서 얻으려고합니다. 버전 118.0.0에 대한 또 다른 회계 소프트웨어 프로그램 중 2 개. 귀하의 비즈니스 모델은 버전 업그레이드 및 기술 지원을 판매하는 것입니다. 소프트웨어 개발자는 모든 이전 로봇이 동일한 방식으로 동일한 코드를 작성할 수 있습니다. 타 버린 것을 새 것으로 교체하고 업그레이드 판매를 계속하십시오.

이 질문들에 대한 보편적 인 대답은 없습니다. 당신은 당신의 의견이 무엇인지 알아 내고 함께 살아가고 방어해야합니다. 당신의 마음을 바꾸고, 함께 살고, 변호하십시오.

모든 것에 의문을 제기하십시오 ... 난로의 냄비를 만지면 정말 화상을 입을 수 있습니까? 두려워하는 심리적 영향이 화상을 입는 것보다 더 많은 피해를 입히는가? 다 치지 않고 답변을 테스트하는 안전한 방법이 있습니까?

내가 그것을 감당할 수있을 때 나는 기숙사 방에서 트랜지스터, 캡, 저항 등을 사서 결국 녹일 것이다. 첫 번째 트랜지스터 클래스 이후 하루에 앰프를 제작하는 것보다 스테레오 용 앰프를 구입하는 것이 훨씬 저렴하고 쉽습니다. 물론 Linus는 운영 체제를 작성하는 것보다 운영 체제를 구입하는 것이 더 쉽다는 것을 제외하고는 ... 그 당시에 배운 내용이 Linus가 배운 것과 다를지라도 더 많은 것을 할 수 있습니다.

대학 내부와 외부의 세계는 문제를 해결하기 위해 이러한 공식 (cmm, agile 등)을 채택 할 것이며 다음 문제가 나오면 빨리 떨어 뜨릴 것입니다. 당신은 성공하기 위해 버전 관리를 사용할 필요가 없습니다.없이 성공했을 때와 마찬가지로 많은 성공이 있습니다 (실제로 업계의 시대 때문에 지금까지 버전 제어없이 많은 성공이 있습니다). 마찬가지로 최소한의 테스트만으로도 성공할 수 있습니다 (컴퓨터 업계에서 실제로 큰 이름을 예로 들어보십시오). 자신의 코드를 테스트하면 성공할 수 있으며 자신의 코드를 테스트해서는 안된다는 규칙에 따라 성공할 수 있습니다. emacs를 사용하면 성공할 수 있고 vi를 사용하면 성공할 수 있습니다. 어떤 믹스가 효과가 있는지 결정해야하며 운이 좋으면 자신에게 맞는 직장을 찾으십시오.

대학 밖에서 현실 세계로 나가면 "오래된 타이머"를 듣고 함께 일하고 논쟁하십시오. 그들은 수십 년에서 수세기에 걸친 경험을 가지고 있으며, 함정을 피하고 스스로 테스트 할 수있는 함정을 가지고 있습니다 (뜨거운 냄비를 만져서 화상을 입을 필요가 없다는 것을 깨달을 수도 있습니다). 대부분의 사람들은 이러한 유행 중 적어도 하나 또는 두 가지가오고가는 것을 보았을 것입니다. 사물을 테스트하는 여러 가지 방법과오고가는 테스트 스타일의 이름을 알고 있습니다. 작동하는 것, 그렇지 않은 것 위험이 있고 접선에 시간을 낭비하지 않는 방법. 당신이 성숙하고 오래된 타이머가되면 앞으로 전달하십시오. 당신을 따르는 사람들을 가르치면서 배운 것을 지불하십시오. 낚시하는 법을 가르쳐 줘 그들에게 물고기를주지 마십시오. 때로는 성공하기 전에 실패하게해서 너무 심하게 화상을 입지 않도록해야합니다.

제가 여기서 실제로 말하고 싶었던 것은 지금 우리가 평행 우주의 진화를 목격 할 수있는 희소 한 상황에 처해 있다는 것입니다. 컴퓨터 과학은 물리학에 비해 젊은 과학입니다. 그러나 동시에 여러 번 진화했습니다. 어디서 일하고 누구와 함께 일 하느냐에 따라 하드웨어 엔지니어를 관찰 할 수 있습니다. 하드웨어 세계의 프로그래밍 언어는 확실히 새로운 것은 아니지만 소프트웨어 세계만큼 빠르게 발전하지는 않았습니다. 소프트웨어는 수십 년 전에 시작되었습니다. 하드웨어는 항상 소프트웨어 엔지니어를 2 등 시민으로 생각했습니다. 우리의 일은 쉬우 며 그들의 일은 어렵습니다. (참고로 저는 실제로 하드웨어 및 소프트웨어 엔지니어입니다). 흥미로운 점은 지금 우리가 초등 또는 영아 문제를 고려할 것을 여전히 다루고 있다는 것입니다. 버전 제어를 사용해야하는 이유는이 칩에서 유일한 사람입니다. gcc 또는 다른 저렴한 컴파일러 또는 무료 IDE에 대한 경험은 내가 사용하는 데 가치가 있다고 생각하거나 사용 방법을 알면 사본을 구입할 것입니다. 그리고 다른 변명들의 긴 목록. 나는 vhdl과 verilog를 배우고 일주일 이내에 그러한 하드웨어 엔지니어로부터 거의 감히 되었기 때문에 생산성이 높아지는 것을 즐겼습니다 (전기 엔지니어는 내 직책은 소프트웨어 엔지니어라고 말하지만 졸업장). 이 언어를 배우고 싶었습니다. 도구를 사용할 수 있었을 때 나는 사무실에 밤새 머물면서 스스로 가르쳤습니다. 그 시점에서 엔지니어는 특히 내가 말한 것이 사실이라는 것을 깨달았습니다. 프로그래밍 기본 사항은 동일하며 도구는 모두 동일한 기능을 수행합니다. 사과와 사과가 아닌 사과와 사과.

일반적으로이 두 가지 병렬 산업 중 하나가 다른 언어보다 프로그래밍 언어, 프로그래밍 습관, 소스 제어, 테스트, 도구, 프로그래밍 환경 등에서 더 많은 경험을 가지고 있다는 메시지를 보내는 것은 여전히 ​​어렵습니다. 내가 해결하려고하는 문제는 하드웨어 디자인을 개발할 때 가져 와서 프로세서의 시뮬레이션 (가상 머신)과 연결할 수있는 저렴한 기능 시뮬레이터를 생성하여 하드웨어 테스트를 시작하고 테스트를 개발하는 것입니다. 실리콘에 오기 오래 전에 제공 가능한 소프트웨어. 이것에 대해 "새로운"것은 없지만, 우리는 최신 코드를 얻고, 코드의 변화를 추적하여 시간을 어디에 집중해야 하는지를 알 수있는 메커니즘이 없습니다. 하드웨어에 대한 사용자 (프로그래밍) 인터페이스를 정의하는 문서를 추적하는 메커니즘이 없습니다. 하나의 황금 사본은 누군가의 전자 메일받은 편지함에 바이너리 형식으로 있으며 변경 사항을 읽을 때 Verilog를 읽을 필요가없는 경우에만 변경됩니다. 잠깐만, 그 verilog는 몇 살입니까? 내가 일주일 내내 보낸 버그는 3 주 전에 알아 내고 고쳤습니까? 하드웨어 담당자가 작업을 마치고 벽에 넘길 때까지 기다리는 6 개월 동안 휴가 장소와 파티에 가거나 참을성 있고 낙관적이며 그들에게 작업을 수행하고 작업을 백업하며 동료 검토를 위해 물건을 공유 할 수있는 방해가되지 않는 상식적인 방법이 있습니다 ... 그 verilog는 몇 살입니까? 내가 일주일 내내 보낸 버그는 3 주 전에 알아 내고 고쳤습니까? 하드웨어 담당자가 작업을 마치고 벽에 넘길 때까지 기다리는 6 개월 동안 휴가 장소와 파티에 가거나 참을성 있고 낙관적이며 그들에게 작업을 수행하고 작업을 백업하며 동료 검토를 위해 물건을 공유 할 수있는 방해가되지 않는 상식적인 방법이 있습니다 ... 그 verilog는 몇 살입니까? 내가 일주일 내내 보낸 버그는 3 주 전에 알아 내고 고쳤습니까? 하드웨어 담당자가 작업을 마치고 벽에 넘길 때까지 기다리는 6 개월 동안 휴가 장소와 파티에 가거나 참을성 있고 낙관적이며 그들에게 작업을 수행하고 작업을 백업하며 동료 검토를 위해 물건을 공유 할 수있는 방해가되지 않는 상식적인 방법이 있습니다 ...

하드웨어 엔지니어들은 당신과 마찬가지로 반짝이는 새로운 도구 상자를 가지고 대학을 떠났습니다. 당신은 당신이 하나를 사용할 수있는 17 가지 프로그래밍 언어를 배웠고, 당신이 직업에서 나머지 언어는 대학을 떠난 후에 발명 될 것입니다. 그들이 대학을 떠났을 때 그들은 각 원소에 얼마나 많은 전자가 있는지 계산하고 상대성 이론에 대해 알고 가우시안 표면 주위의 전하를 계산할 수 있습니다. 그러나 그들의 경력의 대부분은 1, 0, 또는 아닙니다 (우리는 공통점이 있습니다. 하드웨어, 소프트웨어 엔지니어가 아닌 컴퓨터, 1, 0 및 / 또는 컴퓨터에 대해 실제로 알아야 할 모든 것). 물리학, 미적분학의 기본 법칙을 인정하면 전자는 프로그래밍 언어만큼 빠르게 변하지 않을 것입니다. 그러나 프로그래밍의 기본은 모든 언어에서 동일하며 앞으로도 계속 될 것입니다. 대학에서 그 사실을 알고 있었습니까, 아니면 자바가 C ​​++과 다르고 더 좋았다고 생각하셨습니까?

다른 사업과 마찬가지로 대학의 직업은 수익성을 유지하는 것입니다. 그들은 올바른 학생과 올바른 연구비, 그리고 대학의 수익성을 높이기위한 올바른 종류의 연구를 모두 제공하기 위해 올바른 학계를 고용해야합니다. 그들은 올바른 학생들을 데려오고 올바른 졸업생을 배출 할 수있는 올바른 수업을 제공해야합니다. 그래야 수십 년간 대학 근처의 고용주가 지나갈 때이 대학이 생산적이고 수익성있는 직원을 생산할 수 있다는 것을 알게 될 것입니다. (예, 때로는 적절한 스포츠 시간에 적절한 선수를 유치하여 적절한 시간의 TV 시간과 적절한 이름의 인지도 및 스포츠 수익을 얻으십시오). 일부 대학에서는 C ++ 및 Java를 가르치지 만 일부 대학에서는 그렇지 않습니다. 어떤 사람들은 CMM을 발명 할 것이고 어떤 사람들은 애자일을 가르 칠 것이고 어떤 사람들은 그렇지 않을 것입니다. 대학에 가치가 있다면 배울 점이 있습니다. 그들은 당신에게 배울 모든 것을 가르쳐주지는 않지만 유용한 것을 갖게 될 것입니다. 당신이 거기있는 동안 무언가를, 도구 상자에 합리적인 수의 다양한 형태의 도구를 모으십시오. 대학을 떠나 직장을 구하십시오. 당신의 도구 상자가 짜증 나면 다른 대학을 찾아서 처음 언급하지 마십시오. 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학계에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ... 그들은 당신에게 배울 모든 것을 가르쳐주지는 않지만 유용한 것을 갖게 될 것입니다. 당신이 거기있는 동안 무언가를, 도구 상자에 합리적인 수의 다양한 형태의 도구를 모으십시오. 대학을 떠나 직장을 구하십시오. 당신의 도구 상자가 짜증 나면 다른 대학을 찾아서 처음 언급하지 마십시오. 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학계에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ... 그들은 당신에게 배울 모든 것을 가르쳐주지는 않지만 유용한 것을 갖게 될 것입니다. 당신이 거기있는 동안 무언가를, 도구 상자에 합리적인 수의 다양한 형태의 도구를 모으십시오. 대학을 떠나 직장을 구하십시오. 당신의 도구 상자가 짜증 나면 다른 대학을 찾아서 처음 언급하지 마십시오. 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학계에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ... 당신이 거기있는 동안 무언가를, 도구 상자에 합리적인 수의 다양한 형태의 도구를 모으십시오. 대학을 떠나 직장을 구하십시오. 당신의 도구 상자가 짜증 나면 다른 대학을 찾아서 처음 언급하지 마십시오. 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학계에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ... 당신이 거기있는 동안 무언가를, 도구 상자에 합리적인 수의 다양한 형태의 도구를 모으십시오. 대학을 떠나 직장을 구하십시오. 당신의 도구 상자가 짜증 나면 다른 대학을 찾아서 처음 언급하지 마십시오. 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학계에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ... 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학문에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ... 그것이 괜찮은 도구 상자라면 그 도구를 사용하여 자신의 시간에 새로운 도구를 만드십시오. 아주 좋은 도구 상자라면, 그 대학과 당신이 배운 것들과 그로부터 얻은 좋은 학계에 대해 좋은 것을 말하고 그들이 준 것에 대해 학교에 갚아주십시오. 유니버설 대학 도구 카탈로그에서 가능한 모든 도구를 얻지는 못했지만 특정 하위 세트로 이동합니다. 졸업하지 않아도 ...

---

오 신 이시여

나는 한 번 유명한 대학의 cs 학장에게 객체 지향 프로그래밍이 단지 'fad'라고 말 했으므로 C ++과 같은 환상적인 것을 전달하는 클래스를 제공하지 않았습니다.

그들이 왜 이런 것들을 가르치지 않는지에 관해서는, 대학은 당신에게 업계의 모범 사례가 아닌, 당신에게 규율의 기초를 가르치기 위해 있습니다.

---

가장 간단한 대답은 컴퓨터 과학을 공부하고 있으며 나열된 것들이 실제로 컴퓨터 과학의 학문 분야와 관련이 없다는 것입니다. 소프트웨어 개발은 당신이 뭔가 수 있습니다 할 컴퓨터 과학, 당신이 배운 내용의 블록을 기반으로 구축 뭔가를 ...하지만 컴퓨터 과학 및 소프트웨어 개발은 같은 것이 아니다.

버전 관리를 가르치거나 효과적인 단위 테스트를 작성하는 방법을 가르치는 수업은 무역 , 즉 (좋은) 소프트웨어 개발을 가르치는 것 입니다.

---

대학이 가진 것은 실제로 보편적 인 것을 가르쳐야한다는 것입니다. 민첩한 개발과 같은 것은 여전히 ​​새로운 것입니다. 인터넷에서 그것이 얼마나 많이 이야기 되더라도 어디서나 사용되지는 않으므로 전체 클래스의 학생들에게 가르치는 것은 민첩한 상점에 ​​착륙 한 소수의 사람들에게만 이익이 될 것입니다.

그러나 버전 관리는 요즘 변명 할 수없는 일입니다. 모든 사람들이 컴파일러만큼 유용하고 CVS는 약 20 년 이상 사용되어 온 도구라는 것을 모든 사람들이 이해해야하는 것입니다. 적어도 개념은 대학을 떠나는 프로그래머가 이해해야합니다. 다행히도 대학에서 그룹 작업을 수행하는 경우 이미 버전 관리에 대해 알고 있고 그룹에서 사용하도록 설득하는 사람과 착륙 할 수있을만큼 운이 좋을 수 있습니다. 나는 그 사람이 내 그룹에 있다는 것이 기쁘다는 것을 안다.

단위 테스트도 변명 할 수없는 수준입니다. 내가 말하고 싶은 유일한 것은 책이 여전히 테스트 중심 개발에 관한 것이며 100 % 코드 적용 범위로가는 것은 때때로 가치보다 더 어려울 수 있다는 것입니다. 그러나 단위 테스트는 매우 가치가 있으며 소프트웨어 엔지니어링 과정에서 다루어야합니다. 이 것들 중 일부가 일부 대학에 들어가고 있지만 아직까지는 아직 도달하지 않았다고 생각합니다.

---

실제로는 어떻습니까? CS 학위를받는 경험은 거의 같습니다. 그 이유는 프로그래밍을 가르치는 사람들이 내가 알 수있는 한 프로그래밍하지 않기 때문입니다. 인정을 위해 물건을 가르치는 것은 필요하지 않으며, 교사는 그것에 익숙하지 않으며, 학생들은 수업 과정의 일부로 중요한 프로젝트를 개발하지 않습니다. CS 이론이나 Java 구문을 가르치는 것과는 달리 프로그래밍을 실제로 가르치는 동기는 없습니다.

---

대학에 따라 다릅니다. 2003 년 호주의 한 학부에서 졸업했습니다. 그 당시 우리는 Z, 알고리즘 및 데이터 구조, 운영 체제 등과 같은 모든 공식적인 것들과 함께 UML, 단위 테스팅, XP 및 기타 민첩한 방법론을 배웠습니다.

They didn't cover unit testing in great detail though, more just paid it passing service for one lecture. It would have been great to have learnt how to write effective unit tests, rather than just "What is a unit test".

As far as version control is concerned, we were using it (CVS) in our programming projects from 2nd year onwards.

I do agree strongly with what Glyph said, too. CS is such an immature field, really only around in the last 50 years, that we don't know what we should be learning and what is only a passing fad. Give it a 150 years, then things might be settling down more. The number of failed realworld projects makes it obvious that this is an immature industry. Imagine if 80% of building projects failed!

---

Computer scientists think they are mathematicians not engineers and so they prefer teaching the maths parts than the engineering parts. Testing,version control and documentation aren't passing fads any more than they are in any other engineering discipline.

---

All of that can easily be covered (shallowly) in a single class on software development practices. It's not part of most CS curriculums, because that isn't what CS is about, though I do think some coverage of that stuff is useful. My school had such a class; it didn't cover version control, but it did cover UML, requirements gathering, development methodologies (various agile and waterfall), unit testing, integration testing, etc., and required us to work in teams of 4-5 to develop a project (a rather simple Clue rip-off in Java). If you felt the need for further Software Engineering classes, they were available as electives.

Despite never having version control mentioned once in any class that I took, most of my friends were using it for personal projects, class assignments, and so forth, so it isn't as if we weren't exposed to it. The people who didn't pick it up on their own got forced to use it by a classmate in the course of a team assignment.

University is meant to teach concepts and theories, because those are the things that are hard to pick up on your own. Version control is a tool, and pretty easy to pick up. Use it a bit, read some tutorials on the web, and you're all set. If you need lectures and homework assignments to figure out how to check something out of SVN, you are going to have a lot of trouble with the things that actually ARE difficult.

Remember that there are plenty of ways to learn stuff in college outside of classes; take advantage of that. You're paying a lot to attend the classes and use the facilities, so milk it for all it's worth and go to LUG and ACM meetings, participate in project teams (there's always some MEs building a robot who need a programmer), or get a job administering the Humanities department's server. Trashpick a computer from the loading dock of the Materials Engineering building, download a Linux iso with your fast dorm internet connection, and play around.

---

I think the issue is that universities don't feel that they need to teach you to be a professional, but instead focus on the academic side of programming. I would have thought there should at least be reference to the latest methods and techniques that are used in the industry, as these things are of academic interest as well.

In our course, we were taught Personal Software Process, which covered things like recording time spent on projects, good commenting etc., but no mention of professional fundamentals like version control.

---

You've named 3, some of which I don't think are nearly as important to an understanding of computer systems (eg version control). These things are part of a job, and you can become a good programmer/computer scientist without needing to know it.

similarly for unit testing - why pick out unit testing? Surely usability testing, system test, user acceptance test and factory acceptance test is more important? Well, they are unless you consider your job complete once the code is shipped to the maintenance department :)

Think of the other concepts that I use daily, that would be of little use to a student coming to terms with the fundamentals of software and computer systems:

• good commenting practices
• standards compliance (not just international ones, but team coding standards)
• documentation
• change control (not necessarily the same as version control which is about storing differences, this is more about what and why you changed something)
• usability development

The above are all "soft skills" which you don't need to write good code.

However if you're missing the "hard' skills, like data structures and algorithms, then your chance of writing good code is next to impossible.

---

I learned all of those in University. Perhaps it depends on the courses you choose? My courses were very diverse (Software Design, UI Design, eCommerce, AI, Functional programming, etc.). Software Design had exposure to design patterns and unit testing (one large project which involved various things). UI Design...we were a three person group working on a project. We couldn't do anything without version control, so we got that. And agile development was something our professors continuously told us about, but they left it upto each group to use it.

I find that many University students took "easy" courses or courses which would them give a high GPA. Others focus on what they want to learn and are largely exploring to find what field would interest them. And then there are those who know exactly what they are interested in...which is good, except they tend to not diversify their courses.

---

To answer why these things aren't the first things being taught: Undergraduate programs typically train you to become a Masters student. Only once you start picking your own courses (which typically happens in later years) can you choose to learn about things used outside of academia. This is why they focus on algorithms, data structures, presenting you with unsolved problems, etc.

I personally think it is fine that they are doing this. Programming isn't as easy as many of us make it seem; many people struggle with it. I would rather these people first understand how a for loop works before figuring out the monster that Perforce is.

---

They don't teach such topics because most schools are academic, not trade. That is, they are designed to teach ideas and theories, not train you into a career. The entire concept of QA has nothing to do with computer science beyond passing a mathematical proof. Besides, QA practices and development workflows differ wildly from one development house to the next, so teaching them in school is a waste of your time and money.

---

I learned all that stuff freshman year, with the exception of agile development.

It's all about choosing the right school, IMHO. If you go top 10, you will learn all that stuff quickly.

As far as CS Education in general, we're basically asking professors to teach so much (languages of every flavor, data structures, run-time efficiencies, how things actually work at the bit level). I'd like to raise the question, Why don't the kids take it upon themselves to learn more about Software Engineering?

---

Just like students, each college is different. Some colleges, or more accurately, some professors are resistant to change or are lazy. Fortunately most are not. Theories, concepts, history etc. are important and vital to any CS curriculum. But so is preparing the student for their working environment. Not surprising, the community colleges in my area offer very current and applicable CS courses. Not so much with large, established and prestigious university.

---

It's simply because data-structures and algorithms constitute the core of computing and thereby are much more important. Unit testing, version control and agile methodology are but tools of the trade (and if necessary, one is expected to pick them up on the job).

---

I think good CS programs should teach the fundamentals that will serve as your basis for all future programming education. Development methodologies like Agile, and version control tools are like fads; they come and go. Also, they tend to be used in industry settings and not academic ones, so I think it's rare for universities to cover things such as those that you'll probably learn on the job. I'm not saying it's right, but that's probably the academic mentality.

---

I agree with what you're saying. I just recently started working in the software development world and I've already started to learn about agile development, something that I was never taught in university.

The fact of the matter may be that university profs don't keep up with newer development techniques as much as they should. They also may feel that there are other, more important things on their curriculum.

---

University lecturers don't know about how to write software, they just research it, teach it, and occasionally bash out some code that only has to work until the paper is published.

It's only because of folks like Titus that we're getting any academics who truely grok programming - Read his comments on that topic here

When I was a student I read books in the library about Extreme Programming, an we discussed it breifly in classes - the same classes that demanded that we conform to the "Waterfall Model" of software development, where "compilation" is a step of its own.

All the best with your career, I hope you graduate your degree, it's nice to have letters after your name. :)

---

All three things you mention (unit testing, version control, agile development) are taught to some degree in the Computing Science programme of the University of Groningen. Whether or not that is a good thing I will leave as an open question; but it is not true that no universities teach you the "practical stuff".

---

These are based off my limited experiences in a CS program before I switched majors, and my experience as an intern at a large software company. Unit testing isn't taught because most of the programs that you have to create arn't large enough to need automated testing, your garanteed a specific set of inputs so can test everything manually. Teaching you how to automate testing may also interfear with the grading of your project since most projects are graded with scripts that run automated tests, with a quick glance at the code to make sure you don't have int foo1; int foo2; and you use proper indentation.

I don't know why version control wouldn't be taught but part of it is probably the size of projects. I never had any project that was large enough for version control, and by large I mean over 1000 lines of code and took an entire semester to write. I guess they figure you'll teach it to your self if you need it. Any group projects I had were supposed to be pair programming projects, and why use version control if your both at the same computer?

I don't know why agile development wouldn't be taught but it probably goes back to the same thing with program size. While adgile development is common with new software that runs on personal computers and small servers it is not generally used on systems such as IBM mainframes or in problem domains such as banking or medical where documentation is king. It also probably has to do with the fact that adgile development wasn't around 20 years ago when a lot of professors were trained.

---

The main reason is that many (most?) universities considers themselves to have a different goal than a trade school. As such, they want to teach students how to learn, and the fundamental principles of the discipline. Additionally, algorithms and data structures will apply to any programming language, and is not dependent on specific tools (which may or may not still be in use by graduation).

In Computer Science, that means algorithms, data structures, computer theory, compiler theory, etc. The stuff that you're listing is less about understanding how to program, how to solve problems, etc. It's about the practice of programming (which, incidentally, is an amazing book for anyone in college with the intention of working as a programmer). Now, much of this will not be used at an entry level code monkey position, leading some people to think it isn't useful. I disagree. I think it can be extremely useful. However, it doesn't mean that after you get your CS degree, you know everything you'll ever need to work as a programmer.

Which also isn't to say that the things you mention aren't useful. They are. You'll have trouble working on as a programmer if you don't learn them, and I do think they should be taught in college, at least to a certain extent. I would look at teaching version control, unit testing, etc, at the same way I would look at an undergraduate programming in art, and the teaching of what paint brushes are and which ones should be used for various cases.

---

I think it depends on what type of Computer Science program you are in there are the ones that aim toward the Research and Science side and there are ones that gear toward the Implementation side. I specially declined against certain schools that only had professors that stayed in the academic world. If you don't have professors that havent been "using" what they teach, its all in their head, literally.

Plug: Having taking BS in Comp Sci and MS in Soft Eng at DePaul University, I was mostly taught by instructors/professors who taught part time, which was fine by me because I would rather have them come in with a anecdote from the previous day and relate it to class. Also this being a mostly commuter/part-time school, most of the students have jobs in using what they are learning.

The process of learning still starts with the all the theory, but then we usually get asked "how many of you actually use this in your job?" and the typical answer is "we use it but in a stripped down or simplier way" and then we go into the practical real world scenarios.

During my schooling unit testing was always present. Even though they start you out on Java, they made us use ANT and JUnit for all project. Which was a good starting on build configuration and unit testing.

And Extreme Programing was included in about 3 or 4 of the classes i took. I remember they all started out with the 12 different aspects, from pair programing to unit testing(see above). And now it seems like the focus is on Agile.

So the quick answer is yes there are schools out there that have a more pragmatic approach then others.

---

Unit testing and version control were both taught in 2nd year Computer Science courses where I went to university. Unit testing fell under the part of testing that also included differences between white and black box and a good chunk of the marks in 3rd year programming assignments went for good error handling that can easily come from unit testing.

Agile development may be rather hard to teach in an academic setting I'd think. While I did learn about the Waterfall method in theory, I didn't get to see it in the field until after I graduated and moved into the real world that can be quite different from academia, e.g. in 3rd year I do all the odd error cases and nearly pass an assignment where I never touched the heart of what the assignment tried to teach me about Semaphores.

Also, how long has agile been around and which form of agile did you mean? There are many different implementations of it from what I've seen.

---

I don't think agile programming is a fad, but at the same time I'd be hard pressed to think of a way a teacher could give you projects to allow you to learn it.. Unless they gave you project A build a, project B expand on a. The problem is time and scope. In a 4 month course it would be hard.

Version control and unit testing methods are ever changing and dependant on the language, or the person who defines them.

The data structures and algo's are something that can be worked on in a class setting. Honestly too, they take quite a bit more effort to understand then unit testing and versioning. Try to remember part of university is to teach you to teach yourself. Collage does not quite have the same mandate. Or at least not to the same extent. IMHO.

참고URL : https://stackoverflow.com/questions/79231/why-dont-they-teach-these-things-in-school