소프트웨어 세계의 터무니없는 법칙

소프트웨어 개발자와 같은 똑똑한 사람들이 왜 그렇게 자주 망치는지 궁금한 적이 있습니까? 하신 분들이 있습니다. 이 게시물에서 우리는 검토 전문가의 행동을 설명하는 일부 불문법 컴퓨팅의.

내 첫 번째 컴퓨터는 Commodore 64였습니다. 약 30k의 RAM이 시스템용이었고 32k는 워드 프로세싱, 게임, 가족 사업 회계 및 6GB 컴퓨터에서 수행하는 거의 모든 작업에 사용되었습니다. 그것은 질문을 열어 둡니다. 현재 장비가 소프트웨어의 요구 사항을 충족합니까, 아니면 소프트웨어가 사용 가능하기 때문에 더 많은 하드웨어 리소스를 사용합니까?

공정하게 게임이 같지 않고 그래픽도 같지 않으며 영화를 보고 음악을 듣는 것은 불가능했을 것입니다. 그러나, 그렇게 생각하지 않을 수 없다. 실제로 새로운 것을 제공하지 않고 버전을 릴리스하고 점점 더 많은 리소스를 소비하는 프로그램이 있습니다.

원인은 다음과 같습니다.

자윈스키의 법칙

Netscape의 개발자인 Jamie Zawinsky는 다음과 같이 주장했습니다. 모든 프로그램은 이메일을 읽을 수 있을 때까지 기능을 통합합니다. 성공하지 못하면 그렇게 할 수 있는 다른 사람으로 대체됩니다.

그가 말했을 때 농담은 그가 원래 메일 클라이언트로 의도되지 않은 프로그램을 언급하고 있다는 것이었습니다. Google Play의 많은 앱이 작업을 수행하는 데 필요하지 않은 전화 구성 요소 및 사용자 데이터에 액세스할 수 있는 권한을 요청하고 있다는 사실이 발견되면서 더 이상 웃기지 않았습니다.

일부는 이를 사용자를 염탐하려는 시도의 일부로 해석했습니다. 하지만 단순히 할 수 있기 때문에 무언가를 하는 것은 아마도 인간의 본성일 것입니다.

소프트웨어에 적용된 피터의 원리

Lawrence Peter는 계층 구조에서 사람은 분명히 무능한 위치에 도달할 때까지 상승한다고 말한 것으로 유명해졌습니다. 그러나 그는 또한 복잡한 프로젝트에 대해 말할 시간이 있었습니다.

"복잡한 프로젝트는 자체 개발자도 이해하기에는 너무 복잡해질 것입니다."

최소한의 놀라움의 원칙

1984년 IBM Systems Journal에 발표된 이 원칙은 다음과 같습니다.

"필요한 기능이 큰 놀라움을 불러일으키면 기능을 재설계해야 할 수도 있습니다."

즉, 소프트웨어의 일부 또는 전부가 사용자가 익숙했던 것과 매우 다른 경우 가장 좋은 방법은 재설계하는 것입니다.. 이상은 달성하기 위해 노력하는 것입니다 인상적일 정도로 크지만 친숙하게 남을 만큼 작은 점진적인 개선 사용자를 위해.

유감스럽게도 Shuttleworth는 Unity를 출시할 때 이를 고려하지 않았습니다.

사이버네틱 곤충학의 법칙

컴퓨터 역사상 최초의 버그(버그)는 실존했다. 나방이 MARK II 컴퓨터의 릴레이 중 하나로 날아가 오작동을 일으켰습니다.

은유를 계속하면 사이버네틱 곤충학의 법칙은 항상 버그가 하나 더 있습니다.

그것은 모든 컴퓨터 사용자가 알고 있는 것입니다. 운영 체제를 아무리 많이 테스트해도 너무 늦었을 때 발견되는 버그가 항상 있습니다.

커니건의 법칙

Linux Adictos 저자가 검색 엔진 친화적인 방식으로 글을 쓸 수 있도록 플러그인이 설치되어 있습니다. 나는 첫날부터 그것을 싫어했다. 약간의 문학적 도피로 글을 쓰려는 시도는 즉시 빨간색 원으로 비난됩니다. 시간이 지나면서 익숙해져서 손질할 일이 거의 없었습니다.

프로그래머에게도 같은 일이 발생합니다. 많은 경우 그들은 이해하고 유지하기 쉬운 간단한 코드를 작성하는 것보다 코딩 능력을 입증하는 데 더 관심이 있습니다.

따라서 Kernighan의 법칙은 다음을 유지합니다.

“디버깅은 애초에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 가능한 한 현명하게 코드를 작성한다면 디버깅할 만큼 똑똑하지 못한 것입니다."

90/90 규칙

실생활에서 영리 프로젝트를 시작해 본 사람이라면 모든 프로젝트가 예상 수익의 절반을 만들기 위해 두 배의 시간과 예산이 소요된다는 것을 알고 있습니다.

컴퓨터 세계에는 이 법칙의 변형이 있습니다. 예를 들어 Tom Cargill은 다음과 같이 말했습니다.

“코드의 처음 90%는 개발 시간의 처음 90%를 나타냅니다. 나머지 10%의 코드가 나머지 90%의 개발 시간을 차지합니다."

명확하지 않았나요? 아마도 Hofstadter의 법칙이 도움이 될 것입니다.

"Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다."

우분투와 페도라 개발자가 알아야 할 것 같습니다. 또는 적어도 6개월마다 기억하십시오.

브룩의 법칙

오픈 소스 소프트웨어 프로젝트에는 일반적으로 두 가지 문제가 있습니다. 자금 조달 및 협력자 부족. 두 번째가 문제가 아닌 한. 브룩에 따르면:

"일정보다 늦게 실행되는 소프트웨어 프로젝트에 노동력을 추가하면 더 후퇴할 것입니다."

속도를 높여야 하는 것은 새로운 코더만이 아닙니다. 문서화해야 할 일이 더 많아지고 모든 사람을 동기화하기 위한 관료주의가 더 많아질 것이며 아마도 싸움이 있을 것입니다.

그리고 물론 우리는 친구 Parkinson과 그의 말을 잊을 수 없습니다. 얼마나 많은 빈 공간으로 시작하는지는 중요하지 않습니다. 당신은 항상 더 필요합니다. 그는 사무실 공간을 언급했지만 RAM과 디스크 공간도 마찬가지입니다.