"안녕, 아미고!"
"안녕, 빌라보!"
"오늘은 보통 프로그램이 어떻게 개발되는지 알려드리려고 합니다."
"현대 IT가 태동하던 20세기에는 누구나 프로그래밍을 건설이나 제조와 같다고 생각하는 것 같았습니다."
"일반적으로 다음과 같이 진행되었습니다."
" 고객은 자신에게 필요한 프로그램 유형, 즉 수행해야 하는 작업과 수행 방법을 설명할 것입니다."
" 비즈니스 분석가는 그의 말을 듣고 그가 말한 내용을 기반으로 프로그램 요구 사항의 전체 목록을 만들 것입니다."
"그런 다음 프로젝트 관리자는 이러한 요구 사항을 작업으로 나누고 어떤 프로그래머가 어떤 작업을 어떤 순서로 수행할지 결정합니다."
"그러면 프로그래머들이 일을 시작합니다. 때로는 몇 년(!) 동안 일하기도 합니다."
"작업이 완료되면 프로그램이 테스터에게 제공되었습니다."
" 테스터는 각 프로그램의 요구 사항을 검토하여 프로그램이 구현되었고 프로그램이 예상대로 작동하는지 확인했습니다."
"뭔가 잘못되면 테스터는 버그를 기록하고 프로그래머에게 보냅니다."
"그런 다음 프로그래머는 버그를 수정하고 수정된 프로그램을 테스터에게 다시 보냅니다. 그리고 주기가 반복됩니다."
"주요 버그가 수정되었을 때 고객에게 프로그램이 제공되었습니다."
"그게 정말 일이 어떻게 된거야?"
"글쎄요, 물론 저는 많이 단순화했지만 작업이 수행된 방식에 매우 가깝습니다."
"그러면 프로젝트를 완료하는 데 정말 1년 반에서 2년이 걸릴 수 있나요?"
"때때로 프로젝트의 개발이 정말 길면 프로젝트를 별도의 릴리스로 나눕니다. 개발자는 3-6개월마다 프로그램 기능의 특정 부분을 만들고 테스트하고 모든 버그를 수정한 다음 프로젝트에 보여줘야 했습니다. 고객."
"먼저 그가 자신의 인상을 공유할 수 있도록. 그리고 두 번째로, 그리고 더 중요한 것은 그가 프로그램 개발 비용을 계속 지불할 수 있도록."
"계속 결제?"
"당시에는 개발 시간이 계획보다 2~3배 오래 걸리는 경우가 많았습니다. 그리고 프로그래머가 시급을 받는 경우가 많아 프로그램 비용이 2~3배 더 비쌌습니다. 게다가 혜택도 줄었습니다. 결국 오늘날 고객이 원하는 것은 $100,000는 3년 안에 필요하지 않을 수 있습니다. 특히 가격이 3배나 더 비쌉니다."
"고객이 결제를 자주 거부했습니까?"
"네. 그들은 나중에 계약에 벌칙을 추가하기 시작했지만 상황이 개선되지 않았습니다. 소프트웨어 개발은 계속해서 지연되었습니다. 그리고 아무도 원하더라도 그것에 대해 아무것도 할 수 없었습니다."
"근데 왜?"
"글쎄요, 먼저 계획 단계에서 알려진 것이 너무 적습니다. 처음에는 아무도 프로그래머가 직면할 문제를 예측할 수 없었습니다."
"하지만 숙련된 프로그래머는 모든 것을 예측할 수 있어야 했죠?"
"프로그래밍이 독특한 직업이라는 것을 알 수 있습니까?"
"평범한 노동자는 종종 같은 일을 반복해서 수행합니다. 시계공은 시계를 만들고, 요리를 하고, 교사는 가르치고, 의사는 치료합니다."
"이 전문가들 각각은 기본적으로 매일 같은 일을 합니다. 결과적으로 그들은 일을 점점 더 잘하기 시작합니다."
"프로그래밍에서는 접근 방식이 다릅니다. 프로그래머는 매일 같은 작업에 직면하자마자 이를 수행하기 위해 함수, 모듈 또는 프로그램을 작성하고 다시는 그 작업으로 돌아오지 않습니다."
"각각의 프로그래머는 일반적으로 일생에 한 번 각 작업을 해결합니다."
"물건을 발명하는 과학자나 설계 엔지니어 같은 것."
"아. 그럼 프로젝트에서 가장 중요한 역할은 뭐지?"
"흠, 어떻게 대답해야 할까. 무엇이 가장 중요하다고 말하기는 쉽지만 가장 덜 중요한 것을 식별하는 것은 어렵다."
" 테스터( Q uality A ssurance, QA ) 의 주요 업무 는 프로그램의 상태를 모니터링하고 버그를 신속하게 보고하는 것입니다. 테스터가 버그를 더 빨리 발견할수록 더 많은 버그를 수정할 수 있습니다. 좋은 테스터는 제품 품질에 더 많은 영향을 미칩니다. 좋은 프로그래머는 ."
"프로그래머가 자신의 프로그램을 테스트할 수 없는 이유는 무엇입니까? 어쨌든 그들은 무엇이 작동하고 작동하지 않는지 테스터보다 더 잘 알고 있지 않습니까?"
"좋은 프로그래머는 단순히 좋은 테스터가 될 수 없습니다. 프로그래머는 프로그램이 실제로 어떻게 작동하는지 알고 있기 때문에 항상 특정 방식으로 사용합니다. 원하는대로 프로그램을 사용하는 일반 사용자와 달리. "
"또한 테스터는 아직 작동하지 않는 것을 테스트하지 않습니다. 테스터는 프로그래머가 이미 거의 완벽하게 작동한다고 말하는 프로그램의 기능이나 일부를 테스트합니다."
"그리고 테스터가 해당 기능에서 수많은 버그를 발견하고 프로그래머가 버그를 수정하면 제품은 실제로 완벽에 가까워집니다."
" 프로그래머( Software Developer E ngineer, Developer , SDE )의 주요 임무는 새로운 기능 을 구현 하는 것 입니다 . 간단히 말해서 자신에게 할당된 작업을 수행하는 것입니다. 프로그래머에게 새로운 기능이 할당된 작업이 있을 때 , 그들은 그것을 수행합니다. 버그가 할당되면 버그를 수정합니다."
"그러나 때때로 더 어려운 작업이 있습니다. 예를 들어 프로그램 또는 그 일부에 대한 아키텍처를 제안합니다. 제안된 아키텍처가 좋을수록 향후 작업을 수행하기가 더 쉬워집니다."
"문제는 처음부터 아키텍처를 선택해야 하지만 올바른 아키텍처를 선택했는지 여부가 명확하지 않은 것은 개발 중반에 이르러야 한다는 것입니다."
"또한 아키텍처가 성공적이고 프로그램이 훌륭하다면 고객은 이를 프로그램의 새 버전의 기반으로 사용하기를 원할 것입니다."
"여기에 내가 하려고 하는 것이 있다."
"어떤 아키텍처를 선택하든 아키텍처가 설명하지 못하는 많은 변경 사항, 추가 사항 및 새로운 기능이 항상 있을 것입니다."
"여기에 좋은 예가 있습니다."
"고객이 5층 건물을 지어달라고 해서 건축을 설계하고 집을 짓습니다."
"그런 다음 고객은 다른 이야기를 추가하도록 요청한 다음 또 다른 이야기를 추가하도록 요청합니다."
"그러나 1층의 벽은 그 정도의 무게에 맞게 설계되지 않았고 기초도 마찬가지였습니다. 그래서 모든 것을 다시 해야 했습니다."
"하지만 5층 건물이 완공된 후 고객이 즉시 50층 건물을 원한다고 결정하면 어떻게 될까요?"
"기존 구조물을 허물고 처음부터 다시 짓는 것이 더 쉬울 텐데..."
"하지만 건축과 관련하여 조언이 하나 있습니다."
"응용 프로그램의 아키텍처는 무엇보다 유연해야 합니다. 즉, 응용 프로그램의 절반을 다시 실행하기로 결정한 경우 처음부터 시작할 필요가 없습니다. 이러한 유형의 아키텍처를 일반적으로 유연 하고 모듈식이 라고 합니다 ."
" 프로젝트 매니저의 주요 업무 는 의사 결정입니다. 프로젝트 매니저는 큰 그림을 보고 그 관점에서 의사 결정을 내리는 사람입니다."
"개발 중에 특정 작업이 계획대로 완료되지 않을 것이 분명해졌다고 가정합니다. 그러면 프로젝트 관리자가 다음을 수행할 수 있습니다."
" a) 작업을 수정하기 위해 고객과 협상을 시도하십시오."
" b) 작업에 더 많은 시간 할당"
" c) 다른 프로젝트에서 경험 많은 프로그래머를 데려옵니다."
"그리고 다른 많은 가능성이 있습니다."
"각 옵션은 당신이 무언가를 희생해야 하며, 매니저의 임무는 이러한 희생으로 인한 총 손실을 최소화하는 것입니다. "
"예를 들어, 경쟁자가 수석 프로그래머에게 두 배의 돈을 제안하여 그를 훔친다고 가정해 봅시다."
"프로젝트 관리자는 다음을 수행할 수 있습니다."
" a) 아무 것도 하지 마십시오. 프로그래머는 떠나고 프로젝트는 뒤처져 페널티를 받게 될 것입니다."
" b) 그의 급여를 두 배로 올리십시오. 그러면 팀의 다른 모든 사람들도 인상을 원할 것입니다. 그들 모두에게 더 많은 돈을 주면 프로젝트 비용이 증가하고 수익성이 없게 될 수 있습니다."
" c) 당신이 생각하는 다른 옵션."
"알겠어요."
"잘못된 프로젝트 관리자와 함께 좋은 팀은 일반적으로 프로젝트를 연장하지만 항상 그런 것은 아닙니다."
"평균적인 프로그래머들로 구성된 팀을 가진 좋은 관리자는 거의 항상 뛰어난 프로그래머들로 구성된 팀을 가진 나쁜 관리자보다 더 빨리 프로젝트를 완료합니다."
"알겠어요."
"알았어, 잠시 쉬었다가 계속하자."
GO TO FULL VERSION