사람들은 어떻게 코드를 작성하는 것이 매우 복잡하고 읽기 어려운가요? [닫은]

SQLite 소스 코드를 읽는 것은 IMO 임무가 불가능합니다. 그러나 다른 코드에서 다운로드, 컴파일 및 사용할 수있는 매우 복잡한 소프트웨어 (완전히 내장 된 내장 데이터베이스)이며, 지속적으로 업데이트됩니다.

사람들이 그렇게 복잡하고 읽기 어려운 코드를 작성하고 유지 관리하는 방법은 무엇입니까?

Complex와 Complex는 큰 차이가 있습니다. 다음 링크가 요약되어 있습니다. :)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

좀 더 개인적인 견해로는 100 만 줄 이상의 코드 기반으로 작업합니다. 나는 라인 1에서 현재 상태로왔다. 당신이 더 많은 farmilar (코드에서 더 오래 읽을수록) 더 쉽게됩니다. 모든 줄의 기능을 말할 수는 없지만 주어진 작업이나 버그를 찾기 시작했다고 말할 수 있습니다. 그것은 자연스럽게 온다.

이야기의 도덕은 프로그래밍 세계의 다른 것들과 마찬가지로 시간이 걸린다는 것입니다. SQLite를보고 그것을 알고 이해한다면, 당신은 농담입니다. 모든 것이 어떻게 작동하는지 알아내는 데 시간이 걸릴 것입니다. 좋은 코드와 나쁜 코드의 차이점은 프로세스가 얼마나 오래 걸리는가입니다.

마지막으로, 일부 개발자는 코드베이스로 뛰어 들어 알아낼 수 없습니다. 많은 사람들이 코드베이스의 크기 나 아키텍처에 압도 ​​당할 것입니다. 다른 사람들은 뛰어 들어도 아무런 문제가 없습니다. 그것은 모두 개발자의 강점에 달려 있습니다.

특정 SQLite의 경우 개발 및 유지 관리에 사용하기로 선택한 주요 도구는 자동화 된 테스트입니다. 그들은 테스트 스위트에서 100 % 커버리지 (문장 커버리지가 아닌 브랜치 커버리지)를 자랑스럽게 생각합니다. 그들에 따르면, 그것은 세계에서 가장 테스트 된 소프트웨어 제품 중 하나입니다. 그래서 그들은 자신이 추가하거나 변경 한 것이 회귀를 일으키는 것을 즉시 알고 있으며 그 결과로 두려움없이 발전 할 수 있습니다.

http://sqlite.org/testing.html

엄청나게 큰 숫자- 생산 코드 보다 약 640 배 많은 테스트 코드가 있습니다.

편집 :이 질문은 죽음에서 제기되었습니다, 그것은 보인다! 그리고 1 년이 조금 지난 후에도 같은 페이지에 프로덕션보다 1177 배 많은 테스트 코드 라인이 있다고합니다!

• 기능은 시간이 지남에 따라 진화합니다.
  • 새로운 기능은 새로운 고객 요구 사항에 의해 주도됩니다.
  • 구식 코드는 구식 코드를 깨지 않고 미래에 아직 구현할 기능을 추가 할 수있는 방식으로 작성되었습니다.
• 도메인 전문가 (이 경우 데이터베이스는 컴퓨터 과학에서 잘 알려진 도메인입니다.)
• 커뮤니티 피드백
  • 버그
• 가파른 학습 곡선은 잘 준비되고 인내하는 데 문제가되지 않았습니다. 편안해지기까지 6 개월, 1 년 또는 그 이상이 걸릴 수 있으며, 이것이 일부 사람들이 참을 수있는 것입니다.
• 상업적 동기 부여. 금전적 인 지원이 없으면 극소수의 사람들 만 가파른 학습 곡선에 시간과 에너지를 투자 할 수 있습니다.

프로젝트를 유지하기 위해 전체 프로젝트를 자세히 이해하지 않아도됩니다 . 일반적으로 크고 복잡한 소프트웨어를 사용하는 사람들은 자신이 돌보는 특정 "영역"을 갖게되며 나머지 시스템에 대한 '통과'지식 만 갖습니다.

SQLite는 실제로 "대규모 소프트웨어 프로젝트"의 규모에 상대적으로 작은하지만 윈도우 운영 체제 같은 것을 보면, 당신은 사람들이 누구거야 단지 커널에, 사람들이 누가 일을 단지 사람들 누구 쉘에 일을 바로 작업 인터넷 익스플로러, 사람에 불과 창 관리자 작업은 "쉘"작동 등 등 누군가 모자의 드롭에있는 커널의 버그를 고칠 수 될 수 없습니다.

이러한 프로젝트가 시간이 지남에 따라 발전한다는 이점도 있습니다. 항상 이러한 복잡한 프로젝트를 시작하지는 않았습니다. 이는 새로운 개발자가 경험이 많은 개발자에 의해 "훈련"될 수 있음을 의미합니다.

대규모 개발자 팀에 합류하면 프로젝트의 특정 측면 (버그 또는 새로운 기능 일 수 있음)이 제공되며 처음 몇 번의 반복에 대해 "버디"인 다른 개발자를 갖게됩니다. 친구는 작업중인 지역을 잘 이해하고 길을 찾는 데 도움이됩니다.

SQLite와 같은 오픈 소스 프로젝트의 경우 기존 개발자가 새로운 개발자를 "훈련"하려는 동기가 없기 때문에 실제로 조금 더 어려워집니다. 그래서 당신은 당신이 조금 더 자신을 찾을 수 있습니다. 그러나 개발자 포럼이나 메일 링리스트에 대한 도움말을 찾을 수 있습니다 (예 : "그러한 기능을 구현하고 싶습니다"또는 "버그 XYZ를 찾았습니다. 어디에서 시작합니까?"와 같은 질문을 게시하면됩니다.) 어떤 형태의 도움.

읽기 어려운 프로젝트와 복잡한 프로젝트에는 차이가 있습니다. 사람이 프로젝트가 작성된 언어 또는 프로젝트의 도메인을 깊이 이해하지 못한다고해서 코드가 잘못 작성된 것은 아닙니다.

나의 충고:

• 프로젝트의 언어를 이해해야합니다. 언어를 아는 것만으로는 충분하지 않습니다.
• 코드를 작성하기 전에 도메인에 대한 모든 세부 사항을 학습하십시오.

나에게 SQLite는 복잡하고 복잡하지 않다. 이 프로젝트의 영역은 광범위한 개념에 대한 깊은 이해가 필요합니다.

다른 답변에서 언급되지 않은 한 가지는 "자연스럽게 그들에게 온다"입니다. 대부분의 사람들은 좋은 코드를 작성하려고하지만 나쁜 코드를 작성하도록 조정되었습니다. 내가 만난 프로그래머 중 일부는 당연히 LINEAR 사상가이며 때로는 복잡한 해결책을 제시합니다. 그러한 사람들의 대부분은 자신이 배우는 책을 읽거나 학습 할 때 시간을 소비하지 않습니다.

사람들이 그렇게 복잡하고 읽기 어려운 코드를 작성하고 유지 관리하는 방법은 무엇입니까?

이들이 원래 코더이고 계속 유지한다면 "복잡하고 읽기 어려운"것으로 보지 않습니다. 그들은 스스로 작성했기 때문에 아마도 "간단하고 읽기 쉬운"것으로 볼 수 있습니다.

모든 코드는 그것을 이해하는 데 시간이 걸립니다. 일부는 다른 것보다 오래 걸리는 것입니다. :)

인내, 인내심 및 체계적인 접근 방식이 있다면 코드 기반으로 머리를 감쌀 수 있지만 주로 인내심은 :-)

항상 같은 방식으로 작업을 수행하면 관리가 훨씬 쉬워집니다. SQLite 코드를 모르지만 여러 프로젝트가있는 환경에서 일하고 있습니다. 비즈니스 사례 (eq 로직)를 이해하는 것 외에도 모든 것이 기본적으로 모든 곳에서 동일한 방식으로 수행되므로 (데이터베이스 액세스 등) 다른 프로젝트에서 작업하기가 비교적 쉽습니다. 긴 텍스트 요약 : 코딩 지침-적절한 방식으로 삶과 그러한 코드를 훨씬 쉽게 만듭니다. 이는 SQLite 코더의 도우미 중 하나 일 수 있습니다.

• 소프트웨어의 최초 작성자이고 10 년 이상 소프트웨어를 사용해 왔으며 천재라면 모든 것을 이해하는 것이 가능할 수 있습니다. SQLite 나 Linux 커널과 같은 복잡한 소프트웨어는 실제로 다른 사람이 기여 했음에도 불구하고 완벽하게 깊이 이해하는 독창적 인 작가를 보유하고 있습니다.
• 소프트웨어 아키텍처가 정상이라면 (높은 응집성, 낮은 결합), 모든 것을 이해하는 것이 유용한 추가 및 수정을위한 전제 조건이 아닙니다.
• RDBMS 또는 OS를 이해하는 것은 다소 특별한 경우이며 기본 CS 원칙을 깊이 이해해야합니다. "일반적인"소프트웨어 응용 프로그램에서는 그렇지 않습니다.

그들은 간단한 방법으로 글을 쓰려고 시도하지만 단순한 방법은 아닙니다.

시간이 많이 걸리더라도 이해하기 쉽고 빠르게 읽을 수 있도록 최대한 단순하게하십시오.

구현되는 알고리즘은 구현을위한 코드가 얼마나 간단한 지에 대한 하한을 설정합니다. 구현 될 알고리즘에 대한 추상적 인 설명이 매우 복잡하고 서로 다른 톤의 데이터를 서로 연결해야하는 경우, 누가 알고리즘을 작성하든 상관없이 상기 알고리즘을 구현하는 코드는 간단 할 수 없습니다.

다시 말해서, 때때로 난해한 코드를 작성하는 한 가지 이유는 구현하려는 알고리즘이 주어지면 선택의 여지가 없기 때문입니다.