개발 방법이 개발자의 개인주의를 무너 뜨릴까요?

저는 대학의 마지막 학기에 있으며 소프트웨어 엔지니어링 과정을 수강하고 있습니다. 이 수업에서는 다양한 소프트웨어 개발 방법에 대해 배웁니다. 우리가 집중하고 프로젝트를 개발하는 데 사용한 방법은 폭포 방식이었습니다.

강사가 잘못 구현 한 것 같습니다. 클래스 다이어그램에는 개인 속성을 포함한 모든 속성과 메서드를 나열해야했습니다. 기능을 최대한 짧고 집중적으로 유지하는 몇 가지 책, 즉 Clean Code를 읽었습니다. 다른 개발자를 도와주지 않으면 다이어그램에 모든 작은 기능을 나열하는 것이 지루한 것 같습니다 (비공개, 다른 사람은 사용하지 않을 것입니다). 또한 프로그램을 설계 할 때 모든 작은 기능을 생각하지 못할 수도 있으며 리팩토링 할 때 나타날 수 있습니다.

강사는 우리에게 모든 기능을 열거하도록 요청함으로써 우리에게 틀렸다고 말했습니까? 그리고 이러한 설계 방법이 개발자의 개인주의를 무너 뜨려서 그것을 가장 잘 이해할 수있는 코드를 작성합니까?

왜 모든 방법을 나열해야하는지 강사에게 물었습니까?

강의실 환경에서 요구되는 많은 것들과 마찬가지로, 클래스 다이어그램을 개발자에게 더 유용하게 만들지 말고 귀하와 반 친구가 클래스 디자인 방법에 대해 생각하도록하는 것이 목적 일 수 있습니다. 학생들이 더 큰 문제를 더 작은 문제로 분해하는 방법을 배우면 아마도 어떤 개인적인 방법이 필요할지 생각하는 것이 도움이 될 것입니다. 그리고 누군가의 디자인이 제대로 고려되지 않은 경우 강사가 프로세스 초기에 개입하기 위해 학생들이 어떤 방법을 구현하려고하는지 더 잘 이해하는 것이 도움이 될 것입니다. 강의실 환경의 문서는 실제 환경의 문서보다 훨씬 더 복잡합니다.

물론 강사는이 수준의 문서가 실제 프로젝트에 도움이된다고 생각할 수도 있습니다. 이 경우 강사는 최신 정보가 아니거나이 수준의 계획 및 문서화가 적합한 특정 틈새 배경에서 비롯된 것일 수 있습니다. 예를 들어 우주 왕복선 용 내비게이션 시스템을 구축하거나 의료 기기를 설계하는 경우 일반적으로 개발 과정에서 코드를 리팩토링하는 대신 설계에 많은 투자를하는 것이 훨씬 더 적합합니다. 반면에 소셜 네트워킹 사이트를 개발하는 경우보다 민첩한 접근 방식이 더 적합합니다.

아닙니다. 강사는 Waterfall 메서드를 사용하는 경우 모든 속성과 메서드를 미리 나열하도록 지시합니다. Wikipedia 는 폭포에 대한 비판을 지적합니다.

많은 사람들이 폭포수 모델이 실제로 나쁜 생각이라고 주장합니다. 사소한 프로젝트가 소프트웨어 제품의 수명주기 단계를 완벽하게 마치고 다음 단계로 넘어 가서 배우기 전에는 불가능하다고 생각합니다. 예를 들어, 클라이언트는 작동중인 프로토 타입을 검토하고 주석을 달기 전에 필요한 요구 사항을 정확히 모를 수 있습니다. 요구 사항이 지속적으로 변경 될 수 있습니다. 디자이너와 프로그래머는이를 거의 제어하지 못할 수 있습니다. 설계가 완료된 후 고객이 요구 사항을 변경하는 경우 새로운 요구 사항에 맞게 설계를 수정해야합니다. 이는 많은 작업 시간을 무효화하는 것을 의미합니다. 이는 특히 많은 프로젝트 자원이 이미 Big Design Up Front에 투자 된 경우 비용 증가를 의미합니다.

이러한 디자인 방법은 여전히 ​​해석 할 부분과 구조에 대한 고유 한 손길을 가하는 방법 (예 : 골격이 주어진 그림, 근육과 다른 조직을 추가하여 동물이 얼마나 많은지 궁금해하는 동물을 만드는 방법)이 있기 때문에 디자인의 개별주의 구현자를 찌그러 뜨리지 않습니다. 그 동물을 자유롭게 디자인해야 했습니까?

폭포의 단점을 발견했지만 모든 장점과 단점이 있습니다.

이 수업에서는 다양한 소프트웨어 개발 방법에 대해 배웁니다. 우리가 집중하고 프로젝트를 개발하는 데 사용한 방법은 폭포 방식이었습니다.

처음부터 언급 한 소프트웨어 개발 세계에이 모델을 도입 한 사람이 대규모 소프트웨어 시스템을 개발하는 데 부적합한 클래식 폭포 모델을 배웠을 것입니다. 많은 사람들이 Waterfall 모델로 간주하는 문제에 대한 자세한 내용을 알아 보려면 Winston Royce의 대형 소프트웨어 시스템 개발 관리라는 제목의 논문 을 읽는 것이 좋습니다.

그러나 Waterfall 모델은 소프트웨어 개발 수명주기를 가르치는 데 유용하며 요구 사항 엔지니어링, 건축 설계, 세부 설계, 구현, 테스트 및 유지 관리에 대해 배우고 수행하는 데 매우 명확하고 뚜렷한 단계로 시간을 소비 할 수 있습니다.

클래스 다이어그램에는 개인 속성을 포함한 모든 속성과 메서드를 나열해야했습니다. 기능을 최대한 짧고 집중적으로 유지하는 몇 가지 책, 즉 Clean Code를 읽었습니다. 다른 개발자를 도와주지 않으면 다이어그램에 모든 작은 기능을 나열하는 것이 지루한 것 같습니다 (비공개, 다른 사람은 사용하지 않을 것입니다). 또한 프로그램을 설계 할 때 모든 작은 기능을 생각하지 못할 수도 있으며 리팩토링 할 때 나타날 수 있습니다.

이것들은 모두 매우 유효한 포인트입니다.

폭포수를 사용하는 경우에도 디자인 단계에서 모든 속성과 메서드를 나열하는 것은 너무 과도 할 수 있습니다. 필수 속성과 함께 공개 된 모든 것을 반드시 나열해야합니다. 실제로 다른 모든 것은 구현을 다이어그램으로 리버스 엔지니어링하여 얻을 수있는 구현 세부 사항입니다.

Clean Code의 조언 (나는 그것을 읽지 않았습니다-당신이 게시 한 내용으로 가고 있습니다)은 폭포 형 방법론을 사용할 때조차도 공정한 것으로 보입니다. 단일 책임 원칙 , 문제 분리 및 기타 SOLID 원칙 과 관련하여 클래스와 방법을 설계 할 수 있습니다 . 폭포는 필요할 때만 디자인하는 방법을 알려주지 않습니다. 즉, 구현하는 동안 더 나은 방법을 배우고 생각할수록 선구자가 더 어려워집니다.

디자인과 구현 사이에 반복이 필요하다는 사실을 지적합니다. 전통적인 폭포가 설명하지 않은 문제입니다.

다른 개발자를 도와주지 않으면 다이어그램에 모든 작은 기능을 나열하는 것이 지루한 것 같습니다 (비공개, 다른 사람은 사용하지 않을 것입니다).

이것이 지루하다고 생각되면 실제 작업 프로그래밍을 얻을 때까지 기다리십시오. 잠시 동안 해당 소프트웨어가 실용적이지 않을 수도 있습니다.

또한 프로그램을 설계 할 때 모든 작은 기능을 생각하지 못할 수도 있으며 리팩토링 할 때 나타날 수 있습니다.

그래서?

강사가 우리에게 모든 기능을 열거하도록 요청함으로써 우리에게 틀렸다고 말했습니까?

아니요. 일반적인 요구 사항입니다.

그리고 이러한 디자인 방법은 디자인 (개발자) 개인주의 구현자를 스쿼시하여 디자인을 가장 잘 이해할 수있는 코드를 작성합니까?

예. 개인의 영혼을 분쇄하는 것은 소프트웨어 개발의 중요한 부분입니다. 모든 개성을 가능한 모든 방법으로 모든 프로그래머로부터 항상 물리 칠 것입니다. 그것은 "하나님의 프로그래밍 규칙"어딘가가 어떤 산에서 어떤 선지자로 전해졌다 고 말합니다.

아뇨. 당신은 단지 지루한 일을하고 있습니다. 그것을 극복하고 다시 일을 시작하십시오.

프로그래밍은 제약 조건 내에서 작업하는 기술입니다. CPU는 제한된 명령어 세트를 제공합니다. IO는 하드웨어 설계에 의해 제한됩니다. OS API는 특정 행동을 장려하고 다른 행동을 제한하기 위해 만들어졌습니다. 고급 언어는 종종 하나의 관용구를 다른 것보다 홍보하도록 설계되었습니다 ...

그리고 방법론도 제한적으로 만들어졌습니다.

개발 프로세스의 모든 측면에서 문제는 이러한 제약 조건 내에서 비전을 실현하는 것 입니다. 하드웨어, 언어, API 및 방법론에 의해 발생하는 각 벽에 머리를 박살 치겠습니까? 아니면 성취하고 격려하고있는 것과 성취하고자하는 것을 조화시키는 방법을 찾을 수 있습니까?

당신이 할 정말 강사의 소원 특징점의 끝없는 페이지를 읽을 생각하십니까? 그런 다음 이론을 테스트하십시오. 프로그램을 분해하고 각 원자를 문서화하십시오. 그의 책상이 무게로 처질 때 그의 진정한 욕망이 당신이 기대하는 것과 약간 다르다는 것을 알 것입니다.

또는 문서를 준비하는 당신이 적합을 참조하십시오. 명확하게 이해하고 이해하기 쉽게 Dashiell Hammett 소설처럼 읽습니다. 그리고 앉아서 그와 이야기하고, 당신이 한 일을 보여주고, 그 장점을 확신시킵니다.

강사가이 프로젝트를하게함으로써 폭포 개발의 장단점을 가르쳐주는 것이 훌륭하다고 생각합니다.

프로젝트 분석의 복잡성을 측정하는 간단한 경험 법칙은 "개발자 나 그가 일하는 회사가 소프트웨어로 인해 발생하는 극적인 일 (일반적으로 사망 또는 막대한 돈 손실)을 책임질 수 있는가?"입니다.

내 코스 중 일부와 같은 경험을했습니다. 군사 산업에 대한 배경 지식을 가진 사람들은 우리에게 분석을 가르쳐 줄 것입니다. 그리고 그것은 아주 작은 세부 사항이라도 프로젝트의 모든 과정을 계획하는 완전하고 철저한 분석 일 것입니다. 이런 종류의 프로젝트로 많은 반복을 감당할 수 없으며 (폭발 폭발도 가능하고 예산 폭발도 불가능합니다) 창의력을위한 장소가 없으므로 계획을 따라야합니다.

반면에 조금 읽었다면 민첩한 방법론에 대해 확실히 읽을 수 있습니다. 일반적으로 문서가 적고 개발자가 자신의 창의력을 활용하면서 발생하는 문제에 대한 해결책을 개발할 수있는 여지가 더 많습니다.

결론적으로, 경험이 많을수록 더 좋으며 강사가 보여주는 내용이 산업의 일부에 적용됩니다. 프로젝트를 코딩하는 것만 큼 프로젝트를 관리하고 디자인하는 방법이 많이 있다는 것을 명심하십시오. 그리고 당신은 그들 모두에 대한 수비수와 비평가를 찾을 수 있습니다. 공부하는 동안 시험해보고 마음에 드는 것을 선택하십시오.

내가 가지고있는 것과 같은 일부 소프트웨어 엔지니어링 수업은 '실패는 성공'이고, 성공은 실패에서 배울 수있는 낭비 된 기회이며, 더 많을수록 더 적습니다. 이것이 그 중 하나라면 과제를 고수하고 이상한 것을 즐기십시오.

교수님의 연락이 닿지 않은 것 같습니다. 상용 소프트웨어는 그 정도까지 디자인되거나 문서화되지 않습니다. 너무 비싸서 결과 문서를 더 많은 비용없이 유지할 수 없습니다. IMO와 같은 관행은 코딩이 종종 어셈블리 언어로 수행 된 시절부터 나온 유산입니다. 테스트 중심 개발, 페어 프로그래밍, 지속적인 리팩토링과 같은보다 민첩한 관행을 시도하는 데 시간이 더 많이 소비되었을 것입니다.

강사가 "잘못 말했습니까?"

나도 그렇게 생각해.

지적 재산 근로자에게 지루한 작업을 할당하는 것은 낭비입니다. 학교에서 지루한 작업은 학생들에게 지루한 작업을 유도하는 것을 제외하고는 교육 학적 가치가 거의 없거나 전혀 없습니다. 이러한 운동은 학생과 산업 모두에 부정적인 영향을 미칩니다. 시간이 낭비되어 학생들이 해를 입습니다. 일부 학생들은 그러한 테디 움이 필요하고 유용하다고 결론을 내릴 수 있기 때문에 업계는 피해를 입습니다. 둘 다 아닙니다. 소프트웨어 분야에서 30 년 만에 제가 생각할 수있는 유일한 작업은 지루하고 유용했으며 백업 테이프를 변경하는 것이 었습니다. 그렇게 할 수있는 로봇이 있었지만 엄청나게 비쌌습니다.