소프트웨어를 처음부터 읽고 이해하는 것보다 소프트웨어를 작성하는 것이 더 쉬운가요? [닫은]

저와 제 친구는 어제 대형 C ++ 소프트웨어를 작성하는 것과 새로운 모집 자로 이해하는 것의 차이점에 대해 논의했습니다.

소프트웨어가 한 번에 한 줄씩 수행되고이 프로세스가 우리 (인간)가 물건을 배우고 다른 것 위에 물건을 만드는 방식과 유사하기 때문에 실제로 큰 소프트웨어를 작성하는 것이 소프트웨어를 읽고 이해하는 것보다 쉽습니다. (코드를 단계별로 진행하는 것이 도움이되지만 여러 클래스 / 소스 파일을 함께 기억해야합니다. 멀티 스레드 코드는 무엇을 위해 작성했는지조차 모릅니다. 멀티 스레드 코드는 Malus 포인트를 추가합니다)?

처음에는 이상하게 들리지만 조금 생각한 후에 합리적으로 보였습니다.

내 경험을 바탕으로 가장 쉬운 것부터 가장 어려운 것까지 순서대로 다음 활동을 평가했습니다.

1. 좋은 코드 읽기
2. 잘못된 코드 작성
3. 좋은 코드 작성
4. 잘못된 코드 읽기

위의 순위는 두 가지 결론으로 ​​이어집니다

1. 나쁜 코드를 읽는 것보다 코드를 작성하는 것이 더 쉽지만 자신의 코드를 작성하는 것보다 좋은 코드를 읽는 것이 더 쉽습니다
2. 나쁜 코드를 작성하는 것은 좋은 코드를 작성하는 것보다 쉽지만, 나쁜 코드를 작성하면 나쁜 코드를 읽을 수 있습니다. 특히 잘못된 코드는 작성된 것보다 많이 읽습니다.

물론 좋은 코드와 나쁜 코드는 광범위한 일반화입니다. 좋은 코드에 대한 자세한 내용은 Code Complete 및 Clean Code 를 권장 합니다.

이 질문은 거짓 합의에 호소합니다. http://en.wikipedia.org/wiki/False-consensus_effect

사람들마다 정보를 다르게 배우고 흡수합니다. 청각 학습자, 시각 학습자 및 운동 학습자와 유사합니다. 어떤 사람들에게는 코드를 읽는 것이 더 쉽고 어떤 사람들에게는 코드를 만드는 것이 더 쉽습니다. 나를 위해, 그것은 후자입니다. 우리 팀의 다른 사람들에게는 전직입니다. 나는 일종의 합의 나 다수를 찾는 것이 유용하다고 생각하지 않습니다. 뇌가 어떻게 정보를 흡수하고 배우는지 이해하고 그 지식을 사용하여 나 자신을 개선하고 다른 사람들을 받아들이는 법을 배우는 것이 좋습니다.

큰 C ++ 소프트웨어를 작성하고이를 새로운 모집 자로 이해하는 것의 차이점

이것은 소프트웨어 읽기와 쓰기의 차이점과 다릅니다. 프로젝트를 처음 접했을 때 (특히 회사를 처음 접할 때) 코드가하는 것보다 더 많은 것을 배울 수 있습니다. 이해 왜 코드가 종종 사업이 프로젝트가 조직의 나머지 부분에 어떤 관련이 있는지 작동 방법에 대한 이해를 필요로 무엇을한다. 요컨대, 배경 지식의 이점없이 코드를 읽는 것은 코드가 작동하는 컨텍스트를 완전히 이해할 때 코드를 읽는 것보다 느리고 더 어려운 작업입니다.

이 인 A의 새로운 코드를 작성하는 사이에 차이 그린 필드 프로젝트 와 읽기, 기존 코드를 수정,하지만 나는 하나가 반드시라고 언급하지 않았다 쉽게 단지 다른, 다른 것보다. 새로운 것을 만들 때 이미 존재하는 코드로 코드를 작성하는 방법에 대해 걱정할 필요는 없지만 프로젝트를 확장 가능하고 미래에 유용하게 사용할 수 있도록 프로젝트를 확장 할 수 있는지 걱정할 필요는 없습니다. . 기존 프로젝트에서 작업 할 때는 이미있는 것을 종종 안내서로 사용할 수 있지만 먼저 무엇이 있는지 이해해야합니다.

"신규 모집"으로서는 일반적으로 기존 프로젝트에서 작업하는 것이 좋습니다. 비즈니스의 작동 방식, 다양한 프로젝트의 협력 방식, 코딩 표준 및 실습, 심지어는 알지 못하는 모든 것을 배우는 데 도움이되기 때문입니다. (특히) 개선 될 수있는 것.

흥미로운 질문이지만, 나는 그것을 만드는 것보다 읽고 이해하기가 더 편한쪽으로 기울어지는 경향이 있습니다.

당신이 베테랑하고 노련한 프로그래머라면, 코드를 읽고 "그래, 좋은 선택, 확인, 오, 나는 Y 대신 X를했을 수도 있습니다"등으로 갈 것입니다. 당신은 수정하거나 조정할 수 있습니다. 처음부터 다시 쓰는 시간을 엄청나게 절약하십시오 (이유가없는 한).

만약 당신이 새로운 프로그래머라면, "당신은 당신이 모르는 것을 모른다", 그래서 당신은 모든 작은 것들을 발명 / 학습해야 할 것이고, 아마도 당신은 약간의 비 효율성을 가질 것입니다. 암호. 그러나 언어에 대한 이해가 높아질 것입니다.

그러나 두 경우 모두 처음부터 완전히 작성하는 것보다 코드를 읽고 읽는 것이 더 쉬울 것입니다.

대부분의 프로그래머는 다른 사람들이 작성한 코드에 비해 자신이 작성한 코드를 이해하기가 더 쉽다는 것을 알게됩니다. 이것은 여러분이 언급 한 라인 별 학습뿐만 아니라 개별적인 스타일과 재능의 문제 때문입니다. 그래서 많은 바퀴 재발 명이 발생합니다.

그러나 그것은 나무의 관점입니다. 포리스트 뷰는 처음부터 코드를 작성하는 것보다 코드를 읽는 것이 훨씬 쉽다는 것입니다. 예를 들어, 새로운 워드 프로세서를 처음부터 작성하는 것이 더 쉬워 지거나 기존 코드 기반을 개선하여 충분히 개선 할 수 있습니까?

코드를 읽기 시작하면 코드를보다 쉽게 ​​읽을 수있는 독창적 인 방법을 생각할 수 있습니다. 처음에는 코드를 추적하면서 토지의 위치를 ​​알아 내려고 시도하며 때로는 원하는 방식에 완전히 타협하는 아키텍처를 사용합니다. 그러나 실제로 큰 코드 기반의 경우에도 해당 응용 프로그램을 만드는 데 이미 투자 한 수십만 시간에 비해 40-80 시간이 소요됩니다.

소프트웨어를 작성하는 사람은 거의 항상 프로그램을 작성하는 동안 논리 및 사고 과정을 알고 있기 때문에 프로그램을 가장 잘 이해하게됩니다.

코드 작성이 이해의 용이성 측면에서 코드를 읽는 것과 비교할 수 있다고 생각하지 않습니다. 한편으로는 단순히 소프트웨어를 작성하면 각 코드 섹션, 사용 된 라이브러리 등과 관련된 컨텍스트에 대한 지식으로 인해 특정 소프트웨어를 더 잘 이해할 수 있습니다. 그러나 다른 사람이 작성한 코드를 읽는 것은 이해하기 어려울 수 있습니다. 실제 소프트웨어이지만 언어를 이해한다는 관점에서 사용하지 않는 라이브러리를 사용하는 새로운 방법이나 사용 방법에 대한 통찰력을 제공하여 삶의 코드 작성이 더 쉬워 질 수 있습니다.

빌드 지식의 관점에서, 코드 읽기와 코드 쓰기는 서로 밀접하게 연결되어 있으며 여러 방법으로 서로를 구축한다고 생각합니다. 코드 작성 경험을 통해 다른 코드를 쉽게 이해할 수 있으며, 코드를 읽으면 새로운 논리 개념, 라이브러리 사용 등을 통해 코드를 작성하기가 더 쉬워집니다.

이것은 개인적으로 자명 한 것으로 느껴졌지만 프로그래밍 인구 전체를 위해 그것이 확실하다는 것을 결코 확신하지 못했습니다. 예를 들어, 나는 문서를 읽지 않고 다른 사람들의 코드를 행복하게 선택하여 자신의 코드처럼 이해할 수있는 매우 재능있는 코더를 알고 있습니다.

이것은 질문으로 이어진다 : 이것이 문제가 되는가?

코드를 읽는 중이라면 코드를 다시 쓰지 않고 변경할 가능성이 있습니다. 다시 작성하더라도 새로운 언어 / 버전으로 작성했을 가능성이 높으므로 반드시 동일한 방식으로 코드를 작성하지 않아도됩니다. 내가하고있는 요점은 항상 모든 코드를 항상 이해할 필요는 없다는 것입니다.

이 모든 것이 사실이며, BDD와 같은 새로운 개발 방법론 은 코드가 단순히 기계를 구동하는 수단이 아니라 코드에서 비즈니스 로직을 명확하게하는 것이 중요하다는 것을 인식합니다. 물론이 개념은 새로운 것이 아닙니다.이 개념은 Donald Knuth의 주요 작업 인 Literate Programming 이후에 있었습니다.

나는 StMotorSpark의 대답에 다음과 같이 덧붙
입니다. 예 : 예 또는 아니오 질문이 될 수없는 많은 요인에 달려 있습니다.

• 기존 코드가 잘 문서화되고 잘 작성되어 있거나 어떤 의미 나 의견이없는 스파게티처럼 보입니까?
• 해결 방법을 찾는 데 시간이 오래 걸리는 매우 드문 상황의 작은 앱입니까, 더 크지 만 간단한 앱입니까?
• 기타