유닉스 철학 프로그래밍 원리
- 王林앞으로
- 2024-02-20 10:54:18483검색
1 유닉스 철학
유닉스 철학은 풍부한 경험을 바탕으로 실용성을 강조하며 전통적인 방법론이나 표준에 얽매이지 않습니다. 이 지식은 더 잠복적이고 반 본능적입니다. 유닉스 프로그래머가 개발 경험을 통해 축적한 지식은 다른 프로그래머에게도 도움이 될 수 있습니다.
(1) 각 프로그램은 하나의 작업을 완료하는 데 중점을 두고 원래 프로그램에 새로운 기능을 추가하여 복잡성이 증가하는 것을 방지하기 위해 새로운 작업이 발생할 때 다시 시작해야 합니다. (2) 프로그램의 출력이 다른 프로그램의 입력이 될 것이라고 가정하면, 다음 프로그램이 아직 알려지지 않은 경우에도 출력에 관련 없는 정보가 포함되지 않도록 해야 합니다. (3) 설계 및 작성된 소프트웨어는 가능한 한 빨리 시험 사용하고, 품질이 낮은 코드는 과감히 버리고 다시 작성한다. (4) 프로그래밍 작업의 부담을 줄이기 위해서는 비효율적인 보조 수단보다 먼저 도구를 사용해야 합니다.
2 코딩 원칙
유닉스 철학의 본질은 현자들이 말로 전달한 것뿐만 아니라 그들의 실천과 유닉스 시스템 자체의 설계에도 더 많이 반영되어 있습니다. 이 철학은 몇 가지 핵심 사항으로 요약될 수 있습니다.
소프트웨어 공학을 처음 배울 때는 이러한 원리에 대한 깊은 이해가 있어야 합니다. 대부분의 기사에서는 이러한 원칙을 장려하지만 많은 시스템에는 프로그래머가 이러한 원칙을 구현하는 것을 방해하는 실용적인 도구와 전통이 부족합니다. 잘못된 툴링, 잘못된 디자인, 과로, 중복된 코드로 인해 어려움을 겪는 경우가 많습니다.
2.1 모듈 원리: 간단한 인터페이스를 사용하여 간단한 구성 요소를 조립합니다
프로그래밍의 핵심은 복잡성을 관리하는 것입니다. 버그를 해결하는 데 개발 시간의 대부분이 소요됩니다. 사용 가능한 시스템의 성공은 재능이나 디자인 기술보다는 시행착오의 결과에 더 가깝습니다.
어셈블리 언어, 컴파일 언어, 순서도, 절차적 프로그래밍, 구조적 프로그래밍, 객체 지향 및 소프트웨어 개발 방법론이 과도하게 선전됩니다. 그러나 그들은 인간 두뇌의 처리 능력을 넘어서 프로그램의 복잡성을 증가시킵니다.
복잡한 소프트웨어를 성공적으로 개발하려면 전반적인 복잡성을 줄이고 명확한 인터페이스를 통해 간단한 모듈을 결합하는 것이 중요합니다. 이렇게 하면 문제가 특정 부분에 국한되어 전체에 영향을 주지 않고 쉽게 개선할 수 있습니다.
2.2 명확성 원칙: 명확성은 영리함보다 낫습니다
향후 유지 관리의 복잡성과 비용을 염두에 두고 코드를 작성하세요. 코드는 필요한 경우 다른 사람이나 본인이 쉽게 수정하고 유지 관리할 수 있도록 읽고 이해하기 쉬워야 합니다.
Unix 전통에서 이 원칙은 단순한 코드 주석 이상의 것에도 적용됩니다. Unix 모범 사례에서는 알고리즘과 구현을 선택할 때 향후 확장성을 고려하는 것도 강조합니다. 프로그램 성능을 약간 향상시키기 위해 기술적 복잡성과 혼란을 추가하고 싶은 유혹이 있을 수 있지만 이 접근 방식은 얻을 가치가 없습니다. 이는 복잡한 코드가 버그가 발생하기 쉬울 뿐만 아니라 나중에 읽고 유지 관리하기가 더 어려워지기 때문입니다. 반대로, 우아하고 명확한 코드는 더 안정적일 뿐만 아니라 다른 사람들이 이해하고 수정하기도 더 쉽습니다. 특히 지금으로부터 몇 년 후에 이 코드를 수정해야 하는 사람이 바로 당신일 수도 있기 때문에 이는 매우 중요합니다.
모호한 코드를 세 번 해독하려고 애쓰지 마세요. 처음에는 문제가 없을 수도 있지만 다시 재해석해야 하는 경우(처음 사용한 지 너무 오래되어 구체적인 세부 사항이 기억나지 않는 경우) 이제 코드를 주석 처리해야 합니다. 세 번째는 상대적으로 덜 고통스러울 것입니다.
2.3 조합 원칙: 디자인 시 접합 및 조합을 고려하세요
프로그램이 서로 효과적으로 통신할 수 없다면 소프트웨어는 필연적으로 복잡해지게 됩니다.
입력 및 출력 측면에서 Unix 전통은 단순하고, 텍스트적이고, 스트림 지향적이고, 장치 독립적인 형식의 사용을 강력히 옹호합니다. 클래식 Unix에서 대부분의 프로그램은 가능한 한 간단한 필터의 형태를 채택합니다. 즉, 입력 텍스트 스트림을 간단한 텍스트 스트림 출력으로 처리합니다. 일반적인 통념과는 달리 Unix 프로그래머는 그래픽 사용자 인터페이스를 싫어하기 때문이 아니라 간단한 텍스트 입력 및 출력 스트림을 사용하지 않으면 프로그램과 인터페이스하기가 극도로 어렵기 때문에 이 접근 방식을 선호합니다.
Unix의 텍스트 스트림은 객체 지향 환경에서 객체에 대한 메시지가 무엇인지 도구로 사용됩니다. 텍스트 흐름 인터페이스의 단순성은 도구의 캡슐화를 향상시킵니다. 원격 프로시저 호출과 같은 정교한 프로세스 간 통신 방법에는 너무 많은 프로세스가 포함되는 경향이 있습니다.
프로그램을 구성 가능하게 만들려면 프로그램을 서로 독립적으로 만들어야 합니다. 텍스트 스트림의 한쪽 끝에 있는 프로그램은 가능한 한 텍스트 스트림의 다른 쪽 끝에 있는 프로그램을 고려하지 않아야 합니다. 한쪽 끝의 프로그램을 다른 쪽 끝을 전혀 방해하지 않고 완전히 다른 프로그램으로 쉽게 교체할 수 있어야 합니다. GUI는 좋은 것일 수 있습니다. GUI를 만들기 전에 복잡한 대화형 프로그램과 거친 작업을 수행하는 알고리즘 프로그램을 분리하고 각 부분을 별도의 조각으로 만든 다음 간단한 명령 흐름이나 응용 프로그램을 사용할 수 있는지 생각해야 합니다. 그것들을 결합하는 프로토콜은 그것을 모두 하나로 결합합니다.
복잡한 데이터 전송 형식을 구상하기 전에 간단한 텍스트 데이터 형식을 사용할 수 있는지 현장에서 확인하는 것이 필요합니다. 약간의 형식을 파싱하는 데 드는 비용은 일반 도구를 사용하여 구성하거나 데이터 스트림을 해석합니다.
프로그램이 직렬화된 프로토콜 기반 인터페이스를 자연스럽게 사용할 수 없는 경우 올바른 Unix 디자인은 최소한 가능한 한 많은 프로그래밍 요소를 잘 정의된 API 세트로 구성하는 것입니다. 이러한 방식으로 최소한 링크를 통해 애플리케이션을 호출할 수 있으며, 다양한 작업의 필요에 따라 다양한 인터페이스를 함께 연결할 수 있습니다.
2.4 분리 원칙: 전략과 메커니즘의 분리, 인터페이스와 엔진의 분리
전략과 메커니즘은 다양한 시간 규모에 따라 변화하며, 전략은 메커니즘보다 훨씬 빠르게 변화합니다. 전략과 메커니즘을 결합하면 두 가지 부정적인 효과가 있습니다. 첫째, 전략을 경직되게 만들고 사용자 요구 변화에 적응하기 어렵게 만듭니다. 둘째, 전략의 변경으로 인해 메커니즘이 흔들릴 가능성도 있습니다. 반대로, 새로운 전략을 모색할 때 이 두 가지를 제거하는 것만으로는 메커니즘을 무너뜨리기에 충분하지 않을 수 있습니다. 또한 메커니즘에 대한 더 나은 테스트를 작성하는 것이 더 쉽습니다.
스트리핑을 달성하는 방법은 소켓 상위 계층의 전용 애플리케이션 프로토콜을 통해 협업하고 통신할 수 있는 프런트엔드와 백엔드 프로세스로 애플리케이션을 나누는 것입니다. 프론트엔드 구현 전략, 백엔드 구현 메커니즘. 단일 프로세스만 사용하는 전체 구현과 비교할 때 이러한 이중 설계는 전체 복잡성을 크게 줄이고 버그를 줄여 프로그램의 수명주기 비용을 줄일 것으로 예상됩니다.
2.5 단순성의 원칙: 디자인은 단순해야 하며 복잡성은 최대한 낮아야 합니다
다양한 측면의 압력은 종종 프로그램을 더 복잡하게 만듭니다(이로 인해 프로그램이 더 비싸지고 버그가 더 많아집니다). 압력 중 하나는 기술적 허영심에서 비롯됩니다. 프로그래머는 똑똑하고 종종 복잡한 사물과 추상적인 개념을 다루는 능력에 자부심을 느낍니다. 당연히 그렇습니다. 그러나 이 때문에 그들은 누가 가장 복잡하고 아름다운 것을 손질할 수 있는지 알아보기 위해 동료들과 경쟁하는 경우가 많습니다. 이들의 설계 능력은 구현 및 디버깅 능력을 훨씬 능가하며 그 결과 값비싼 스크랩이 발생합니다.
"복잡하게 아름다운 것들"은 모순처럼 들립니다. 유닉스 프로그래머들은 누가 "단순하고 아름다울" 수 있는지 알아보기 위해 서로 경쟁합니다. 비록 이것이 이 규칙에 암시되어 있을 뿐이지만, 여전히 공개적으로 언급하고 강조할 가치가 있습니다.
적어도 상용 소프트웨어의 세계에서는 프로젝트 요구 사항으로 인해 과도한 복잡성이 발생하는 경우가 많으며, 이러한 요구 사항은 고객 요구 사항과 소프트웨어가 실제로 제공할 수 있는 내용보다는 영업 홍보에 기반을 두는 경우가 많습니다. 거의 사용되지 않는 기능으로 판매되는 긴 기능 목록으로 인해 많은 좋은 디자인이 죽습니다. 그러면 남보다 화려해지는 길은 자신도 더욱 화려해지는 것이다. 곧, 부풀림은 업계 표준이 되었습니다. 모두가 너무 많은 버그가 있는 부풀어 오른 소프트웨어를 사용하게 되었고, 심지어 소프트웨어 개발자조차도 이를 심각하게 받아들이지 못했습니다.
이러한 함정을 피하는 유일한 방법은 단순함이 아름다움인 대체 소프트웨어 문화를 장려하는 것입니다. 이는 단순한 솔루션을 중시하고, 항상 프로그램 시스템을 함께 작동할 수 있는 작은 부분으로 분해하려고 시도하며, 너무 많은 특수 효과로 프로그램을 설탕 코팅하려는 모든 시도를 본능적으로 거부하는 엔지니어링 전통입니다.
2.6 인색의 원칙: 다른 방법이 없는 한 거대한 프로그램을 작성하지 마세요
"Big"에는 큰 크기와 높은 복잡성이라는 두 가지 의미가 있습니다. 프로그램이 클수록 유지 관리가 더 어려워집니다. 만들기 위해 많은 노력을 들인 것과 이별의 어려움은 실패할 운명이거나 최선의 해결책이 아닌 거대한 프로그램에 대한 투자의 낭비로 이어진다. 불필요한 코드와 논리를 피하고 코드를 간결하게 유지하세요.
2.7 투명성 원칙: 디자인은 검토 및 디버깅을 위해 표시되어야 합니다
디버깅은 개발 시간의 4분의 3 이상을 차지하는 경우가 많기 때문에 나중에 디버깅 작업량을 줄이려면 처음에 조금 더 작업을 수행하는 것이 좋습니다. 디버깅 작업량을 줄이는 효과적인 방법은 설계 시 투명성과 가시성을 충분히 고려하는 것입니다.
소프트웨어 시스템의 투명성이란 소프트웨어가 수행하는 작업과 수행 방법을 한눈에 볼 수 있음을 의미합니다. 가시성이란 프로그램이 내부 상태를 모니터링하고 표시할 수 있는 능력이 있어 프로그램이 잘 실행될 뿐만 아니라 어떤 방식으로 실행되는지도 볼 수 있음을 의미합니다.
설계 중에 이러한 요구 사항을 충분히 고려하면 전체 프로젝트 프로세스에 이점을 가져올 수 있습니다. 디버깅 옵션의 설정은 사후에 이루어져서는 안 되며, 프로그램이 그 정확성을 입증할 수 있을 뿐만 아니라 후발자에게 원 개발자의 문제 해결 방법을 알려줄 수 있어야 합니다. 사고 모델.
프로그램이 정확성을 입증하려면 유효한 입력과 올바른 출력 사이의 관계가 올바른지 쉽게 확인할 수 있을 만큼 간단한 입력 및 출력 형식을 사용해야 합니다. 투명성과 가시성을 위해 다른 프로그램, 특히 테스트 모니터링 도구 및 디버깅 스크립트를 쉽게 작동할 수 있도록 간단한 인터페이스를 홍보해야 합니다. WeChat 공개 계정 [임베디드 시스템]을 팔로우하세요
2.8 견고성 원칙: 견고성은 투명성과 단순성에서 비롯됩니다
소프트웨어의 견고함이란 소프트웨어가 일반적인 상황에서도 잘 실행될 수 있을 뿐만 아니라 상상 이상의 예상치 못한 상황에서도 잘 실행될 수 있음을 의미합니다.
대부분의 소프트웨어는 충돌을 견딜 수 없으며 모든 것을 고려하기가 너무 복잡하고 어렵기 때문에 많은 문제를 안고 있습니다. 프로그램의 논리를 제대로 이해하지 못하면 그것이 맞는지 확신할 수 없고, 문제가 발생해도 고칠 수 없습니다. 프로그램을 강력하게 만드는 방법은 프로그램의 내부 논리를 이해하기 쉽게 만드는 것입니다. 이를 수행하는 두 가지 주요 방법은 투명성과 단순성입니다.
견고함 측면에서는 극한의 입력을 견딜 수 있는 능력을 염두에 두고 설계하는 것도 중요합니다. 비정상적인 입력의 경우 소프트웨어의 견고성을 보장하는 매우 중요한 전략은 코드에서 특수한 경우를 피하는 것입니다. 버그는 일반적으로 특수한 경우를 처리하는 코드와 다양한 특수 상황의 대화형 작업을 처리하는 코드에 숨겨져 있습니다. .
소프트웨어의 투명성은 무슨 일이 일어나고 있는지 한눈에 볼 수 있다는 것을 의미합니다. "무슨 일이 일어나고 있는지"가 복잡하지 않다면, 즉 머리를 쓰지 않고도 가능한 모든 시나리오를 추론할 수 있다면 프로그램은 간단합니다. 프로그램이 더 간단하고 투명할수록 프로그램은 더 강력해집니다.
모듈화(간단한 코드, 간단한 인터페이스)는 보다 간결한 목적을 달성하기 위해 프로그램을 구성하는 방법입니다.
2.9 표현 원리: 지식을 데이터에 중첩하여 간단하고 견고한 논리 달성
데이터는 프로그래밍 로직보다 제어하기 쉽습니다. 설계에서는 코드의 복잡성이 데이터에 적극적으로 전달되어야 합니다.
이러한 고려 사항은 Unix 고유의 것은 아니지만 많은 Unix 코드가 이에 영향을 받은 것으로 보입니다. 특히 포인터 사용을 제어하는 C 언어의 기능은 커널 위의 다양한 코딩 수준에서 참조 구조의 동적 수정을 용이하게 합니다. 구조에서 매우 간단한 포인터 작업으로 수행할 수 있는 작업은 다른 언어에서는 더 복잡한 절차가 필요한 경우가 많습니다.
데이터 기반 프로그래밍을 할 때는 코드와 코드가 작동하는 데이터 구조를 명확하게 구분해야 합니다. 이런 식으로 프로그램의 로직을 변경할 때는 코드 대신 데이터 구조만 편집하면 됩니다. 데이터 기반 프로그래밍은 데이터 구성에 중점을 둔 또 다른 스타일인 객체 지향 프로그래밍과 혼동되기도 합니다. 그들 사이에는 적어도 두 가지 차이점이 있습니다. 첫째, 데이터 기반 프로그래밍에서 데이터는 객체의 상태일 뿐만 아니라 실제로 프로그램의 제어 흐름을 정의합니다. 가능한 한 덜 고정된 코드.
2.10 인기 원칙: 인터페이스 디자인에서 참신함을 피하세요
이는 "최소 놀라움의 원칙"이라고도 알려져 있습니다. 가장 사용하기 쉬운 프로그램은 사용자가 최소한의 새로운 것을 배워야 하는 프로그램이며 사용자의 기존 지식과 가장 잘 맞는 프로그램입니다. 그러므로 인터페이스 디자인은 부당한 참신함이나 영리함을 피해야 합니다.
계산기를 프로그래밍하는 경우 '+'는 항상 덧셈을 의미해야 합니다. 인터페이스를 디자인할 때 사용자에게 가장 친숙할 것 같은 동일한 기능 인터페이스 및 유사한 애플리케이션에 따라 모델링해 보십시오.
대상 고객에 초점을 맞추세요. 최종 사용자일 수도 있고, 다른 프로그래머일 수도 있고, 시스템 관리자일 수도 있습니다. 가장 놀라운 것은 이러한 다양한 그룹의 사람들에게 다른 것을 의미합니다. 학습 곡선을 완화하는 데에는 그럴 만한 이유가 있는 기존 규칙에 중점을 둡니다.
최소 혁신 원칙의 또 다른 측면은 유사해 보이지만 실제로는 약간 다른 것을 피하는 것입니다. 명백한 유사성은 종종 사람들이 잘못된 가정을 하게 만들기 때문에 이는 매우 위험할 수 있습니다. 그래서 거의 똑같아 보이는 것보다는 확실히 다른 점이 있는 것이 더 좋습니다.
2.11 침묵의 원칙: 프로그램에 할 말이 없으면 침묵을 유지하세요
예의바른 프로그램은 조용하게 작동해야 하며 절대로 잡담을 해서는 안 됩니다. 침묵은 황금입니다. 이 원칙은 Unix가 탄생했을 때 모든 중복 출력 라인이 사용자의 소중한 시간을 심각하게 소비한다는 사실에서 비롯되었습니다. 이러한 상황은 더 이상 존재하지 않지만, 모든 것을 단순하게 유지하는 훌륭한 전통은 오늘날까지 계속되고 있습니다.
단순성은 Unix 프로그램의 핵심 스타일입니다. 프로그램의 출력이 다른 프로그램의 입력이 되면 필요한 데이터를 쉽게 골라낼 수 있습니다. 인간의 관점에서 볼 때 중요한 정보는 프로그램의 내부 동작에 대한 긴 정보와 섞여서는 안 됩니다. 표시된 정보가 모두 중요하다면 굳이 찾을 필요가 없습니다. 잘 설계된 프로그램은 사용자의 주의를 제한적이고 귀중한 자원으로 간주하여 불필요한 정보로 사용자를 방해하지 않도록 필요한 경우에만 사용하도록 요구합니다.
2.12 해결 원칙: 예외 발생 시 즉시 종료하고 충분한 오류 정보를 제공합니다
오류가 발생할 경우 소프트웨어는 정상 작동 시와 마찬가지로 동일한 투명한 논리를 가져야 합니다. 물론 최선의 시나리오는 소프트웨어가 비정상적인 작동에 적응하고 대처할 수 있다는 것입니다. 최악의 시나리오는 수정 조치가 명백히 성공하지 못하더라도 충돌 위험을 조용히 묻어두어 훨씬 나중에야 드러나는 것입니다. .
따라서 소프트웨어는 다양한 잘못된 입력과 자체 실행 오류를 최대한 침착하게 처리해야 합니다. 이를 수행할 수 없는 경우 가능한 한 오류를 쉽게 진단할 수 있는 방식으로 프로그램을 종료해야 합니다.
"관용있게 받고 주의해서 보내세요." 입력 데이터가 표준화되지 않더라도 잘 설계된 프로그램은 그 의미를 이해하고 가능한 한 다른 프로그램과 협력하려고 노력할 것입니다. 그런 다음 큰 소리로 축소되거나 프로그램에 대한 엄격하고 깨끗하며 올바른 데이터를 출력합니다. 작업 체인의 다음 링크.
디자인할 때 관용을 고려해야 하며, 표준의 단점을 보완하기 위해 지나치게 관대하게 구현을 사용하지 마십시오. 그렇지 않으면 조심하지 않으면 추악하게 죽을 것입니다.
2.13 경제 원칙: 프로그래머에게 1초를 투자하는 것보다 기계에 1포인트를 투자하는 것이 더 좋습니다
유닉스 초기 미니컴퓨터 시대에도 이 관점은 여전히 상당히 급진적이었습니다. 기술이 발전함에 따라 개발 회사와 대부분의 사용자는 값싼 컴퓨터를 얻을 수 있었기 때문에 이 원칙의 합리성은 말할 필요도 없습니다.
품질 보장을 전제로 컴퓨터 리소스를 사용하여 작업을 완료하고 프로그래머의 부담을 줄이십시오. 프로그래머의 시간을 크게 절약하는 또 다른 방법은 기계에 더 낮은 수준의 프로그래밍 작업을 수행하는 방법을 가르치는 것입니다. WeChat 공개 계정 [임베디드 시스템]을 팔로우하세요
2.14 생성 원리: 손으로 찢지 말고, 프로그램을 생성하여 프로그램을 작성해 보세요
우리 모두는 인간이 힘든 세부 작업을 수행하는 데 형편없다는 것을 알고 있습니다. 프로그램의 모든 수동 작업은 오류와 지연의 온상이며, 프로그램 생성 코드는 거의 항상 손으로 작성한 코드보다 저렴하고 신뢰할 수 있습니다.
코드 생성기의 경우, 손글씨가 필요한 반복적이고 마비된 고급 언어 코드를 기계 코드처럼 대량 생산할 수 있습니다. 코드 생성기를 사용하면 추상화 수준이 높아질 때, 즉 생성기의 선언문이 생성된 코드보다 간단하고 생성된 코드가 힘든 수동 처리의 필요성을 제거할 때 효과가 있습니다. 코드 생성기는 오류가 발생하기 쉬운 세부 작업을 자동화하기 위해 Unix에서 광범위하게 사용됩니다.
2.15 최적화 원칙: 조각하기 전에 프로토타입을 만들고, 달리기 전에 걷는 법을 배우세요
프로토타입 디자인의 가장 기본적인 원칙은 "지금 실현 가능한 기능의 90%, 결코 실현할 수 없는 기능의 100%보다 낫다"입니다. 프로토타이핑을 잘하면 작은 이익을 위해 너무 많은 시간을 투자하는 것을 피할 수 있습니다.
"사소한 이익의 효율성 향상을 고려해서는 안 됩니다. 성급한 최적화는 모든 악의 근원입니다." 병목 현상이 어디에 있는지 모르고 성급하게 최적화하는 것은 무작위 기능을 추가하는 것보다 디자인을 손상시키는 유일한 실수일 수 있습니다. 변형된 코드부터 정리되지 않은 데이터 레이아웃까지, 투명성과 단순성을 희생하면서 일방적으로 속도를 추구하면 수많은 버그가 발생하고 수백만 명의 시간이 소모됩니다. 이러한 작은 이점은 후속 문제 해결 노력을 상쇄하지 못합니다.
성급한 로컬 최적화는 실제로 전역 최적화를 방해하여 전반적인 성능을 저하시킬 수 있습니다. 전체 디자인에 더 큰 이점을 가져올 수 있는 수정 작업은 종종 조기 로컬 최적화로 인해 방해를 받아 성능이 저하되고 코드가 지나치게 복잡한 제품이 생성됩니다.
Unix 세계에는 프로토타입을 먼저 만든 다음 개선하는 매우 명확하고 오랜 전통이 있습니다. 최적화하기 전에 먼저 걸을 수 있는지 확인한 다음 달리는 방법을 배우십시오. 이것을 다른 문화에서 효과적으로 확장합니다. 먼저 달리고, 바로 옆에 있고, 가장 나중에 빠르게 가십시오.
이 모든 단어의 본질은 실제로 같은 것을 의미합니다. 먼저 최적화되지 않고 느리게 실행되며 메모리를 소비하지만 올바른 구현을 설계한 다음 성능을 최소화하면서 더 큰 결과를 얻을 수 있는 구현을 체계적으로 조정합니다. 개선되었습니다.
2.16 다양성의 원칙: 소위 "유일한 방법"이라는 주장을 믿지 마십시오
최고의 소프트웨어라도 디자이너의 상상력에 따라 제한되는 경우가 많습니다. 모든 것을 최적화할 만큼 똑똑한 사람은 없으며 소프트웨어의 가능한 모든 용도를 예측할 수도 없습니다.
소프트웨어 설계 및 구현과 관련하여 Unix 전통의 한 가지 좋은 점은 소위 "모든 경우에 적용되는 단일 접근 방식"을 결코 믿지 않는다는 것입니다. Unix는 다양한 언어의 광범위한 사용, 확장 가능한 개방형 시스템 및 사용자 정의 메커니즘을 추구하며 다양하고 우수한 디자인 아이디어를 흡수하고 활용하며 자체 디자인 방법과 스타일을 지속적으로 개선합니다.
2.17 확장 원칙: 미래를 염두에 두고 디자인하세요. 미래는 항상 예상보다 빠릅니다
데이터 형식 및 코드 확장을 위한 여지를 남겨두십시오. 그렇지 않으면 원본과의 호환성을 유지하면서 변경할 수 없기 때문에 원래의 현명하지 못한 선택에 얽매이는 경우가 많습니다.
프로토콜이나 파일 형식을 설계할 때 확장 가능하도록 충분히 자체 설명적으로 만드세요. 버전 번호를 포함하거나, 형식을 읽는 코드를 손상시키지 않고 언제든지 새 버전을 삽입하고 이전 버전을 교체할 수 있는 방식으로 구성된 독립적이고 자체 설명적인 문을 사용하세요. Unix 경험에 따르면 데이터 배포 자체 설명을 만드는 오버헤드를 약간 늘리면 전체를 파괴하지 않고 확장할 수 있으며 작은 노력으로 수천 배의 보상을 받을 수 있습니다.
코드를 설계할 때 미래의 개발자가 전체 아키텍처를 해체하거나 재구축하지 않고도 새로운 기능을 추가할 수 있도록 잘 구성되어야 합니다. 이 원칙은 사용하지 않는 기능을 마음대로 추가할 수 있다는 의미가 아니라, 나중에 기능을 더 쉽게 추가할 수 있도록 코드를 작성할 때 향후 요구 사항을 고려해야 한다는 의미입니다. 프로그램 인터페이스는 유연해야 합니다. 코드에 "확장...필요한 경우..."라는 주석을 추가하세요. 앞으로 작성한 코드를 사용하고 유지 관리하는 사람들을 위해 좋은 일을 해야 할 것입니다. 미래에 자신이 코드를 작성하고 미래를 염두에 두고 설계하면 절약되는 것이 바로 자신의 에너지일 수 있습니다.
3 Unix 철학 적용
이러한 철학적 원칙은 결코 모호하고 일반적인 것이 아닙니다. 유닉스 세계에서 이러한 원칙은 실천에서 직접 나오며 특정 규칙을 형성합니다.
유닉스 철학을 바탕으로 끊임없이 우수성을 추구해야 합니다. 소프트웨어 디자인은 지혜, 창의성, 열정이 필요한 기술입니다. 그렇지 않으면 단순하고 구식인 디자인과 구현을 넘어서지 못할 것입니다. 생각해야 할 때 프로그래밍에 돌진하게 될 것이고, 복잡함을 무자비하게 잘라내고 단순화해야 할 때 문제를 복잡하게 만들 것이며, 왜 그런가에 대해 불평하게 될 것입니다. 코드가 너무 비대해지고 디버깅하기가 어렵습니다.
Unix 철학을 잘 활용하려면 무모하게 행동하지 말고 더 많은 기술을 사용하고 필요할 때 사용할 수 있도록 에너지를 절약하세요. 도구를 활용하고 모든 것을 최대한 자동화하세요.
4 태도
소프트웨어 설계 및 구현은 즐거움이 가득한 예술이자 수준 높은 게임입니다. 왜 다른 것 대신 소프트웨어 디자인에 참여해야 할까요? 어쩌면 지금은 단지 돈을 벌거나 시간을 보내기 위한 것일 수도 있고, 한때 소프트웨어 디자인이 세상을 바꾸고 열정을 가질 가치가 있다고 생각했을 수도 있습니다.
위 내용은 유닉스 철학 프로그래밍 원리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!