프로그래밍 패러다임 및 유지 보수 개발자 [닫기]

유지 보수 섹션이있는 소프트웨어 엔지니어링의 사실과 오류를 읽고있었습니다. 저는 몇 년 동안 유지 보수 개발자로 일해 왔기 때문에 매우 흥미로운 사실을 제시했습니다. 여기 3 개가 있습니다.

• 사실 41 : 유지 보수는 일반적으로 소프트웨어 비용의 40-80 % (평균, 60 %)를 소비합니다. 따라서 아마도 소프트웨어의 가장 중요한 수명주기 단계 일 것입니다.
• 사실 42 : 향상은 소프트웨어 유지 관리 비용의 약 60 %를 담당합니다. 오류 수정은 약 17 %입니다. 따라서 소프트웨어 유지 관리는 주로 수정하지 않고 이전 소프트웨어에 새로운 기능을 추가하는 것입니다.
• 사실 45 : 더 나은 소프트웨어 엔지니어링 개발로 더 많은 유지 보수가 가능합니다.

이것은 직관적이지 않았으며, 좋은 소프트웨어는 변경하기 쉽기 때문에 더 많은 유지 보수가 필요하다는 것이 밝혀졌습니다. 따라서 더 오래 사용되므로 더 많은 변경 사항이 발생합니다.

기능, 객체 지향, 절차와 같은 패러다임은 유지 관리 성이 가장 우수하며이를 뒷받침하는 연구가 있습니까?

기능, OO 및 절차와 같은 패러다임이 소프트웨어 유지 관리 기능과 의미있는 방식으로 연결되지는 않을 것입니다.

소프트웨어 유지 관리 기능을 통해 다음과 같은 내용을 훨씬 더 명확하게 확인할 수 있습니다.

• 요구 사항 수집 및 요구 사항 엔지니어링 레벨

• 좋은 개발 관행 : (느슨한 커플 링, 높은 응집력, 단위 테스트, YAGNI ...)

• 숙련되고 자격을 갖춘 소프트웨어 엔지니어 (무론보다 10 배나 가치가 있음)

• 자격을 갖춘 체계적인 기술 QA 팀

• 유능한 프로젝트 관리자가 주도하는 우수한 프로젝트 관리 (숙련 된 소프트웨어 개발자보다 IMHO를 찾기가 더 어렵다)

• 좋은 제품 소유자 또는 응용 프로그램 관리자, 강력한 리더십, 좋은 장기 방향, 프로젝트 팀에 대한 좋은 피드백, 전반적인 비전.

이것은 직관적이지 않았으며, 좋은 소프트웨어는 변경하기 쉽기 때문에 더 많은 유지 보수가 필요하다는 것이 밝혀졌습니다. 따라서 더 오래 사용되므로 더 많은 변경 사항이 발생합니다.

당신은 비용의 비율이 아니라 유지 보수의 양에서 이것을보고있는 것 같습니다. 더 많은 기능이 추가 된 좋은 소프트웨어는 많은 양의 소프트웨어입니다. 유지 관리 비율이 고정되어 있으면 (소프트웨어가 양호하고 추가 기능이 양호한 소프트웨어로 추가되었다고 가정하기 때문에) 양이 증가합니다. 그것은 같은 수의 조각을 가진 더 큰 파이 조각 일뿐입니다.

요청한 내용에 따라 "좋은"소프트웨어가 기능적, OOP 또는 절차 적 코드로 작성되었는지 여부가 중요합니다. 사람이 측정하는 방법을 모른다면 누군가에게 레이저 유도 식 파워 쏘를 주면 목재를 절약 할 수 있습니까?