실수로 나는 Linus Torvalds의 다음 인용문을 우연히 발견했습니다.
“나쁜 프로그래머는 코드에 대해 걱정한다. 좋은 프로그래머는 데이터 구조와 그 관계에 대해 걱정한다.”
나는 지난 며칠 동안 그것에 대해 생각했지만 여전히 혼란스러워 (아마도 좋은 징조가 아닐 수도 있음), 다음을 논의하고 싶었습니다.
- 이것에 대한 어떤 해석이 가능합니까?
- 무엇으로부터 적용 / 학습 할 수 있습니까?
답변
Torvalds가 그 직전에 말한 것을 고려하는 것이 도움이 될 수 있습니다.
git은 실제로 안정적이고 합리적으로 문서화 된 데이터 구조를 가진 단순한 디자인을 가지고 있습니다. 사실, 나는 데이터를 중심으로 코드를 설계하는 데 큰 반대 의견을 제시하고 있으며, 이것이 git이 상당히 성공한 이유 중 하나라고 생각합니다. […] 사실, 그 차이는 나쁜 프로그래머와 좋은 사람의 관계는 코드 나 데이터 구조가 더 중요한지 여부입니다.
그가 말한 것은 훌륭한 데이터 구조는 코드를 설계하고 유지하기가 매우 쉬운 반면, 최상의 코드는 가난한 데이터 구조를 보완 할 수 없다는 것입니다.
git 예제가 궁금하다면 많은 버전 제어 시스템이 새로운 기능을 지원하기 위해 데이터 형식을 상대적으로 정기적으로 변경합니다. 새 기능을 사용하기 위해 업그레이드 할 때 데이터베이스를 변환하기 위해 일종의 도구를 실행해야하는 경우가 종종 있습니다.
예를 들어, DVCS가 처음 보급되었을 때 많은 사람들이 중앙 집중식 버전 제어보다 훨씬 통합 된 분산 모델의 병합을 알아낼 수 없었습니다. 대답은 전혀 효과가 없습니다. 분산 데이터 구조 가 전혀 작동하기를 희망하기 위해 훨씬 더 좋아야한다는 것입니다. 중앙 집중식 병합 알고리즘은 그 이후에 따라 잡았다 고 생각하지만 오래된 데이터 구조는 사용할 수있는 알고리즘의 종류를 제한하고 새로운 데이터 구조는 기존 코드를 많이 파괴했기 때문에 꽤 오랜 시간이 걸렸습니다.
반대로 git의 기능이 폭발적으로 증가했지만 기본 데이터 구조는 거의 변경되지 않았습니다. 먼저 데이터 구조에 대해 걱정하면 코드가 자연스럽게 깨끗해집니다.
답변
코드는 알고리즘과 데이터 구조 를 표현 하는 방법 일뿐 입니다.
답변
이 인용문은 “유닉스 프로그래밍의 기술”의 규칙 중 하나 인 Linux의 제작자 인 Torvalds의 강점 중 하나에 매우 익숙합니다. 이 책은 온라인에 있습니다
이 책에는 토발즈의 말에 대한 다음 인용문이 있습니다.
표현의 규칙 : 지식을 데이터로 접어 프로그램 논리가 어리 석고 강력해질 수 있습니다.
가장 간단한 절차 적 논리조차도 인간이 확인하기는 어렵지만, 매우 복잡한 데이터 구조는 모델링하고 추론하기가 상당히 쉽습니다. 이를 확인하기 위해 50 개 노드 포인터 트리 다이어그램의 표현력과 설명력을 50 개 라인 프로그램의 플로우 차트와 비교하십시오. 또는 변환 표를 표현하는 배열 이니셜 라이저와 동등한 switch 문을 비교하십시오. 투명성과 선명도의 차이는 극적입니다. Rob Pike의 규칙 5를 참조하십시오.
데이터는 프로그램 로직보다 다루기 쉽다. 데이터 구조의 복잡성과 코드의 복잡성 중에서 선택할 수있는 것을 선택하면 전자를 선택하십시오. 자세히 : 설계를 발전시킬 때 코드에서 데이터로 복잡성을 전환하는 방법을 적극적으로 찾아야합니다.
유닉스 커뮤니티는 이러한 통찰력을 얻지 못했지만 많은 유닉스 코드가 그 영향을 나타냅니다. 특히 포인터 조작에있어 C 언어의 시설은 커널부터 모든 코딩 수준에 역동적으로 수정 된 참조 구조를 사용하도록 권장했다. 그러한 구조에서 간단한 포인터 추적은 종종 다른 언어로 구현할 때보다 정교한 절차를 구현해야하는 의무를 수행합니다.
답변
코드는 쉽다. 복잡한 코드의 논리이다.
코드에 대해 걱정하는 경우 아직 기본 사항을 얻지 못하고 복잡한 구조 (예 : 데이터 구조 및 관계)에서 손실 될 가능성이 있습니다.
답변
Morons의 답변 을 조금 확장하기 위해 코드의 특정 내용 (구문 및 구조 / 레이아웃)을 이해하는 것이 우리가 그것을 수행 할 수있는 도구를 만들 수있을 정도로 쉽다는 아이디어입니다. 컴파일러는 코드를 작동하는 프로그램 / 라이브러리로 만들기 위해 코드에 대해 알아야 할 모든 것을 이해할 수 있습니다. 그러나 컴파일러는 실제로 프로그래머 의 문제 를 해결할 수 없습니다 .
인수를 한 단계 더 발전 시켜서 “하지만 우리는 코드를 생성하는 프로그램이 있습니다”라고 말할 수 있지만, 생성하는 코드는 거의 항상 수동으로 구성된 일종의 입력을 기반으로합니다.
따라서 코드에 도달하기 위해 어떤 경로를 사용하든 구성 또는 다른 입력을 통해 도구를 통해 코드를 생성하거나 처음부터 코드를 작성하는 경우 중요한 코드가 아닙니다. 중요한 것은 해당 코드를 얻는 데 필요한 모든 부분을 비판적으로 생각하는 것입니다. Linus의 세계에서는 주로 데이터 구조와 관계가 있지만 다른 영역에서는 다른 부분 일 수 있습니다. 그러나이 맥락에서 Linus는 “코드를 작성할 수 있다면 상관하지 않습니다. 제가 다루고있는 문제를 해결할 수있는 것들을 이해할 수있을 것입니다”라고 말합니다.
답변
리누스는 이것을 의미합니다 :
플로차트 [코드]를 보여주고 테이블 [스키마]을 숨기십시오. 표 [스키마]를 보여 주시면 일반적으로 플로차트 [코드]가 필요하지 않습니다.
-프레드 브룩스, “신화적인 남자의 달”, 9 장.
답변
그는 전반적인 고급 디자인 (데이터 구조와 그 관계)이 구현 세부 사항 (코드)보다 훨씬 중요하다고 말합니다. 시스템의 세부 사항에만 집중할 수있는 시스템보다 시스템을 설계 할 수있는 프로그래머를 소중하게 생각합니다.
둘 다 중요하지만 큰 그림을 얻고 다른 방법보다 세부 사항에 문제가있는 것이 일반적으로 훨씬 낫다는 데 동의합니다. 이것은 큰 함수를 작은 함수로 나누는 것에 대해 내가 표현하려고하는 것과 밀접한 관련이 있습니다 .