프로그래머가 때때로 자신의 코드에 대해 100 % 명확성을 갖지 않는 것이 정상입니까? [닫은]

나는 전문 프로그래머가 아니기 때문에 이것이 이유 일 수도 있지만, 최근에 만든 체스 게임과 같은 복잡한 코드를 만들 때마다 올바른 코드를 작성하여 프로그램을 작동시킬 수 있음을 알게되었습니다. 나는 나중에 또는 몇 초 후에 그것을 발견하지만!-나는 종종 멈추고 생각해야합니다. 어떻게 작동합니까?

그뿐만 아니라 코드에 대해 생각하지 않는 경향이 있으며 대신 입력합니다. 예를 들어, 체스 게임에서 움직임을 처리하기 위해 5 차원 배열을 사용하기로 결정했는데 너무 많은 의식적인 생각없이이 작업을 수행 할 수 있다는 것을 알았습니다. 그러나 멈추고 그것을 읽었을 때, 나는 전체 5 차원 개념을 머리로 쓰는 것이 어려웠으며, 내가 한 일과 코드 자체가 어떻게 작동하는지 완전히 이해하는 데 몇 분이 걸렸습니다.

프로그래머가 복잡한 코드를 작성할 때 절반의 시간을하는 일을 이해하지 못하는 것이 정상입니까?

아니요, 정상이 아닙니다 ¹ . 적어도 좋은 프로그래머에게는 정상이 아닙니다. 누군가가 프로그래밍을 배우는 것은 정상일 것 입니다 .

소프트웨어 작성은 작동 할 때까지 코드 줄을 묶는 것이 아닙니다. 코드를 이해하기 쉽도록 의식적으로 작업해야합니다. 내가 한 번 존경하는 프로그래머 는 "코드가 쓰여진 것보다 더 많이 읽혀진다" 고 말했다 . 그것이 완전히 명백해야하지만, 그가 나에게 말할 때까지 내가 알지 못했던 것은 사실이었습니다. 대부분의 코드는 한 번만 작성되고 한 번 또는 두 번 더 다시 작성되지만 소프트웨어 수명 기간 동안 코드를 자주 읽게됩니다.

코드를 작성한 후 몇 분 동안 이해하기 어려운 코드를 찾으면 코드가 너무 복잡하다는 신호입니다. 코드 추가를 중단하고 더 나은 방법을 찾으십시오. 예를 들어, 5 차원 배열은 거의 좋은 생각이 아닙니다. 정말 똑똑한 프로그래머라도 복잡한 데이터 구조를 이해하는 데 어려움을 겪고 있습니다.

코드 가독성에 대해 말 해준 같은 프로그래머도 "데이터 구조를 보여 주면 코드 작동 방식을 알려줄 수있다"고 말했다 . 좋은 코드는 깨끗하고 이해하기 쉬운 데이터 구조로 시작한다는 의미입니다. 데이터를 올바르게 설계하면 코드는 거의 부차적 인 문제입니다. 분명히 소프트웨어는 단순한 데이터 이상의 것이지만 데이터로 시작 하기 때문에이 문장은 다소 과장된 것 입니다. 따라서 깨끗하고 이해하기 쉬운 데이터 구조를 만드는 작업을 수행하면 코드를 이해하기가 훨씬 쉬워집니다.

¹ 물론 가장 똑똑한 프로그래머조차 이해하기 어려운 코드가 있습니다. 일부 문제는 본질적으로 복잡합니다. 그러나 대다수의 프로그래머가 작성한 대부분의 코드는 이러한 유형의 코드가 아니라고 말하고 싶습니다.

이것에는 두 가지 종류가 있습니다 : 1.) 혼란 2.) 행복한 무지

첫 번째는 나쁘고 시간과 경험으로 사라질 수 있습니다.

두 번째는 프로젝트가 커지면 좋은 것입니다. 코드로 작업 할 수 있도록 모든 구현 세부 사항을 기억해야하는 경우 문제가 있습니다 ( "정보 숨기기"참조).

모든 개발자는 코드의 작동 방식을 잊어 버리므로 다른 새로운 개발자가 자신에게 알려지지 않은 프로그램의 다른 부분을 손상시키지 않고 코드를 이해하고 유지할 수있는 방식으로 코드를 작성합니다.

따라서 "알지 못하는 것"은 실제로 소프트웨어 개발에서 일정합니다. 이는 소프트웨어를 관리하는 방법인지 여부입니다.

사람들이 인정하는 것보다 더 일반적이라고 말하고 싶습니다. 브라이언 커니 건조차도 언급했다.

디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 최대한 영리하게 작성하면 정의에 따라 코드를 디버깅하기에 충분히 똑똑하지 않습니다.

매장으로 운전할 때 페달과 스티어링 휠의 위치를 ​​세부적으로 조정합니다. 이것은 현재 매우 쉽습니다. 이제 그 조정 내용을 종이에 기록하여 상점에 지시가 필요한 친구에게 주었다고 상상해보십시오.

마찬가지로, 우리는 한 수준의 추상화에서 코드를 작성하는 것을 좋아하지만 여러 상위 계층의 추상화에서 코드를 읽는 것을 좋아합니다. 우리가 선호하는 코드 작성 및 읽기 방법은 상충됩니다. 즉, 코드를 쉽게 읽을 수있게하는 것은 일반적으로 다른 기술을 가진 별도의 의식적인 단계입니다.

좋은 프로그래머를 만드는 것은 방금 쓴 것을 읽는 데 어려움이 있고 그 시점에서 추상화를 만듭니다. 더 나은 프로그래머는 매번 더 까다로워 여러 번 수행합니다. 결국 숙련 된 프로그래머는 프로세스를 따라 더 시작하지만 방금 쓴 내용을 읽은 후에도 여전히 개선의 여지를 볼 수 있습니다.

나는 이것이 경험과 함께 사라질 것이라고 생각합니다.

복잡한 시스템을 작성하는 경우 미래와 다른 사람이 모두 이해할 수있는 깨끗하고 유지 관리 가능한 코드를 작성할 수 있어야합니다. 본질적으로, 지금하고있는 일은 확장 할 수 없습니다.

6 개월 전에 작성한 코드를보고 "도대체 무슨 일이 일어나고 있습니까?" 더 코드.

출처 : 결코 5 차원 배열을 사용하지 않았습니다 :)

"정상"은 매우 주관적이므로 나는 매우 일반적이지만 피해야합니다.

"좋은 코드"의 특징 중 하나 (명백한 것이 있다고 들었습니다)는 명확성입니다. 근본적인 문제가 허용하는 한 분명해야합니다. 문제가 복잡하면 코드도 복잡 할 것이지만, 그건 고유 반대로, 복잡한 사고 (내가 처음에이 구별 들어 복잡성 리치 키스 마크 야의 이야기 ) 어긋나 도입하거나 적절한 도구, 패턴, 기술을 사용하지 않는 및 관행.

명확성의 부족이있을 때 경우가 있습니다 허용 당신은 당신이 한 마케팅 캠페인이 간다 마지막 것입니다 알고있는 프로모션 현장을 작성하는 경우 문제가 예를 들어, 매우 복잡한없는 경우에도. 이는 유지 관리 할 수없는 폐기 코드입니다. 다른 (대부분의 경우) 해당 코드를 유지 관리하는 데 많은 비용이 들기 때문에 허용되지 않습니다. 그러나 일반적입니다.

관련 :

• 이해가 재 작성을 의미 할 때 -코드 이해 문제에 관한 기사.
• 효과적인 ML -ML / OCaml 사이에서 "리더"(예 : 관리자)를위한 코드 작성 방법에 대한 긴 이야기 : "라이터보다 선호하는 리더" 어떤 언어를 사용하든 상관없이 시청하는 것이 좋습니다.

나는 그것이 정상이라고 생각하지 않지만 언급 한 체스 프로그램과 같은 매우 복잡한 프로그램의 경우 확실히 가능하다고 생각합니다.

몇 년 전, 나는 대학원에 다닐 때 (그래서 나는 여전히 큰 프로그램을 작성하는 데 상대적으로 경험이 없었습니다), 첫 번째 실제 컴파일러를 썼습니다. 파싱은 간단했지만 4 개의 다른 마이크로 프로세서 명령어 세트를 대상으로해야했습니다. 컴파일러를 자체 언어로 작성하려고했기 때문에 먼저 필자가 꼭 필요한 언어의 기능 만 사용하고 어셈블리 언어로 첫 번째 코드 생성기를 작성하고 언어 하위 집합에 대해 올바른 코드를 생성했는지 테스트했습니다. 그런 다음 컴파일러를 사용하여 그때부터 컴파일하고 나머지 기능을 추가하고 컴파일러 자체에서도 사용할 수있었습니다.

그런 다음 각 마이크로 프로세서에 대한 백엔드 코드 생성기를 작성하고 모두 올바른 코드를 생성하는지 테스트했지만 수정하는 동안 최적화되지 않았습니다. 그런 다음 각 코드 생성기에 대한 최적화 프로그램을 작성했습니다.

모든 최적화를 추가 한 후 코드 생성기의 출력을 테스트 할 때 컴파일러가 생성 한 코드에 자주 놀랐습니다. 손으로 직접 코드를 작성하는 방식이 아니었지만 정확하고 간결했습니다.

코드 생성기가 수행 한 코드 중 일부를 생성 한 방법이 명확하지 않은 경우, 직접 로직을 살펴 보려고했지만 방금 포기한 시간이있었습니다. 많은 추적 출력을 추가했다면 그것을 따라갈 수 있었지만 생성 된 코드가 만족 스럽기 때문에 귀찮지 않았으며 다른 프로젝트를 진행해야했습니다.

여기에 괜찮은 답변이 많이 있습니다.

나는 이것에 몇 가지 걸릴 수 있습니다.

하나는 코드가 작동하는 이유를 이해하지 못하면 a) 아마도 작동하지 않는 것 같습니다 (아마도 작동하는 것처럼 보일 것입니다. ) b) 문제 도메인을 충분히 이해할 수 없었습니다. 코딩을 시작했거나 시작하기 전에 문제 도메인을 더 작고 단순화 된 단위로 분류하지 않았습니다.

또 다른 하나는 실제 키가 코드에서 상식 패턴과 규칙을 사용하는 것입니다. 그것은 하나의 작은 게시물이 다룰 수있는 것보다 훨씬 더 큰 주제입니다. 그러나 "Code Complete"및 "Writing Solid Code"와 같은 오래된 대기 모드를 포함하여 주제에 관한 좋은 문헌을 찾으십시오.

구현 세부 사항이 변경되었습니다. 유일한 실제 상수는 코드의 기능적 목표입니다. 둘 이상의 함수를 작성하면 시간이 지남에 따라 세부적이고 구체적인 구현 세부 정보를 잊게됩니다. 그러나 조각을 만들 때 조각이 어떻게 작동하는지 확실히 이해해야하며 전체 다이어그램을 그리고 조각이 함께 작동하는 방식을 이해할 수 있어야합니다.

패턴을 사용하고 상식 규칙을 따르는 경우 코드를 다시 볼 때 특정 구현 세부 사항을 선택하는 것이 훨씬 쉽습니다. 또는 전에 코드를 본 적이없는 사람이 처음으로 코드를 보았을 때. 또한 시간이 지남에 따라 이러한 규칙과 패턴을 따르면 구현 세부 사항이 규칙과 패턴 자체에서 두드러지며 이는 코드를 이해하기 쉽게 만드는 또 다른 요소입니다.

소프트웨어로 다루는 대부분의 문제는 본질적으로 복잡합니다. 소프트웨어 디자인은 복잡성을 관리하는 연습입니다.

나는 그것을 보통 이라고 부르지는 않지만 분명히 일어날 수 있습니다. 문제의 코드를 작성한 직후에 문제가 발생하면 코드가 불필요하게 복잡하고 단순화되거나 쉽게 산만해질 수 있습니다. :)

그러나 코드를 정리하고 다른 프로젝트에 집중 한 후 몇 주, 몇 달 또는 몇 년 후에 코드를 다시 가져와도 코드를 다시 알아 내야한다는 것은 그리 놀라운 일이 아닙니다.

그러나 이것에 대해 할 수있는 일이 있습니다. 당신이 말한 바에 따르면, 코드를 작성할 때 코드에 대해 충분히 생각하지 않아서 미래의 자기 자신이 진행중인 일을 이해하기가 어려워지고 있습니다. 이 지식을 유리하게 활용하십시오 : 이것은 체계적이고 체계적으로 문서화되고 이해하기 쉬운 코드를 생성하기위한 최고의 동기입니다. 코드의 품질을 관리하지 않으면 어떤 일이 발생하는지 직접 경험할 수 있습니다. 그것을 알면 장기적으로 더 나은 프로그래머가 될 것입니다. 소프트웨어 프로젝트에 대해 공동 작업 할 때 동료는 이해할 수있는 코드를 작성해 주셔서 감사합니다. 그리고 코드의 결함률도 향상됩니다.