큰 코드베이스를 이해하기 쉽게 만드는 방법


104

비교적 큰 프로젝트를 개발하고 있다고 가정하십시오. 이미 Doxygen으로 모든 클래스와 함수를 문서화했지만 각 소스 코드 파일에 "프로그래머의 노트"를 넣는 아이디어가있었습니다.

이것 뒤에 숨겨진 아이디어는 평신도의 용어 로 특정 계급의 작동 방식 을 설명하는 것입니다 ( 대부분의 주석이하는 이유 뿐만 아니라 ). 다시 말해, 동료 프로그래머들에게 수업이 어떻게 진행되는지에 대한 다른 견해를 제공하는 것입니다.

예를 들면 다음과 같습니다.

/*
 * PROGRAMMER'S NOTES:
 *
 * As stated in the documentation, the GamepadManager class 
 * reads joystick joystick input using SDL and 'parses' SDL events to
 * Qt signals.
 *
 * Most of the code here is about goofing around the joystick mappings.
 * We want to avoid having different joystick behaviours between
 * operating systems to have a more integrated user experience, since
 * we don't want team members to have a bad surprise while
 * driving their robots with different laptops.
 *
 * Unfortunately, we cannot use SDL's GamepadAPI because the robots
 * are interested in getting the button/axes numbers, not the "A" or
 * "X" button.
 *
 * To get around this issue, we created a INI file for the most common 
 * controllers that maps each joystick button/axis to the "standard" 
 * buttons and axes used by most teams. 
 *
 * We choose to use INI files because we can safely use QSettings
 * to read its values and we don't have to worry about having to use
 * third-party tools to read other formats.
 */

이것은 새로운 프로그래머 / 기여자가 어떻게 작동하는지 이해하기 위해 대규모 프로젝트를 쉽게 만드는 좋은 방법일까요? 일관된 코딩 스타일과 '표준'디렉토리 구성을 유지하는 것 외에도 이러한 경우에 대한 '표준'또는 권장 사항이 있습니까?


32
지옥 아니 코드를 읽을 수 없으면 설명서가 도움이되지 않습니다.
Telastyn

35
@jeffo-문제는이 작업을 수행하는 데 시간이 걸리면 한 번 발생할 수 있다는 것입니다. 코드를 읽을 수있는 시간은 시간이 지남에 따라 발생합니다. 나는 프로젝트가 어렸을 때, 또는 완벽 주의자 Joe가 여전히 팀에있을 때 행해지는 이런 종류의 문서를 가지고있었습니다. 그런 다음 포기하고 의견이 계속 남아 더 이상 정확하지 않습니다.
Telastyn

25
더 높은 수준에서 프로젝트의 기능, 작동 방식 및 아키텍처에서 이루어진 타협점에 대한 코드 외부의 산문 설명은 매우 중요합니다. 이런 종류의 문서는 신입생 이 코드 투어를 하기 전에 반드시 읽어야합니다 . 많은이 그물 주위 헛소리 내-방법론 - 너무 급진적를 위해 문서-친구의, 그리고 그 동안되어 있습니다 초기 아치 문서 및 진화 아치 문서가 정렬되지 않습니다 사실, 산문 설명이 필요하다 누구나 크고 사소한 코드베이스를 신속하게 파악할 수 있습니다. 다음은 (가난한) 예입니다. zxq9.com/erlmud/html/001-002_architecture.html
zxq9

11
@ Telastyn : 이것은 코드를 읽을 수 있는지 여부와 관련이 없습니다 (그리고 희망합니다). 설계 이론적 근거를 문서화하는 것이 절대적으로 중요합니다.
궤도에서 가벼움 경주

7
@Telastyn : 응, 아마도. 개인적으로 나는 독립형 문서로 작성했습니다. 그러나 소스 파일 상단의 주석 블록은 그렇게 나쁘지 않습니다.
궤도에서 가벼움 경주

답변:


139

대단해. 더 많은 소프트웨어 개발자가 시간과 노력을 들여이 작업을 수행했으면합니다. 그것:

  • 일반 영어로 수업이하는 일 (즉, 책임),
  • 코드가 말한 내용을 그대로 반복하지 않고 코드에 대한 유용한 보충 정보를 제공합니다.
  • 일부 디자인 결정 및 결정 이유 및
  • 다음 사람이 코드를 읽을 때 발생할 수있는 몇 가지 문제를 강조 표시합니다.

아아, 많은 프로그래머들은 "코드가 올바르게 작성되면 문서화 할 필요가 없다"는 수용소에 빠진다. 사실이 아니다. 코드 클래스, 메소드, 모듈 및 코드 자체를 읽는 것만으로는 명확하지 않은 기타 아티팩트 사이에는 많은 암시 적 관계가 있습니다.

숙련 된 코더는 문서 없이도 명확하고 이해하기 쉬운 아키텍처를 가진 디자인을 신중하게 제작할 수 있습니다. 그러나 실제로 몇 개의 프로그램을 보셨습니까?


15
그리고 "신화적인 남자의 달"이 스스로 성취되는 예언이 된 이유는, 새로운 개발자가 마음에 새롭고 프로젝트가 뒤지지 않았을 때이 모든 것을 쓸 시간이 없었습니다.
JeffO

3
나는 당신이 여기에서 만드는 모든 점에 동의합니다. OP가 자신의 게시물에 사용한 용어가 마음에 들지 않습니다 how a class works. 시간과 유지 보수에 따라 변경됩니다. 우리 팀은 위의 내용을 소스에 넣지 않습니다. 의사 결정이있는 위키를 유지하고 문서에 포함 된 설계 결정에 대한 여유 채널 토론을 복사합니다 (우리는 의사 결정 요약 및 결론에서 원시 노트로의 링크를 제공하므로 이전 결정을 다시 해시 할 필요가 없습니다). 모두 github에서 깔끔하게 완료되었습니다 (따라서 모두 한곳에 있습니다).
Martin York

1
내 유일한 문제는 이것을 전 세계적으로 적용하는 것입니다. 이 클래스는 충분히 복잡하고 특정 문제가 가능하며 실제로 유용합니다 (댓글 썩음 처리를 끝내더라도). 수업이 더 분명한 경우 주석이 약간 불필요 할 수 있습니다.
deworde

1
"경험이 풍부한 코더는 문서 없이는 명확하고 이해하기 쉬운 아키텍처를 가진 디자인을 신중하게 만들 수 있습니다. 그러나 실제로는 그와 같은 프로그램이 몇 개나 있습니다"이것이 사실이지만 문서의 품질은 결코 품질보다 우수하지 않습니다. 코드. 잘 설계된 코드는 무의미하지만 문서화가 좋은 경향이 있습니다. 잘못
설계된

3
나는이 답변에 전적으로 동의하며, 코드에서 OP의 예와 같은 것을 발견하면 너무 행복 할 것입니다. 단 한 번의 추가 : 댓글에 날짜 를 추가하고 최종 독자에게 설명의 최신 정보에 대한 힌트를 제공하고 텍스트를 업데이트 할 때마다 업데이트하십시오.
Svalorzen

36

큰 코드베이스 작업의 핵심은 변경하기 위해 전체 코드베이스를 읽을 필요가 없습니다. 프로그래머가 원하는 코드를 신속하게 찾을 수 있으려면 코드를 구성하고 조직을 명확하게해야합니다. 즉, 실행 파일, 라이브러리, 네임 스페이스, 개별 클래스에 이르기까지 코드의 각 논리 단위에는 분명한 책임이 있어야합니다. 따라서 소스 파일뿐만 아니라 해당 파일이있는 디렉토리도 문서화합니다.

프로그래머의 노트는 디자인 결정에 대한 배경 지식도 제공합니다. 이 정보는 귀중한 정보가 될 수 있지만, 책임의 진술과 분리하여 (독자가 수업의 책임에 대해 읽고 싶은지 또는 설계 이론적 근거를 읽을 것인지 선택할 수 있도록), 설명하는 출처와 가까운 곳으로 옮기십시오. 가능한 경우, 코드가 업데이트 될 때 문서가 업데이트 될 가능성을 최대화합니다 (문서는 정확성을 신뢰할 수있는 경우에만 유용합니다. 오래된 문서는 없음보다 나쁠 수 있습니다!).

즉, 문서는 DRY로 유지되어야합니다. 즉, 코드로 표현되었거나 다른 곳에서 이미 설명 된 정보를 반복해서는 안됩니다 ( "문서 상태"와 같은 문구는 경고 표시입니다). 특히, 미래의 관리자는 영어와 마찬가지로 프로젝트의 프로그래밍 언어에 능숙 할 것입니다. 주석으로 구현을 해석하면 (사람들이 문서를 자랑스럽게 생각할 때 너무 자주 볼 수 있음) 이점이 없으며, 특히 문서가 설명 된 코드 근처에 있지 않은 경우 구현에서 벗어날 수 있습니다.

마지막으로 문서 구조는 프로젝트 전체에서 표준화되어야 모든 사람들이 문서를 찾을 수 있습니다 (버그 추적기의 Peter 문서, Wiki의 Sue, readme의 Alan, 소스 코드의 John). .


첫 번째 문장은 내가 이것을 어떻게 보는지입니다. 큰 코드베이스는 새로운 프로그래머가 다른 코드를 위험에 빠뜨리지 않고 하나를 안정적으로 변경할 수있는 여러 개의 작은 컴포넌트로 구성되어야합니다.
Jon Chesterfield

1
코드가이면 문서가 업데이트 될 가능성을 최대화하기 위해 가능한 한 설명 된 소스에 가깝게 이동하십시오 . 이것은 귀중한 경험입니다.
laike9m

문서화를위한 가이드 라인으로서의 DRY는 매우 좋은 지적입니다! 그러면 자동으로 초점이 올바르게 설정되고 유명한 "// x x 1 증가"설명이 금지됩니다.
Hans-Peter Störr

13

나는 이것이 매우 좋은 접근 방식이라는 것에 동의하지 않을 것입니다.

  1. 프로젝트를 리팩터링 할 때 메소드를 이동하면 문서가 중단됩니다.

  2. 설명서가 제대로 업데이트되지 않으면 코드를 이해하는 데 도움이되는 것보다 더 혼란 스러울 수 있습니다.

각 모듈에 대한 각 방법 / 통합 테스트에 대한 단위 테스트가있는 경우 코드 주석에 비해 유지 관리가 쉽고 이해하기 쉬운 자체 문서가됩니다.

그렇습니다. 적절한 디렉토리 구조를 갖는 것이 확실히 도움이 될 것입니다.


코드 기반을 이해하는 가장 좋은 방법은 테스트에 +1입니다. 단위 테스트, 통합 테스트, 승인 테스트는 모두 응용 프로그램의 작동 방식과 사용 방법에 대한 이야기를 제공합니다.
BZink

7

저는 개인적으로 디자인에 대한 개요와 클래스 및 리소스 목록을 제공하는 고급 디자인 문서를 선호합니다. 하향식 설계는 사물을 크게 단순화합니다. "게임 엔진-> 하드웨어-> 컨트롤러-> 조이스틱"일 수 있습니다. 따라서 새로운 프로그래머는 " 'xyz 컨트롤러의'a '버튼을 수정하십시오."

현대 언어가 너무 많으면 코드를 수백 개의 작은 파일로 나누는 경향이 있으므로 적절한 파일을 찾는 것만으로도 중간 정도의 프로젝트에서 문제가 될 수 있습니다.


16
20 년 전에 모든 코드는 하나의 거대한 파일에있었습니다. 이제 수천 개의 작은 파일과 테스트 파일이 있습니다. 이에 대한 충분한 이유가 있으며 20 년의 소프트웨어 개발 (일반 지식이 아닌 일반적인 생태계)을 반영합니다. 그래도 의견이 너무 깁니다.
Michael Durrant

4
아, 코딩하기 전에 단일의 포괄 불변의 진실을 작성하는 오래된 폭포 방법은 심지어 시작에서 상기 진실로부터 구현에서 벗어나는 것을 불가능하게 만듭니다.
jwenting

2
@jwenting : 당신은 그것을 멀리 가져갈 필요가 없습니다. 그러나이 여전히 좋은 일부 당신이 구축하고있는 무슨 생각을.
Robert Harvey

1
확실히 이것을 어떻게 분류하고 규칙을 어기는지에 대한 경고없이, 당신은 매우 오래된 문서 또는 맷돌이있는 문서를 매우 빨리 가질 것입니다. "시간을 먹는 베헤모스 도쿠 칸토에 새로운 수업을 추가해야합니다!"
deworde

2
@deworde : 나는 "문서를 유지하기에는 너무 게으른"것으로 읽었습니다.
Robert Harvey

6

코드베이스가 큰 경우- 디자인과 구현의 핵심 요소를 설명 하는 디자인 문서 를 제공하려고합니다 . 여기서 사용 된 클래스는 사용 된 클래스를 자세히 설명하는 것이 아니라 코드와 디자인에 대한 생각의 열쇠를 제공하는 것입니다. 그것은 시스템, 그 구성 요소 및 그 적용에 대한 중요한 맥락을 제공한다.

디자인 문서에 포함 할 사항은 다음과 같습니다.

  • 응용 프로그램 아키텍처
  • 논리 코드 구조
  • 데이터 흐름
  • 사용 된 주요 패턴 및 사용 동기
  • 코드 소스 구조
  • 빌드 방법 (암시 적 종속성 및 실제 코드 소스 구조에 대한 통찰력 제공)

이에 따라 클래스 및 기능 / 방법에 대한 문서를 적절하게 작성해야합니다 . 특히 공개 API; 각 경우에 다음의 모든 것이 무엇인지 분명해야한다.

  • 전제 조건
  • 효과
  • 불변
  • 예외 조건 (투사)

+1 각 클래스를 설명하는 것보다 낫습니다. 전체 디자인보다 더 빨리 구식이 될 것입니다.
Lode

4

새로운 개발자가 코드베이스를 이해하기 쉽도록 만드는 가장 중요한 규칙은 완벽한 계약이 비싸다는 것입니다.

새로운 개발자가 작업중인 시스템을 완벽하게 이해해야하는 경우, 직업 학습에 대한 모든 기회를 막을 수 있습니다. 나는 프로그래머의 노트가 훌륭한 시작이라고 생각하지만 더 나아갈 것입니다. 새로 접근 할 경우 개발자가 사전에 학습을 요구하지 않고 진행중인 작업을 파악할 수있는 코드를 작성하십시오. 어설 션이 유효한 이유를 설명하는 의견과 함께 절대 발생할 수없는 사례에 대한 어설 션과 같은 것은 먼 길을갑니다. 따라서 무언가 잘못하면 segfaulting 대신 정상적으로 실패하는 코드를 작성합니다.


나의 규칙은 의견이 HOW가 아니라 WHY 에 관한 것이어야한다는 것이다 . 코드는 HOW를 설명합니다.
user11393

3

나는 문서가있는 큰 클래스를 보았고 문서를 읽은 후에이 클래스가 무엇을 좋아하는지, 왜 누군가가 그것을 사용할 것인지에 대한 단서를 얻지 못했습니다! 동시에 일부 기능이 필요했으며 처리 할 클래스가 있어야하고 어디서나 찾을 수 없다는 것을 절대 확신했습니다. 필요한 클래스에서 수업으로 안내하는 문서가 없기 때문에 하고 있어요

따라서 문서에서 가장 먼저해야 할 것은 클래스가하는 몇 문장과 왜 그것을 사용하고 싶은지입니다. 원래 질문의 의견은 그 점에서 상당히 잘하고 있습니다. 이 주석을 읽은 후 전달하는 값을 해석 할 수 없어서 잘 작동하지 않는 조이스틱이 있으면 어떤 코드를 검사해야하는지 알 것입니다.


0

@meriton이 말한 것과 유사하게 코드를 별도의 구성 요소로 나눕니다. 또한 코드베이스를 별도의 패키지 (JAR, 보석, 계란 등)로 분류하여 구성 요소를보다 명확하게 구분할 수 있습니다. 버그가있는 경우 개발자 는 버그가 있는 패키지 만 찾아서 해결해야합니다. 말할 것도없이, 단위 테스트를 수행하는 것이 더 쉬우 며 종속성 관리를 활용할 수 있습니다.

또 다른 해결책 : 코드베이스를 작게 만드십시오. 코드가 적을수록 이해하기 쉽습니다. 사용하지 않거나 중복 된 코드를 리팩터링하십시오. 선언적 프로그래밍 기술을 사용하십시오 . 이것은 물론 노력이 필요하며 종종 불가능하거나 실용적이지 않습니다. 그러나 가치있는 목표입니다. Jeff Atwood가 다음과 같이 썼습니다 : 최고의 코드는 전혀 코드가 아닙니다


-1

복잡한 시스템의 경우 각 파일뿐만 아니라 해당 파일의 상호 작용 및 계층 구조, 프로그램의 구조 및 이유를 문서화하는 것이 좋습니다.

예를 들어 게임 엔진은 일반적으로 매우 복잡하며 수백 개의 추상화 계층 이후에 무엇이 호출되는지 결정하기가 어렵습니다. "Architecture.txt"와 같은 파일을 작성하여 코드가 어떻게 어떻게 구성되고 왜 그처럼 무의미한 추상화 계층이 있는지 설명 할 수 있습니다.


-7

각 개인이 자신의 프로젝트 부분 만 이해하기 때문에 단일 프로그래머가 작성하기 어렵 기 때문에 부분적으로 가능합니다.

때때로 프로젝트 관리자의 노트에서이 정보를 얻을 수 있지만이 형식으로 노트를 거의 다시 쓰지 않기 때문에 이것이 전부입니다.


7
github를 보면 README.md 파일에 이런 종류의 메모가있는 많은 프로젝트가 있습니다. 그것은 일반적으로 git 문화의 많은 부분이되었으며 특히 대부분의 사람들에게 자바 스크립트 프로젝트는 이런 종류의 고급 문서가없는 라이브러리를 사용하지 않습니다. 따라서 "프로그래머가 작성하지 않을 것"은 사실이 아닙니다. jQuery 나 socket.io와 같은 것을보고 그러한 것을 쓰는 프로그래머를 찾아야하기 때문입니다. 또한 정확하지 않은 README 파일이 버그 보고서를 생성하는 문화가되었습니다.
slebetman

1
이것은 문서화 스타일이 제안하거나 작동하지 않는 이유와 문서 표준을 찾는 질문에 대답하지 않는 것 같습니다.
user52889

5
제품에 대해 작업하는 프로그래머 팀이 있고 각 프로그래머가 작업 한 특정 코드 만 이해하면 팀이 버스 기능이 부적절하게 작동하지 않을뿐만 아니라 코드의 품질에 의문을 갖게됩니다. 동일한 시스템의 나머지 코드를 이해하지 않고 어떻게 코드를 제품에 통합합니까?
궤도에서 가벼움 경주
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.