좋은 프로그래머에 대한 토발즈의 인용문 [닫기]

실수로 나는 Linus Torvalds의 다음 인용문을 우연히 발견했습니다.

"나쁜 프로그래머는 코드에 대해 걱정한다. 좋은 프로그래머는 데이터 구조와 그 관계에 대해 걱정한다."

나는 지난 며칠 동안 그것에 대해 생각했지만 여전히 혼란스러워 (아마도 좋은 징조가 아닐 수도 있음), 다음을 논의하고 싶었습니다.

• 이것에 대한 어떤 해석이 가능합니까?
• 무엇으로부터 적용 / 학습 할 수 있습니까?

Torvalds가 그 직전에 말한 것을 고려하는 것이 도움이 될 수 있습니다.

git은 실제로 안정적이고 합리적으로 문서화 된 데이터 구조를 가진 단순한 디자인을 가지고 있습니다. 사실, 나는 데이터를 중심으로 코드를 설계하는 데 큰 반대 의견을 제시하고 있으며, 이것이 git이 상당히 성공한 이유 중 하나라고 생각합니다. […] 사실, 그 차이는 나쁜 프로그래머와 좋은 사람의 관계는 코드 나 데이터 구조가 더 중요한지 여부입니다.

그가 말한 것은 훌륭한 데이터 구조는 코드를 설계하고 유지하기가 매우 쉬운 반면, 최상의 코드는 가난한 데이터 구조를 보완 할 수 없다는 것입니다.

git 예제가 궁금하다면 많은 버전 제어 시스템이 새로운 기능을 지원하기 위해 데이터 형식을 상대적으로 정기적으로 변경합니다. 새 기능을 사용하기 위해 업그레이드 할 때 데이터베이스를 변환하기 위해 일종의 도구를 실행해야하는 경우가 종종 있습니다.

예를 들어, DVCS가 처음 보급되었을 때 많은 사람들이 중앙 집중식 버전 제어보다 훨씬 통합 된 분산 모델의 병합을 알아낼 수 없었습니다. 대답은 전혀 효과가 없습니다. 분산 데이터 구조 가 전혀 작동하기를 희망하기 위해 훨씬 더 좋아야한다는 것입니다. 중앙 집중식 병합 알고리즘은 그 이후에 따라 잡았다 고 생각하지만 오래된 데이터 구조는 사용할 수있는 알고리즘의 종류를 제한하고 새로운 데이터 구조는 기존 코드를 많이 파괴했기 때문에 꽤 오랜 시간이 걸렸습니다.

반대로 git의 기능이 폭발적으로 증가했지만 기본 데이터 구조는 거의 변경되지 않았습니다. 먼저 데이터 구조에 대해 걱정하면 코드가 자연스럽게 깨끗해집니다.

알고리즘 + 데이터 구조 = 프로그램

코드는 알고리즘과 데이터 구조 를 표현 하는 방법 일뿐 입니다.

이 인용문은 "유닉스 프로그래밍의 기술"의 규칙 중 하나 인 Linux의 제작자 인 Torvalds의 강점 중 하나에 매우 익숙합니다. 이 책은 온라인에 있습니다

이 책에는 토발즈의 말에 대한 다음 인용문이 있습니다.

표현의 규칙 : 지식을 데이터로 접어 프로그램 논리가 어리 석고 강력해질 수 있습니다.

가장 간단한 절차 적 논리조차도 인간이 확인하기는 어렵지만, 매우 복잡한 데이터 구조는 모델링하고 추론하기가 상당히 쉽습니다. 이를 확인하기 위해 50 개 노드 포인터 트리 다이어그램의 표현력과 설명력을 50 개 라인 프로그램의 플로우 차트와 비교하십시오. 또는 변환 표를 표현하는 배열 이니셜 라이저와 동등한 switch 문을 비교하십시오. 투명성과 선명도의 차이는 극적입니다. Rob Pike의 규칙 5를 참조하십시오.

데이터는 프로그램 로직보다 다루기 쉽다. 데이터 구조의 복잡성과 코드의 복잡성 중에서 선택할 수있는 것을 선택하면 전자를 선택하십시오. 자세히 : 설계를 발전시킬 때 코드에서 데이터로 복잡성을 전환하는 방법을 적극적으로 찾아야합니다.

유닉스 커뮤니티는 이러한 통찰력을 얻지 못했지만 많은 유닉스 코드가 그 영향을 나타냅니다. 특히 포인터 조작에있어 C 언어의 시설은 커널부터 모든 코딩 수준에 역동적으로 수정 된 참조 구조를 사용하도록 권장했다. 그러한 구조에서 간단한 포인터 추적은 종종 다른 언어로 구현할 때보다 정교한 절차를 구현해야하는 의무를 수행합니다.

코드는 쉽다. 복잡한 코드의 논리이다.

코드에 대해 걱정하는 경우 아직 기본 사항을 얻지 못하고 복잡한 구조 (예 : 데이터 구조 및 관계)에서 손실 될 가능성이 있습니다.

Morons의 답변 을 조금 확장하기 위해 코드의 특정 내용 (구문 및 구조 / 레이아웃)을 이해하는 것이 우리가 그것을 수행 할 수있는 도구를 만들 수있을 정도로 쉽다는 아이디어입니다. 컴파일러는 코드를 작동하는 프로그램 / 라이브러리로 만들기 위해 코드에 대해 알아야 할 모든 것을 이해할 수 있습니다. 그러나 컴파일러는 실제로 프로그래머 의 문제 를 해결할 수 없습니다 .

인수를 한 단계 더 발전 시켜서 "하지만 우리는 코드를 생성하는 프로그램이 있습니다"라고 말할 수 있지만, 생성하는 코드는 거의 항상 수동으로 구성된 일종의 입력을 기반으로합니다.

따라서 코드에 도달하기 위해 어떤 경로를 사용하든 구성 또는 다른 입력을 통해 도구를 통해 코드를 생성하거나 처음부터 코드를 작성하는 경우 중요한 코드가 아닙니다. 중요한 것은 해당 코드를 얻는 데 필요한 모든 부분을 비판적으로 생각하는 것입니다. Linus의 세계에서는 주로 데이터 구조와 관계가 있지만 다른 영역에서는 다른 부분 일 수 있습니다. 그러나이 맥락에서 Linus는 "코드를 작성할 수 있다면 상관하지 않습니다. 제가 다루고있는 문제를 해결할 수있는 것들을 이해할 수있을 것입니다"라고 말합니다.

리누스는 이것을 의미합니다 :

플로차트 [코드]를 보여주고 테이블 [스키마]을 숨기십시오. 표 [스키마]를 보여 주시면 일반적으로 플로차트 [코드]가 필요하지 않습니다.

-프레드 브룩스, "신화적인 남자의 달", 9 장.

그는 전반적인 고급 디자인 (데이터 구조와 그 관계)이 구현 세부 사항 (코드)보다 훨씬 중요하다고 말합니다. 시스템의 세부 사항에만 집중할 수있는 시스템보다 시스템을 설계 할 수있는 프로그래머를 소중하게 생각합니다.

둘 다 중요하지만 큰 그림을 얻고 다른 방법보다 세부 사항에 문제가있는 것이 일반적으로 훨씬 낫다는 데 동의합니다. 이것은 큰 함수를 작은 함수로 나누는 것에 대해 내가 표현하려고하는 것과 밀접한 관련이 있습니다 .

글쎄, 난 당신이 모든 것에 대해 걱정해야하기 때문에 전적으로 동의 할 수 없습니다. 그리고 그 문제에 대해 프로그래밍에 대해 좋아하는 것 중 하나는 나노초에 대한 생각에서 몇 달에 대한 생각으로 빠르게 되돌아가는 다른 추상화 및 크기 수준을 통한 스위치입니다.

그러나 높은 것이 더 중요합니다.

잘못된 행동을 일으키는 몇 줄의 문제에 결함이 있다면 해결하기가 어렵지 않을 것입니다. 성능이 저하되면 문제가되지 않습니다.

하위 시스템에서 데이터 구조 선택에 결함이 있으면 잘못된 동작이 발생하며 훨씬 더 큰 문제이며 해결하기가 더 어렵습니다. 성능이 저조한 경우 경쟁사보다 상당히 심각하거나 견딜 수있는 수준이 될 수 있습니다.

응용 프로그램에서 가장 중요한 데이터 구조 간의 관계에 결함이있어서 잘못된 행동을 유발하는 경우 내 앞에서 대규모 재 설계를했습니다. 성능이 저조한 경우, 잘못 작동하면 거의 나빠질 수 있습니다.

그리고 어렵게하는 낮은 수준의 문제를 발견하는 무슨 수 있습니다 (낮은 수준의 버그를 수정하는 것은 일반적으로 쉽게, 어려울 수를 찾는 것).

하위 수준의 항목 이 중요하고 나머지 중요성은 종종 심각하게 과소 평가되지만 큰 항목에 비해 창백합니다.

코드를 아는 사람은 "나무"를 보게됩니다. 그러나 데이터 구조를 이해하는 사람은 "포리스트"를 보게됩니다. 따라서 좋은 프로그래머는 코드보다는 데이터 구조에 더 집중할 것입니다.

데이터의 흐름을 아는 것이 모두 중요합니다. 흐름을 알기 위해서는 좋은 데이터 구조를 설계해야합니다.

20 년 전으로 돌아 가면 SmallTalk, C ++ 또는 Java를 사용하는 객체 지향 접근 방식의 가장 큰 장점 중 하나였습니다. 적어도 내가 C ++에서 배운 것이기 때문에 큰 피치는 클래스와 메소드를 디자인 한 다음 다른 모든 것이 제자리에 들어가는 것입니다.

Linus는 의심 할 여지없이 광범위한 용어로 이야기했지만, 잘못 설계된 데이터 구조는 종종 추가적인 코드 재 작업을 필요로하므로 다른 문제가 발생할 수 있습니다.

무엇으로부터 적용 / 학습 할 수 있습니까?

내가 지난 몇 주 동안의 경험. 앞서 논의한 내용은 "무엇을 배웠습니까?"라는 질문에 대한 답을 명확하게했습니다.

나는 코드를 다시 작성하고 "구조, 구조 ..."라고 말한 결과를 반영하여 이러한 극적인 차이가 발생했습니다. 이제는 모든 차이를 만든 것이 데이터 구조라는 것을 알았 습니다. 그리고 나는 모든 것을 의미 합니다 .

• 원래 배달을 테스트하자 비즈니스 분석가는 작동하지 않는다고 말했습니다. 우리는하지만, 우리가 (이하 "한 달에 추가"의미했다 "삼십일 추가"고 말했다 일 변경되지 않는 결과 날짜를). 불연속 년, 월, 일을 추가하십시오. 예를 들어 18 개월 동안 540 일이 아닙니다.

• 수정 : 데이터 구조에서 단일 정수를 여러 정수를 포함하는 클래스로 바꾸고, 구성 변경은 하나의 방법으로 제한되었습니다. 실제 날짜 산술 문을 변경하십시오.

지불

• 새로운 구현에는 더 많은 기능이 있었지만 알고리즘 코드는 더 짧고 명확했습니다.

코드 동작 / 결과 수정 :

• 알고리즘이 아닌 데이터 구조를 변경했습니다.
• 코드의 어느 곳에서도 제어 로직이 건드리지 않았습니다.
• API가 변경되지 않았습니다.
• 데이터 구조 팩토리 클래스는 전혀 변경되지 않았습니다.

나는 백만 개의 무작위적이고 화려한 책을 가진 아름답게 만들어진 도서관에서 매우 영리한 사서 팀을 상상하고 싶습니다. 그것은 어리석은 일입니다.

Linus에 더 동의 할 수 없습니다. 데이터에 중점을두면 주어진 문제에 대한 간단하고 유연한 솔루션을 크게 추출하는 데 도움이됩니다. Git 자체는 입증 된 예입니다. 수년간의 개발에서 지원 된 많은 기능을 제공하는 핵심 데이터 구조는 거의 변하지 않습니다. 마법이다! --2c

나는 이것이 많은 영역을 보았다.

비즈니스 분석에 대해 생각해보십시오 ... Colgate와 같은 소비자 제품 회사에서 마케팅을 지원하는 가장 좋은 방법을 분석한다고 가정 해 봅시다. 멋진 창이나 최신 기술로 시작하면 비즈니스의 데이터 요구를 먼저 생각하는 것처럼 비즈니스를 돕지 않고 나중에 프리젠 테이션에 대해 걱정하지 않아도됩니다. 데이터 모델은 프리젠 테이션 소프트웨어보다 오래 지속됩니다.

웹 페이지를 고려하십시오. 먼저 HTML로 보여주고 싶은 것에 대해 생각하고 스타일 (CSS)과 스크립팅 (도구 선택)에 대해 걱정하는 것이 훨씬 좋습니다.

이것은 코딩도 중요하지 않다는 것은 아닙니다. 결국 필요한 것을 얻으려면 프로그래밍 기술이 필요합니다. 데이터가 기초입니다. 빈약 한 데이터 모델은 지나치게 복잡하거나 생각하지 않은 비즈니스 모델을 반영합니다.

데이터베이스 스키마에 새 열이나 테이블을 추가하는 것보다 새로운 함수를 작성하고 기존 함수를 훨씬 자주 업데이트하는 것을 발견했습니다. 이것은 잘 설계된 모든 시스템에 해당됩니다. 코드를 변경해야 할 때마다 스키마를 변경해야하는 경우 개발자에게 매우 나쁜 신호입니다.

코드 품질 표시기 = [코드 변경] / [데이터베이스 스키마 변경]

"너의 플로우 차트를 보여주고 당신의 테이블을 숨기면, 나는 계속 미스테리하게 될 것이다. 당신의 테이블을 보여 줘라. 그러면 나는 일반적으로 플로우 차트가 필요하지 않을 것이다. 그들은 분명 할 것이다." (프레드 브룩스)

이 아이디어는 다양한 유형의 프로그래밍에서 다양한 해석을하는 것처럼 보입니다. 시스템 개발에도 적용되며 엔터프라이즈 개발에도 적용됩니다. 예를 들어, 도메인 중심 설계에서 도메인에 대한 초점의 급격한 전환은 데이터 구조 및 관계에 대한 초점과 매우 유사하다고 주장 할 수 있습니다.

이에 대한 나의 해석은 다음과 같습니다. 코드를 사용하여 데이터 구조를 작성하므로 후자에 초점을 두어야합니다. 다리를 만드는 것과 같습니다. 매력적으로 보이는 것이 아니라 견고한 구조를 설계해야합니다. 잘 작성된 데이터 구조와 브리지는 효율적인 디자인의 결과로 좋아 보인다.