5 유명한 프로그래밍 따옴표,설명

프로그래머가되는 것은 지속적인 학습의 삶에 자신을 등록하는 것입니다. 새로운 기능,새로운 언어,새로운 도구,새로운 프레임 워크의 샘은 결코 분출하지 않습니다. 그러나 컴퓨터 과학은 또한 시간을 테스트 한 원칙에 기반을 둔 놀라 울 정도로 전통적인 분야입니다. 객체 지향 프로그래밍,최신 하드웨어 및 인공 지능을 추가했습니다. 그러나 이러한 변화에도 불구하고 한 세대 전에 처음 표현 된 많은 통찰력은 오늘날에도 여전히 사실입니다.

이 글에서,나는 컴퓨터 과학에 대한 나의 마음에 드는 인용문의 몇 가지를 해부했습니다. 내가 설정 한 유일한 조건은 각 견적이 적어도 20 세 이상이어야한다는 것입니다. 오래된 기술이 빨리 쓸모 없게되는 동안,우리의 프로그래밍 조상의 고대 계명은 더 많은 체류 능력을 가지고 있기 때문에.

“컴퓨터 과학의 모든 문제는 다른 수준의 간접으로 해결할 수 있습니다.”-데이비드 휠러

여기에 몇 개발자가 설명하고 싶은 자주 반복 콤프 인용이다. 이 코딩에 대한 모든 무엇의 중심에 파업 때문에 그러나 그것은 하나의 내가 제일 좋아하는 프로그래밍 진리입니다.

간접적 인 생각을 시작하는 가장 쉬운 방법은 레이어를 상상하는 것입니다. 예를 들어,구성 요소를 구성 요소에 맞추어야 하는 작은 프로젝트가 있다고 가정해 보겠습니다.:

두 구성 요소 모두 표준화되어 있으므로 열어 놓고 작동 방식을 변경할 수 없습니다. 완전히 새로운 구성 요소(PlugTwoProngVariant)를 빌드 할 수는 있지만 많은 작업과 불필요한 중복입니다. 두 구성 요소에 맞는 그들 사이에 변환 어댑터-더 나은 방법은 두 조각 사이에 레이어를 추가하는 것입니다.

이제 간접 작업이 호환되지 않는 부분에 맞게 새 레이어를 추가하는 것이라면 좋지만 좁게 유용 할 것입니다. 그러나 문제를 해결한다는 아이디어는 그 주위에 구축하여 컴퓨팅의 맨 아래에서 맨 위로 뻗어있는 개념입니다. 새로운 데이터 모델을 이전 사용자 인터페이스에 맞추려고 할 때 볼 수 있습니다. 레거시 응용 프로그램을 새 웹 서비스 백엔드에 맞추려고 할 때 볼 수 있습니다. 로깅 및 캐싱과 같은 더 높은 수준의 기능을 사용하거나 메시징 및 트랜잭션과 같은 더 높은 수준의 서비스를 조정해야 할 때 볼 수 있습니다. 그리고 피라미드의 상단에,당신은 기계 학습과 같은 희박한 주제에 얻을 것이다(당신은 당신이 필요로하는 동작을 코딩 할 수없는 경우,당신을 위해 그것을 알아낼 것이다 코드의 또 다른 레이어를 작성).

많은 사람들이 코딩은 바보 같은 컴퓨터조차도 이해할 수있는 언어로 명시적인 지침을 작성하는 것이라고 말할 것입니다. 그러나 데이비드 휠러의 인용문은 더 나은 통찰력을 보여준다. 좋은 프로그래밍은 가장 일반적인 솔루션을 얻기 위해 추상화의 사다리를 등반하는 것입니다.

보너스 관련 인용구:

간접 지정은 강력하지만 복잡성에 대한 비용이 있습니다. 사람들은 매우 드물게 간접 정보에 대한 휠러의 즉각적인 후속 발언을 인용하지 않습니다:

“그러나 그것은 보통 또 다른 문제를 일으킬 것입니다.”-데이비드 휠러

그 진실은 그 이후로 프로그래머를 사업으로 유지 해왔다.

단순성

“단순성은 신뢰성을 위해 전제 조건입니다.”-에즈저 다이크스트라

현명한 프로그래머가 코드를 과도하게 복잡하게하지 말라고 경고하는 것은 없습니다. 그러나 몇몇은 네덜란드 컴퓨터 과학의 선구자 에츠 제르 다이크 스트라보다 더 명확한 복잡성의 비용을 넣어.

여기 통찰력이 있다:당신은 미래를 위한 선물로 단순함을 선택하지 않는다. 코드를 다시 사용할 수 있는 기회를 예상하거나 코드 검토에서 더 깔끔하게 보이기를 원하거나 쉽게 수정할 수 있기를 원하기 때문에 그렇게 하지 않습니다. (이러한 모든 혜택은 가치가 있지만! 단순 필수 조건이기 때문에)당신은 그것을 할. 단순성이 없으면 비즈니스를 운영하거나 데이터를 처리하기 위해 신뢰할 수있는 신뢰할 수있는 코드를 가질 수 없습니다.

다이크스트라의 요점을 받아들이려면”좋은 코드”가 무엇을 의미하는지 재정의해야 한다. 가장 짧은 코드는 아닙니다. 반드시 가장 빠른 코드는 아닙니다. 그것은 확실히 가장 영리한 코드가 아닙니다. 그것은 신뢰할 수있는 코드입니다.

보너스 관련 인용구:

코드를 단순하게 유지하는 가장 좋은 방법 중 하나는 적은 것이 더 많다는 것을 기억하는 것입니다. 다 익스트라는 우리가 명심하는 데 도움이 메트릭을 제공합니다:

“코드 줄을 세고 싶다면’생산 된 줄’이 아니라’소비 된 줄’로 간주해야합니다.'”—에즈저 다이크스트라

가독성과 재 작성에

“코드를 작성하는 것보다 코드를 읽는 것이 더 어렵습니다.”-조엘 스폴스키

언뜻 보면,소프트웨어 전설과 스택 오버 플로우 공동 제작자 조엘 스폴스키이 인용은 사실이지만 믿을 얕은 보인다. 예,코드는 밀도가 높고 간결하며 지루할 수 있습니다. 그리고 그것은 단지 다른 사람들의 코드가 아닙니다. 1 년 전부터 자신의 작품을 보면 한때 친밀하게 알고 있던 논리를 정렬 할 시간이 필요할 것입니다.

그러나 스폴스키의 통찰력은 왜곡과 함께 온다. 당신이 읽을 수없는 코드의 위험은 단지 명백한 것이 아닙니다(그것을 바꾸고 개선하는 것은 어렵습니다). 대신,더 큰 위험은 복잡한 코드가 실제보다 더 나쁜 것처럼 보인다는 것입니다. 사실,다른 사람의 이미 작성된 코드를 이해하려고 노력하는 부담은 너무 커서 스폴스키가 최악의 실수라고 부르는 것,즉 코드를 처음부터 다시 작성하기로 결정하는 유혹을받을 수 있습니다.

다시 쓰기가 시스템의 아키텍처를 향상시킬 수 없다는 것은 아닙니다. 그들은 확실히 할 수 있습니다. 그러나 이러한 개선은 큰 비용으로 제공됩니다. 그들은 단순한 코딩보다 훨씬 오래 걸리는 두 가지 활동 인 테스트 및 버그 수정시 시계를 재설정합니다. 그들은 소프트웨어 개발에서 가장 일반적인 편견 중 하나에 재생하기 때문에 다시 쓰기는 유혹:우리는 개념적으로 간단한 일을 할 수있는 노력을 과소. 프로젝트의 최종 5%가 시간의 50%를 차지하는 이유입니다. 쉬운 일은 놀라 울 정도로 시간이 많이 걸릴 수 있습니다! 그리고 이미 해결 한 문제를 해결하는 것보다 쉬운 것은 없습니다.

따라서 모든 것을 완벽하게 다시 작성하지 않으면 더 나은 해결책은 무엇입니까? 대답은 모든 개발자가 일정한 한입 크기의 리팩토링에 참여하도록하는 것입니다. 이것은 당신에게 작은,지속적인 코드 개선—최소한의 위험과 실제 보상을 제공합니다. 당신은 방법에 가독성을 향상시킬 수 있습니다.

보너스 관련 인용문:

가독성의 중요성에 대해 여전히 의심 스럽다면 마틴 파울러는 그것을 원근법으로 삼는 데 도움이됩니다:

“어떤 바보라도 컴퓨터가 이해할 수있는 코드를 작성할 수 있습니다. 좋은 프로그래머는 인간이 이해할 수있는 코드를 작성합니다.”-마틴 파울러

즉,프로그래머의 임무는 일을 작동하게하는 것이 아니라 일을 이해하도록하는 것입니다.

반복시

“자신을 반복하지 마십시오. 모든 지식은 시스템 내에서 단일의 모호하지 않은 권위있는 표현을 가져야합니다. 앤디 헌트와 데이브 토마스

모든 자존심있는 프로그래머는 반복이 많은 악의 핵심이라는 것을 알고 있습니다. 다른 장소에서 동일한 것을 작성하는 경우 추가 작업 작성,테스트 및 디버깅을 수행합니다. 더 나쁜 것은,예를 들어 코드의 한 부분이 업데이트되었지만 다른 유사한 루틴이 합의되지 않은 경우와 같이 불일치에 대한 가능성을 도입하는 것입니다. 일관성없는 프로그램은 신뢰할 수없는 프로그램이며 신뢰할 수없는 프로그램은 더 이상 실행 가능한 솔루션이 아닙니다.

을 피할 수 있었지만 코드 만이 반복이 혼란을 야기하는 유일한 장소는 아닙니다. 이 버전의 유명한”자신을 반복하지 마십시오”(건조)규칙은 불일치가 숨길 수있는 다른 장소를 충당하기 위해 중복 방지 원칙을 확장합니다. 우리는 더 이상 코드 중복에 대해 이야기하지 않습니다. 우리는 또한 시스템의 반복에 대해 이야기하고-그리고 시스템은 지식을 인코딩하는 많은 다른 방법이있다. 그들은 다음을 포함합니다:

• 코드 문
• 코드 주석
• 개발자 또는 클라이언트 문서
• 데이터 스키마(예:데이터베이스 테이블)
• 테스트 계획,워크플로 문서 및 빌드 규칙

이러한 계층은 모두 서로 겹칠 수 있습니다. 그리고 그들이 할 때,그들은 같은 현실의 다른 버전을 도입 할 위험이 있습니다. 예를 들어,설명서에서 한 가지 작업 방법을 설명하지만 응용 프로그램이 다른 방법을 따르는 경우 어떻게됩니까? 누가 진리의 소유권을 가지고 있는가? 데이터베이스 테이블이 코드의 데이터 모델과 일치하지 않으면 어떻게 됩니까? 또는 주석은 실제 구현과 일치하지 않는 알고리즘의 작동을 설명합니까? 모든 시스템에는 다른 모든 것이 파생되는 단일 권위있는 표현이 필요합니다.

덧붙여 말하자면,진실의 경쟁 버전은 소규모 프로젝트 나 잘못 설계된 코드에서만 문제가 아닙니다. 가장 좋은 예 중 하나는 대 중으로 분화 했다. 한 캠프는 사양이 공식적인 진실이라고 주장하고,브라우저가 그것을 따라 수정 될 필요가 있었다. 다른 진영은 그들이 웹 페이지를 쓸 때 그 디자이너가 마음에 있던 무엇 때문에 브라우저 동작은,사실상의 표준이라고 주장했다. 결국,진실의 브라우저 버전은 이겼다. 그 시점부터 브라우저가 허용 한 바로 가기와 수락 한 오류를 포함하여 브라우저가 한 일이었습니다.

보너스 관련 견적:

코드와 주석이 서로 모순 될 가능성은 주석이 선보다 해를 끼치는지에 대한 열띤 논쟁을 열었습니다. 극단적 인 프로그래밍의 지지자들은 열린 의혹으로 그들을 대합니다:

“코드는 결코 거짓말을하지 않습니다.”-론 제프리

하드 문제에

“컴퓨터 과학에는 캐시 무효화와 이름 지정이라는 두 가지 어려운 점이 있습니다.”-필 칼튼

언뜻 보면,이 인용은 재미 있지만 일반적인 프로그래밍 농담처럼 보인다. 어려운 소리(캐시 무효화)와 고통없는 소리(이름 지정)의 대조는 즉시 관련이 있습니다. 모든 프로그래머는 잘못된 순서로 전달 된 한 쌍의 매개 변수 또는 일관성없는 대문자 변수(자바 스크립트 감사)와 같이 터무니없이 사소한 문제를 해결하는 데 몇 시간을 투자했습니다. 인간이 일을 끝내기 위해 기계와 파트너가 필요한 한,프로그래밍은 높은 수준의 시스템 계획과 사소한 오타의 매시업이 될 것입니다.

그러나 필 칼튼의 인용문을 두 번째 살펴보면,더 많은 것을 풀 수 있습니다. 프로그래머의 삶이 작은 두통에 의해 정기적으로 파괴되기 때문에 일을 명명하는 것은 어렵지 않습니다. 또한 명명 문제는 실제로 모든 프로그래머의 가장 중요한 작업 인 소프트웨어 디자인의 가장자리이기 때문입니다. 즉,명확하고 깨끗하며 일관된 코드를 어떻게 작성합니까?

이름을 잘못 지정할 수 있는 방법이 많이 있습니다. 우리는 모두 데이터 유형의 이름을 따서 명명 된 변수를 보았습니다(myString, obj), 약어(제품 카탈로그의 경우pc),몇 가지 사소한 구현 세부 사항(swappable_name, formUserInput), 또는 심지어 아무것도 전혀(ret_value, tempArray). 변수를 포함하는 것이 아니라 그 순간에 무엇을하고 있는지에 따라 변수를 명명하는 함정에 빠지기 쉽습니다. 그리고 부울 값은 특히 까다 롭습니다—진행이 시작될 때progress이 설정 되는가,진행률 정보를 사용자 인터페이스에 표시해야 함을 나타내는가,아니면 완전히 다른 것에 플래그를 지정해야합니까?

하지만 변수 이름은 시작에 불과합니다. 클래스 이름을 지정하면 코드를 독립적 인 부분으로 나누는 방법에 대한 질문이 제기됩니다. 공용 멤버의 이름을 지정하면 응용 프로그램의 한 부분이 다른 부분과 상호 작용할 수 있는 인터페이스가 표시되는 방식이 달라집니다. 이 이름을 잠그는 것은 코드 조각이 무엇을 할 수 있는지 설명하는 것이 아니라 무엇을 할 것인지를 결정합니다.

보너스 관련 견적:

“컴퓨터 과학에는 캐시 무효화,이름 지정 및 일대일 오류라는 두 가지 어려운 점이 있습니다.”-레온 밤브릭