소프트웨어가 과장된 원인은 무엇입니까? [닫은]

오늘 나는 Creative Sound Blaster 드라이버를 항상 새로 설치하기로 결정했습니다. 그리고 그것은 전체 청소 절차를 거쳐야한다는 것을 의미했습니다. 거의 2 시간이 걸렸습니다.

그리고 솔직히, 나는 왜 이유를 볼 수 없습니까?! IMHO (Creative)는 결코 작동하지 않는 저품질 소프트웨어를 생산하는 데있어 1 위를 차지했지만 절대 문제는 아닙니다.

Canon 디지털 카메라 드라이버가 장착 된 PC에는 모든 종류의 연결과 상호 연결된 약 10 개의 Canon 항목이 있습니다. Visual Studio는 또한 주요한 예이며, 전체 설치를위한 약 50 개 정도의 항목이 있으며, 해당 항목을 복구하는 것은 완전한 nuking으로 만 가능합니다. 그리고 일단 VS2k8에서 VS2k8SP1 또는 다른 것으로 업그레이드 할 때 전체 OS 설치를 망칠 수있었습니다. 300GB 패치에는 5GB의 여유 공간이 충분하지 않은 것으로 나타났습니다 ...

따라서 이것은 실제로 광범위한 문제인 것 같습니다. 오늘날 거의 모든 응용 프로그램에는 일반적으로 언 패커, 설치된 여러 스파이 족 "친구", 프린터 등 프린터를 포함한 모든 항목에 대해 600Mb 정도가 포함되어 있습니다.

그런데 왜? 개발자 결함입니까? 이와 같은 응용 프로그램은 지원하기에 악몽이며, 현재 100 % 작동하지 않으며, 내가 아는 거의 모든 사용자는 USB 썸 드라이브 / 프린터 / 카메라 / 사운드 카드 / 브라우저에 대한 필수 드라이버 설치로 얻는 모든 팽창에 대해 매우 부정적입니다.

Nullsoft의 NSIS는 Firefox 설치와 같이 내가 아는 것으로부터 부풀려지지 않은 유일한 깨끗한 설정 시스템 인 것 같습니다. 문제없이 깨끗하고 거의 xcopy 기반 설치.

그렇다면 사람들이 30 층 이상의 상호 연결이 아닌 간단한 설정과 응용 프로그램을 사용하지 않는 이유는 무엇입니까? 개발자가 게으 르기 때문입니까? Codegen 도구를 사용하십니까? 기업이 사용자가 좋아할만한 무거운 앱을 강요하기 때문입니까? 원인은 무엇이며 언젠가 소프트웨어가 언젠가 기본으로 되돌아 갈 것이라는 희망이 있습니까? 새로운 응용 프로그램을 처음 시작할 때 부풀림을 피하는 단계는 무엇입니까?

내 생각에는 누군가가 좋은 생각이라고 생각한 많은 기능이 있다는 것입니다. 그러나 많은 사람들이 모두 하나의 응용 프로그램에 통합되는 별도의 아이디어를 가지고 있다면 이것이 그렇게 복잡해질 수있는 방법입니다. 제품의 내용과 다양한 관점에서 제품을 최적화하는 방법에 대한 책임이있는 제품 관리자가 있어야하는 대기업 제품의 경우 개발자를 비난하지 않습니다.

이것의 또 다른 측면은 많은 시간 투자로 보이지 않기 때문에 대부분의 경우 잘 관리되지 않는 기술 부채입니다. 새로운 기능과 버그 수정이 즉각적인 비즈니스 가치가 거의없는 것으로 보이는 리팩토링 또는 기타 부채 업무보다 더 의미가 있다고 생각합니다. 코드베이스가 다소 오래된 경우 개발자 팀이 레거시 코드를 정리하는 데 몇 주가 걸리는 빈도는? 내 추측은 자주하지 않을 것입니다.

전략 서신 IV : Bloatware와 80/20 신화 에서 Joel을 인용하려면 :

[...] bloatware에는 많은 훌륭한 이유가 있습니다. 예를 들어, 프로그래머가 코드의 크기에 대해 걱정할 필요가 없다면 더 빨리 선적 할 수 있습니다. [...] 소프트웨어 공급 업체가 배송을 중단하고 코드를 압축하여 코드를 50 % 더 작게 만드는 데 2 ​​개월이 걸리면 순이익이 눈에 띄지 않게됩니다. [...] 그러나 새 버전을 위해 추가로 2 개월을 기다리는 손실은 인식 할 수 있으며, 2 개월 동안 판매를 포기해야하는 소프트웨어 회사의 손실은 더욱 악화됩니다.

구식 "80/20"규칙에 따라 많은 소프트웨어 개발자들이 유혹을받습니다. 보인다 의미를 많이 만들어 : 사람들의 80 %는 기능의 20 %를 사용합니다. 따라서 기능의 20 % 만 구현하면되며 80 %를 판매 할 수 있습니다.

불행히도, 결코 같은 20 %는 아닙니다. 모두 다른 기능 세트를 사용합니다. [...]

당신이 당신의 "라이트"제품 마케팅을 시작, 당신은 사람들에게 때, "야, 그것의 라이트 만 1메가바이트는"그들은 매우 행복 경향이있는 경우, 그들은 당신에게 자신의 중요한 기능을하고, 그렇게하지 않습니다 그들은 당신의 제품을 사지 않습니다.

그것의 상당 부분은 제품의 의존성과 관련이 있습니다. 운영 체제는 모든 종류의 것들을위한 많은 표준 라이브러리와 함께 제공됩니다. 그러나 이러한 표준 라이브러리는 OS의 발전에 따라 서로 다른 버전을 가지고 있으며 일반 설치 프로그램은 빌드 된 특정 버전이 실제로 OS에 있다고 가정 할 수 없습니다.

따라서 전체 설치 프로그램에는 대상 컴퓨터에 대한 각 종속성의 초기 상태에 관계없이 설치 후 모든 것이 제대로 작동하는지 확인하기 위해 모든 종속성의 올바른 버전이 포함되어야합니다. 이는 특정 유형의 응용 프로그램 (예 : Windows XP 시스템에 배포해야하는 .NET 기반 응용 프로그램)에 큰 영향을 줄 수 있습니다.

최근까지, 내가 작업했던 하나의 설치 시스템은 최신 버전을 배포 할 수 있도록 모든 이전 .NET 버전을 설치해야했기 때문에 모든 .NET 3.5 응용 프로그램에는 .NET 1, 2, 2.5 및 3의 설치 바이너리가 필요했습니다. 3.5 위. 이 경우 설치 프로그램 만 팽창됩니다.

한 가지 해결 방법은 웹 설치 프로그램으로, 대상 시스템에 실제로 존재하지 않는 구성 요소 만 다운로드합니다. 이는 막대한 크기 / 팽창 이점이 될 수 있습니다. 물론 인터넷 연결이 가능한 시스템으로 설치를 제한합니다.

라이브러리 코드 레이어에 레이어와 관련이 있다고 생각합니다. 분명히 라이브러리를 사용할 때 라이브러리에 모든 것을 사용하지 않으므로 점점 더 많은 라이브러리를 포함함에 따라 초과분이 더해집니다.

일반적인 컴퓨터의 처리 능력 / 스토리지가 매년 저렴 해지면서 프로그래머의 1 시간 작업 비용이 점점 비싸지고 있다는 사실과 결합하면 실제로 이런 방식으로 더 비용 효율적이라는 것을 알 수 있습니다.

• "우리는 X를 할 무언가가 필요하다. 다른 프로젝트에서 그것을 사용했기 때문에 라이브러리 $ BIGFATLIBDESIGNEDFORSOMETHINGELSE를 사용하자"
• "우리는 더 이상이 코드 부분이 필요하지 않다고 생각하지만, 아무것도 깨지지 않도록하려면 그냥 유지하십시오"
• 단위 테스트가 없거나 충분하지 않아서
• 리팩토링 없음
• 수년에 걸쳐 설정이 저장된 추적이 없으므로 이제 설정이 어디에나 있습니다.
• ...

절망 의 주기에 있는 모든 사람 이 탓할 수 있는 악순환 이다. 절망의 한주기는 다음 단계로 구성됩니다.

1. 사업 사람들은 부풀어 오른 기능을 요구합니다.
2. 개발자는해서는 안되는 것을 알고 있지만 부풀린 기능을 구현합니다.
3. 고객은 바보 같은 기능이 아닌 제품 만 원하더라도 부풀린 기능에 대한 비용을 지불합니다.
4. 비즈니스 사람들은 고객이 부풀린 기능을 원한다고 생각합니다.
5. 1 단계로 이동하여 반복하십시오.

어떻게 멈춰요? 방법에 대한 쉬운 대답은 없지만주기를 중단하려면 단계 중 하나를 중단해야합니다. 따라서 비즈니스, 개발자 또는 소비자가 혁신적인 행동을 취함으로써 만 깨질 수 있습니다.

1. 엔지니어가 모듈을 최적화하려고했지만 몇 가지 고객 문제가 발생했습니다. 그런 다음 그의 매니저는 거절했다. 그런 다음 엔지니어는 문제가 발생할 때까지 "문제를 일으키지 않기"로 결정했습니다.
2. 복잡한 시스템의 경우 공급 업체는 이미 고객 환경에서 안정적으로 유지하기 위해 많은 패치를 추가하고 수천 개의 버그를 수정했습니다. 그것은 소프트웨어의 관점에서 좋은 품질을 가지고 있지 않지만 작동합니다. 아무도 같은 양의 버그를 다시 수정하기 위해 다시 작성하고 싶지 않습니다.
3. 이전 버전과의 호환성을 위해 시장에서 기능이 널리 사용되지 않더라도이를 유지해야합니다.

그것의 변치 않는 게으름, 그것이 팽창을 일으키는 원인입니다. (또는이 주제에 관한 주요 기사 인 진흙의 큰 공 처럼 진흙 )

예를 들어, 제가 일하는 곳에서는 "레거시"C ++ 응용 프로그램이 있습니다. 그럼에도 불구하고 클라이언트는 DB가 작동하는 서버와 통신하는 API와 통신합니다. 모든 것이 현명하게 이루어졌습니다. 최근에 우리는 추가 모듈이 필요했지만 올바르게 구현하기보다는 개발자가 .NET에서 이것을 구현하기로 결정했으며, 더 나쁜 것은 API를 통해 데이터에 액세스하는 것이 너무 어려워서 (단지 아니라 ...) DB 연결을 만들 것이라고 결정했습니다. 직접. 이런 종류의 혼란이 어떻게 일어나는지 알 수 있습니다. (그리고 "빠른 것"을 "좋은 것"으로 두는 TA의 동의를 얻어서)

예전에는 이런 종류의 것을 보았습니다. 예전에는 GUI의 작은 부분이 html이었습니다. 일부 개발자는 html로 데이터를 작성하고 GUI를 표시하는 것이 좋습니다. 따라서 1 개의 작은 부분이 나머지 부분과 다른 역할을합니다.

요컨대, 게으름이 나쁘고 일관성이 우수합니다 (사용되는 기술에 관계없이). 오히려 MFC와 Winforms 및 WebGL을 모두 묶는 많은 백엔드 아키텍처가있는 WebGL 응용 프로그램보다 모든 MFC 응용 프로그램을 원합니다.