대학원 기대와 현실 [폐쇄]

우리가 공부하고 싶은 것을 선택하고, 직업과 삶과 함께 할 때, 우리 모두는 그것이 어떻게 될 것인지에 대한 기대를 가지고 있습니다. 저는 거의 10 년 동안이 업계에 종사해 왔기 때문에 (컴퓨터 공학을 공부할 때) 프로그래밍 작업 생활이 어떻게 생겼을 지에 대한 생각과 실제 결과가 있다,이다.

필자의 두 가지 가장 큰 충격 (또는 기대에 부응해야한다)은 소프트웨어와 관련된 유지 보수 작업의 양과 전문성이 부족하다는 점이다.

1. 유지 관리 : Uni에서는 모든 소프트웨어 작업이 기존 시스템의 유지 관리라고 들었습니다. 그래서 나는 초록에서 이것을 기대한다는 것을 알았습니다. 그러나 나는 이것이 얼마나 압도적 일지 정확히 상상하지 못했습니다. 어쩌면 그것은 내가 정신적으로 윤이 난 무언가이며, 처음부터 멋진 새 물건을 훨씬 더 많이 만들기를 바랐습니다. 그러나 실제로 대부분의 작업이 압도적으로 유지 관리, 버그 수정 및 지원 지향적 인 경우입니다.

2. 전문성 부족 : 저는 항상 상용 소프트웨어 작업이 매우 프로세스 지향적이고 엄격하게 설계되었다는 인상을 받았습니다. ISO 프로세스 이미지, 기술 문서 다량, 모든 기능 및 버그가 엄격하게 문서화되어 있으며 일반적으로 전문적인 환경이 있습니다. 대부분의 소프트웨어 회사가 한 학기 동안 진행되는 대규모 프로젝트를 수행하는 학생 팀과 다르게 운영된다는 것을 깨닫게 된 것은 큰 충격이었습니다. 저는 소규모 애자일 핵 전문점과 중소 기업 기업에서 근무했습니다. 나는 그것이 항상 "전문적이지 않은"것이라고 말하지는 않지만, 소프트웨어 산업은 (전반적으로) 내가 기대했던 강력한 공학 분야와 거리가 멀다는 느낌이 든다.

다른 사람과 비슷한 경험이 있습니까? 우리의 직업에 대한 당신의 기대가 현실과 다른 방식은 무엇입니까?

난 당신이 남자 느낌. 나는 방금 1 년 전에 거의 졸업을했고, 첫 번째 직업 제안에 뛰어 들었고 내 인생에서 가장 큰 충격을 받았습니다.

내가 기대하지 않은 것 :

학교 스트레스와 직장 스트레스는 동일하지 않습니다 -학교 과제물을 친구들과 함께 일하거나 혼자 일하는 스트레스는 다가오는 논문 마감일이나 특별 프로젝트 방어로 인해 합리적으로 보이지 않는 업무 마감 시간, 의사 소통 문제와 비교되지 않습니다 (소규모의 정치)와 위기 시간.

모범 사례 부족 -전문성에 대한 경험과 동일합니다. 첫 번째 직업을 시작하기 전과 훈련 기간 동안 나는 프로그래밍과 소프트웨어 엔지니어링의 모범 사례를 검토하고 읽었습니다. 비실용적이고 공정하고 실질적인 이유 때문에 따라야 할 것은 아닙니다. 때때로, 당신의 지식은 단순히 알려지지 않은 것을 두려워하고 이러한 관행을 경멸로 취급하는 다른 사람들에게는 거의 중요하지 않습니다.

그들이 학교에서 가르친 것은 빙산의 일각 일뿐 입니다. 제가 스스로 공부하고 수업에서 배운 내용이 저를 통과하기에 충분하다고 생각했을 때, 저는 제가 처음으로 작성한 코드에서 벙어리를 쳐다봤을 때 가장 적은 말에 충격을 받았습니다. 유지해야합니다. 제가 지금 사용하는 많은 기술은 직장에서 또는 직장에서 배웠으며, 대학 학위없이 전혀 할 수 없었는지 궁금합니다. XD

의사 소통의 중요성 -모든 영어 수업의 목적을 깨달았습니다. 실생활이 있기 전에, 우리가 1 학년 때부터 가르쳤을 때 대학에서 3-4 개의 다른 영어 수업을받는 것과 관련성이 없었습니다. 컴퓨터와 대화를 할 수는 있지만 사람들과 대화를 할 수 없을 때는 직장에서 아무 소용이 없습니다.

당신이하는 대부분의 작업은 획기적인 것이 아닙니다

Uni에서 축구 게임 로봇을 제어하기 위해 AI 루틴을 작업 할 때 컴파일러를 구축하고 운영 체제 커널을 해킹했습니다.

그러나 실제로는 소프트웨어 개발의 99 % ^* 가 실제로 지루합니다. 나는 항상 "생계를 위해 무엇을합니까?"라는 질문을받는 건축 가나 건축업자들에게 감탄했습니다. 건물 또는 무엇이든을 가리키고 "내가 한 말을 할 수 있다고 ." 그러나 대부분의 소프트웨어 개발자는 그렇게 할 수 없습니다. "생활을 위해 무엇을하십니까?" 내가 올 수 있었던 가장 가까운 것은 라디오 방송국 등을 위해 SMS 메시지를 처리하는 소프트웨어를 개발 한 회사에서 일할 때였을 때입니다. "노래에 투표 할 라디오 방송국을 찾았습니다. 그 투표와 자료를 처리하는 소프트웨어를 작성했습니다." 여전히 건물을 가리킬 수 있고 "내가 지어 냈다"고 말하는 것만 큼 멋진 곳은 없습니다.

물론 "Windows에서 작업했습니다"라고 말할 수 있는 사람들이 있지만 실제로 다음 질문에 대한 두려움 때문에 "프린터를 작동시킬 수 없습니다. 나를 위해 고칠 수 있습니까? "

^* 모든 통계량의 62 %가 현장에서 구성됩니다.

오늘날 엔지니어링 역사의 렌즈를 통해 소프트웨어를 살펴보면 확실히 일종의 엔지니어링이지만 아치의 개념이없는 사람들이 수행 한 엔지니어링의 종류입니다. 오늘날 대부분의 소프트웨어는 구조적 무결성없이 수백만 개의 벽돌이 쌓여있는 이집트 피라미드와 매우 유사하지만 무차별 대대와 수천 명의 노예가 수행합니다. 2004 년 앨런 케이

전체 인터뷰 : http://queue.acm.org/detail.cfm?id=1039523

나는 업계 전문가가 아닙니다. 그와는 정반대로 저는 최근 졸업생이지만 미국 최고의 CS 학교 출신이지만 본능적으로 느끼는 것은 소프트웨어 제작 방식이 잘못되었다는 것입니다. 일시 정지 버튼을 누르고 프로그래밍 방식의 기본 사항을 다시 검토하는 대신 50 년대의 오래된 모델을 사용하여 60 초 동안 계속해서 설탕을 조금씩 첨가했습니다. 우리가 이런 식으로 계속한다면 우리가있는 곳을 지나치지 않을 것입니다. 인간은 MS Windows 코드베이스 크기의 복잡성을 관리 할 수 ​​없습니다. 새로운 방법이 필요합니다. 나는 그것이 무엇인지 모른다.

나는 이것이 크고 작은 소프트웨어 상점들이 기본 원칙에 대한 깊은 이해없이 소프트웨어를 해킹함으로써 소프트웨어를 만드는 것처럼 보이는 느낌의 근본 원인이라고 생각합니다.

나는 학위를 얻지 못했지만 대학 도서관과 실험실에서 약간을 얻었습니다.

• Big Iron- 그들이 가르치는 기술은 주로 메인 프레임과 미니 컴퓨터였습니다. 한 대학의 학장은 내가 마스터 파일이 무엇인지조차 몰랐기 때문에 일자리를 얻을 수 없을 것이라고 말했습니다. 여유가 없어서 메인 프레임 작업을 할 생각이 없었지만 약간 준비가되지 않은 것처럼 어리석지 않았습니다. VAXen은 시원했고 큐비클에있는 내 Micro VAX의 코드를 지불하기를 기대하고있었습니다. 시장이 전적으로 부끄러운 것을 수치스럽게 생각합니다. (그 결과 IBM의 계약자로서 메인 프레임으로 작업하는 두 가지 직책이있었습니다.)

• 소프트웨어 엔지니어링 -구조적 프로그래밍, SASD 및 기타 설계 방법론의 발판에서 우리는 실제 엔지니어가 될 것이라고 생각했을 것입니다. 나는했다. 그러나 교사들은 내가 도서관에서 읽은 디자인 기법에 대해 거의 안내하지 않았습니다. 학생들은 스스로를 지키기 위해 남겨두고 마이크로는 그들이 만족스러운 답변을 얻을 때까지 코드를 작성하기가 너무 쉬워졌습니다. 나는 직업 시장에서 그것이 얼마나 더 나빠지는지 몰랐다. 어쨌든 나는 아주 새로운 코드를 작성해야 했으므로 지루하지 않았습니다. 그러나 나는 또한 많은 것을 인수했고, 많은 코드를 수정해야했기 때문에 새로운 프로젝트와 같았습니다. 기존 기능을 조사하고 새 코드를 작성 (대체)하는 조합이었습니다. 프로세스를 단순화하고 더 나은 프로젝트 관리를위한 도구 작성

• 최첨단 경력 -학교에 오래된 건물과 장비가있는 경우 (1984 년에 시작하기 전에 펀치 카드 장비가 학기 교체 되었음), 조명이 어두운 창고에서 일하거나 전화를 끊는 상사를 위해 일하는 경우 고객 지원 센터에 전화를 걸면 작업 설명에 5 메가 와트 레이저의 팝콘 요리가 포함되지 않을 것입니다.

• 개발은 주로 팀워크입니다. 즉, 의사 소통 (음성 및 읽기), 다른 사람의 코드 읽기 및 이전 모듈 (사내 및 외부 모두)의 재사용은 거의 매일 직면해야합니다. 대학에서는 최소한 몇 번이라도 더 많은 사람들과 코드를 작성해야했기 때문에 작업의 주요 부분은 광야에서 코드 만 작성하는 것이라고 생각했습니다. 그렇지 않습니다.
• 비 개발자에게 설명하는 것은 어렵고 (첫 번째 요점도 포함), 다른 세계의 99 %가 아닌 귀하의 요점을 밝히는 것은 귀하의 책임입니다.
• 좋은 테스트는 실패한 테스트입니다. (최소한 처음) 그리고 물론, 버그가없는 코드는 없습니다. 버그가 있다면 나쁜 프로그래머가 아닙니다. 버그는 작업에서 (매우 중요하고 시간이 많이 걸리는) 부분입니다.
• 은 총알이 없습니다. 각 기술에는 장단점이 있습니다.
• College는 최신 기술을 가르치지 않습니다. 또한 작품의 90 %가 오래된 기술을 사용합니다. 그건 그렇고 때로는 필요한 것입니다.
• 비 기술적 인 사람들은 주로 유지 보수, 파트너십, 근로자의 가용성 등과 같은 비전적인 이유로 기술적 솔루션에 대한 결정 을 내립니다 ...
• 당신은 방금 시작했습니다 , 젊은 padawan .

그 이후로 코딩이 더 많은 사람들과 함께하는 작업이라는 사실, 특히 오픈 소스가 더욱 두드러지게되었다는 사실을 깨닫기 시작했습니다. 그러나 내가 대학에 왔을 때 (90 년대 후반), 나는 처음부터 일을하고 다른 사람의 코드를 보거나 다른 사람들과 조율 할 필요가 없다고 확신했다 ...

돌아 보면, 나에게 가장 좋은 부분 중 하나입니다 학습 및 다른 사람을 가르치고 .

• 컴퓨터 프로그래밍은 비 물리적이고 직관적이지 않습니다.
  • 주택 건설업자가 작업을 마치면 주위를 돌아 다니거나 잘못된 것이 있으면 즉시 보거나 느낄 수 있습니다. 컴퓨터 프로그래밍 버그는 같은 방식으로 발견 할 수 없으며 시스템에 몇 달 또는 수십 년 동안 숨어있을 수 있습니다.
  • 프로그래머는 코드 검토를 통해 소스 코드를 보거나 느낄 수 있지만 코드에 포함 된 모든 오류를 발견 할 수는 없습니다. 그러나 컴퓨터는 특정 입력으로 프로그램을 실행하여 매번 오류를 정확하게 재현 할 수 있습니다. 따라서 소스 코드에 대한 인간의 이해는 항상 컴퓨터에 대한 지침이라는 본질에 대한 불완전한 모델입니다.
• 가장 일반적인 경우를 처리하는 프로그램을 코딩하는 것은 매우 쉽지만 가장자리를 처리하는 데는 완전히 실패합니다.
  • 다른 분야에서는 사후 조치를 취하기가 비교적 쉽습니다. 치료 조치를 위해 특별히 고안된 지식 기관이있을 수도 있습니다. 소프트웨어 개발에는 그러한 것이 없습니다.
  • 다행스럽게도, 테스트 중심 개발은 코드가 처리해야하는 중요한 경우를 체계화하는 데 도움이됩니다.
  • 추가 된 반면에, 특정 소프트웨어 개발 방법론은 우리가 의식적으로 가장자리 경우를 처리하고, 고객에게 그 결정을 의사 소통을하지 선택하여 비즈니스 가치 (시장에 빠른 시간 등)을 추출 할 수 있음을 시사하는 것 같다.
• 고객은 가장 일반적인 경우 만 처리하는 소프트웨어에서 비즈니스 가치를 찾을 수 있으므로 소프트웨어 제공 업체는 드문 경우를 처리하는 것에 대해 너무 걱정하지 않습니다.
  • 고객은 단순히 거친 가장자리를 피하는 법을 배웁니다.

추가

• 소스 코드의 우아함은 가치가 없습니다.
  • 고객은 소스 코드의 우아함을 보지 못합니다. 그들은 사용자 인터페이스의 우아함과 상호 작용 만 볼 수 있습니다.
  • 반면 프로그래머는 일반적으로 사용자 인터페이스의 우아함을 소중히 여기지 않으며, 우아한 소프트웨어 디자인을 감상하기 시작할 정도로 오랫동안 단일 프로젝트에 머물지 않습니다.
  • 고객이나 프로그래머 모두 소스 코드의 우아함을 소중히 여기지 않기 때문에 비즈니스에서도 가치를 인정하지 않습니다.

추가

내 두 센트 : 그냥 익숙해 지십시오.

ISO 프로세스 이미지, 기술 문서 다량, 모든 기능 및 버그가 엄격하게 문서화되어 있으며 일반적으로 전문적인 환경에서는 회사를 잘 설명합니다. 우리는 중요한 인프라 소프트웨어 / 하드웨어 제품을 수행하므로 품질 에 대한 압박이 가중 되고 있습니다 (예 : ISO 9001 인증).

졸업 한 후에는 담당자가 나쁜 일에서 좋은 일을 인식 할 수 있다고 생각했습니다. "최고의 코더가 만든 정말 훌륭한 코드"의 백만 번째 사본을 건네받은 후 다음과 같이 보입니다.

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

나는 뾰족한 머리 보스의 귀 사이에 무슨 일이 일어나고 있는지 이해하려고 거의 포기했습니다. "위대한"이란 유지 악몽을 의미하고, "좋은"은 산들 바람에 충돌을 의미하며 "끔찍한 혼란"은 엔지니어가 위생을 유지하기 위해 음란 한 기한을 지키기를 거부 한 구조화 된 코드 기반을 의미합니다.

첫 번째 코드 줄 이후의 모든 소프트웨어 엔지니어링은 유지 관리라고 주장하는 것을 들었습니다. 그리고 그것은 분명히 내 경험과 일치하는 것 같습니다. 필자가 작성한 유일한 코드는 유지 관리가되는 비용의 대부분을 가지지 못했기 때문에 결코 성공하지 못하거나 잠깐 사용되지 않은 코드였습니다.

강력한 프로세스를 개발하고 따르는 전문화 된 엔지니어링 팀을 찾을 수 있다고 생각합니다. 강력한 코드가 출시되어 팀이 높은 수준의 신뢰를 가질 수 있습니다. 나는 지금 같은 팀에서 일하고 있다고 생각합니다. 나는 다른 종류의 개발을 확실히 경험했지만.

그래도 내가 이해하게 된 것은 문제가 항상 완벽한 알고리즘이나 문제에 대한 가장 깨끗한 해결책을 찾는 것이 아니라는 것입니다. 그러나 종종 모든 종류의 제약 (자원, 지식, 돈, 시간, 기술, 위험, 기존 사용자 교육 등)을 거래하여 가용 투자에 대한 최고의 수익을 달성하십시오. 그것은 기술적 영향뿐만 아니라 모든 요소에 가장 적합한 시스템을 구축하는 것입니다.

많은 소프트웨어가 소프트웨어를 충분히 사용 / 구매하는 시점까지 만들지 않습니다. 그것을 만들 때, 그것은 붙어 경향이 있으며 유지 보수에서 "메시지"만 있습니다.

기능에 대한 사용자의 기대치는 매일 증가하고 있지만 많은 영역에서 엔지니어링 영역에서는 더 낮습니다. 은행 거래 소프트웨어가 현대 자동차처럼 견고하고 전문적으로 설계되었다고 가정 해 봅시다. 거래량을 다루는 것은 현대의 놀라운 일이지만 각 거래의 신뢰성을 높이는 것은 무엇입니까? 별로. 깔개에 강아지의 첫 번째 쓰레기에 대한 귀하의 게시물이 삭제되었습니다. 식료품 점에있는 작은 비닐 봉투와 비슷합니다. 그들은 수십억 달러를 벌이고 찢고 찢어 버립니다. 대부분의 사람들은 더 나은 가방을 요구하기에 충분히 신경 쓰지 않습니다.

결국에는 양질의 소프트웨어가 만들어 졌다고 생각합니다. 그 중 일부는 대부분의 상용 제품보다 빨리 시장에 출시됩니다. 누가 베타에서 자동차를 운전하게됩니까?