대규모 코드베이스에 익숙해지는 가장 좋은 방법은 무엇입니까?

대규모 코드베이스에 익숙해지는 가장 좋은 방법은 무엇입니까?

---

이미 대규모 코드베이스가있는 기존 팀에 합류하는 것은 어려울 수 있습니다. 최선의 접근 방식은 무엇입니까?

• 넓은; 코드에서 모든 것이 어떻게 연결되는지에 대한 일반적인 개요를 얻으십시오.
• 제한된; 한 번에 작은 코드 섹션에 집중하고 코드가 완전히 작동하는 방식을 이해합니다.
• 진행하면서 개발하고 배울 기능을 선택하십시오.
• 가능한 경우 클래스 다이어그램 및 uml에서 통찰력을 얻으십시오 (최신).
• 완전히 다른 것?

나는 현재 약 20k 라인의 C ++ 앱 및 라이브러리에 대해 작업하고 있습니다 (편집 : 작습니다!). 업계에서는 경험 많은 프로그래머가 소개를받을 것이라고 생각합니다. 그러나 그렇지 않은 경우 가능한 한 빨리 가치를 추가하기 위해 무엇을 할 수 있습니까?

-
답변 요약 :

• 디버그 모드에서 코드를 단계별로 실행하여 작동 방식 확인
• 당신보다 코드베이스에 더 익숙한 사람과 짝을 이루고, 코딩하는 사람과보고 / 토론하는 사람이 되십시오. 팀원간에 파트너를 교체하여 지식이 확산되도록합니다.
• 단위 테스트를 작성합니다. 코드가 어떻게 작동 할 것이라고 생각하는지에 대한 주장으로 시작하십시오. 예상대로 나온다면 아마도 코드를 이해했을 것입니다. 그렇지 않다면 풀어야 할 퍼즐이나 질문이 있습니다. (감사합니다 Donal, 이것은 좋은 대답입니다)
• 위와 유사한 방식으로 기능 코드에 대한 기존 단위 테스트를 진행합니다.
• UML, Doxygen 생성 클래스 다이어그램 및 기타 문서를 읽고 코드에 대한 폭 넓은 느낌을 얻으십시오.
• 사소한 수정 또는 버그 수정을 한 다음 점진적으로 구축
• 메모를 남기고 뛰어 들어서 개발을 시작하지 마십시오. 지저분하거나 부적절한 코드를 생성하는 것보다 이해하는 데 시간을 보내는 것이 더 중요합니다.

이 게시물은 상속 된 코드베이스에 익숙해지기위한 최선의 방법 의 부분 복제입니다 .

---

가능하면 작은 작업으로 시작하여 문제 주변의 코드를 디버그하십시오. 디버그 모드에서 코드를 단계별로 실행하는 것이 작동 방식을 배우는 가장 쉬운 방법입니다.

---

또 다른 옵션은 관심있는 기능에 대한 테스트를 작성하는 것입니다. 테스트 하네스를 설정하는 것은 시스템에 어떤 종속성이 있고 시스템 상태가 어디에 있는지를 설정하는 좋은 방법입니다. 각 테스트는 시스템이 작동해야한다고 생각하는 방식에 대한 주장으로 시작됩니다. 그런 식으로 작동하는 것으로 판명되면 무언가를 얻은 것이며이를 재현 할 수있는 작동하는 샘플 코드가있는 것입니다. 그런 식으로 작동하지 않으면 풀어야 할 퍼즐과 따라야 할 일련의 질문이 있습니다.

---

내가 아직 언급하지 않은 사람들에게 일반적으로 제안하는 한 가지는 개발자가되기 전에 기존 코드 기반의 유능한 사용자가되는 것이 중요하다는 것입니다. 새로운 개발자가 대규모 소프트웨어 프로젝트에 참여할 때 코드 작업에 뛰어 들기 전에 전문 사용자가되는 데 시간을 할애하는 것이 좋습니다.

당연 할 수도 있지만, 많은 사람들이 발전을 시작하기를 열망하기 때문에 코드에 너무 빨리 뛰어 들려고하는 것을 보았습니다.

---

이것은 당신이 어떤 종류의 학습자이고 어떤 종류의 프로그래머인지에 따라 상당히 다릅니다.

• 넓은 우선-범위와 크기에 대한 아이디어가 필요합니다. 여기에는 괜찮다면 문서 / uml 스키밍이 포함될 수 있습니다. 장기적인 프로젝트이고 모든 것을 완전히 이해해야한다면 실제로 문서를 제대로 읽을 수 있습니다. 또, 경우에 그들은 좋은거야.
• 좁음-관리 가능한 것을 선택하고 이해하려고 노력하십시오. 코드에 대한 "맛"을 얻으십시오.
• 기능을 선택하십시오. 자신감이 있으면 방금 본 것과 다른 기능을 선택하고 약간의 변경을 시작하십시오.
• 반복-일이 얼마나 잘 진행되었는지 평가하고 더 깊이있는 초기 단계를 반복하는 것이 도움이되는지 확인합니다.

---

엄격한 회전과 페어링.

가능하면 문서 / 코드베이스를 살펴 보는 동안 엄격한 회전으로 페어링을 사용하십시오. 즉, 두 사람이 고정 된 시간 (예 : 2 시간 세션) 동안 함께 앉아 쌍을 전환하면 한 사람은 해당 작업을 계속하고 다른 사람은 다른 파트너와 함께 다른 작업으로 이동합니다.

짝을 지어 두 사람 모두 지식을 습득 한 다음 회전이 발생할 때 팀의 다른 구성원에게 제공 할 수 있습니다. 이것에 대한 좋은 점은 새로운 쌍이 모일 때 작업을 수행 한 사람 (이 경우 코드 조사)이 개념을보다 쉽게 ​​이해할 수있는 방식으로 요약하고 설명 할 수 있다는 것입니다. 시간이 지남에 따라 모든 사람은 비슷한 수준의 이해를해야하며 "오, 오직 John만이 코드를 알고 있습니다"신드롬을 피해야합니다.

당신의 시나리오에 대해 제가 말할 수있는 바에 따르면, 당신은 이것에 대해 좋은 숫자 (3 쌍)를 가지고 있지만, 당신이 분산되어 있거나 같은 시간 척도로 일하지 않는다면 그것은 가능하지 않을 것입니다.

---

최신 클래스 다이어그램을 얻기 위해 Doxygen을 실행 한 다음 잠시 동안 확장하는 것이 좋습니다. 이것은 당신이 코드를 가까이서 더럽힐 때 사용할 수있는 빠른 큰 그림을 제공합니다.

---

나는 그것이 당신이 어떤 유형의 학습자인지에 전적으로 달려 있다는 것에 동의합니다. 하지만 저는 처음부터 매우 큰 코드 기반을 가진 두 회사에있었습니다. 일반적으로 다음과 같이 작업합니다.

가능하다면 기능 코드를보기 전에 이미 작성된 단위 테스트를 거칩니다. 이것들은 일반적으로 많은 도움이 될 수 있습니다. 사용할 수없는 경우 다음을 수행합니다.

첫째, 구현을 거의 무시하고 헤더 파일 또는 클래스 인터페이스 만 살펴 봅니다. 나는 각 수업의 목적이 무엇인지 생각하려고 노력합니다. 둘째, 가장 중요한 영역으로 보이는 것부터 시작하여 구현에 대해 한 단계 깊이 들어갑니다. 이것은 측정하기 어렵 기 때문에 가끔 맨 위에서 시작하여 파일 목록에서 아래로 작업합니다. 나는 이것을 폭 우선 학습이라고 부릅니다. 이 초기 단계 후에는 일반적으로 나머지 코드를 깊이있게 살펴 봅니다. 초기 너비 우선 모양은 인터페이스 수준에서 얻은 아이디어를 강화 / 수정하는 데 도움이되며, 깊이 별 모양은 시스템 구현에 사용 된 패턴과 다양한 디자인 아이디어를 보여줍니다. 깊이 우선이란 기본적으로 디버거를 사용하여 프로그램을 단계별로 실행하고 각 기능을 실행하여 작동 방식을 확인합니다. 등등. 이것은 정말 큰 시스템에서는 불가능하지만 20k LOC는 그다지 많지 않습니다. :)

---

시스템에 더 익숙한 다른 프로그래머와 협력하여 새로운 기능을 개발하거나 버그를 수정하십시오. 이것이 제가 본 최고의 방법입니다.

---

나는 이것을 특정 작업에 연결해야한다고 생각합니다. 손에 시간이있을 때 원하는 접근 방식으로 가십시오.

완료해야 할 일이 있으면 자신에게 좁은 초점을 맞추고 완료하십시오.

---

팀이 2 주 동안 버그를 수정하도록합니다 (2 주가있는 경우). 그들은 누군가에게 책임을지게 해줄 것이며, 기간이 끝날 무렵에는 도서관에서 문제를 해결하는 데 너무 많은 시간을 할애하여 아마 꽤 잘 알고있을 것입니다.

---

단위 테스트가 있으면 (그렇지 않을 것입니다). 작게 시작하고 단위 테스트가 실패하지 않는지 확인하십시오. 전체 코드베이스를 한 번에 쳐다 보면 눈이 번쩍이고 압도 감을 느낄 것입니다.

단위 테스트가 없으면 원하는 기능에 집중해야합니다. 앱을 실행하고 기능이 영향을 미칠 결과를 확인합니다. 그런 다음 코드를 살펴보고 앱이 변경하려는 항목을 생성하는 방법을 파악합니다. 마지막으로 변경하고 원하는 방식으로 결과가 나오는지 확인하십시오.

앱과 라이브러리라고 말씀하셨습니다. 먼저 앱을 변경하고 라이브러리를 사용자로 사용하십시오. 그러면 도서관을 배운 후에 변경하기가 더 쉬울 것입니다.

하향식 접근 방식에서 앱에는 모든 작업을 제어하는 ​​기본 루프 또는 기본 GUI가있을 수 있습니다. 애플리케이션의 주요 제어 흐름을 이해하는 것이 좋습니다. 앱의 주요 흐름에 대한 광범위한 개요를 제공하기 위해 코드를 읽는 것이 좋습니다. GUI 앱인 경우 어떤 화면이 있고 한 화면에서 다른 화면으로 이동하는 방법을 보여주는 문서를 작성합니다. 명령 줄 앱인 경우 처리 방법입니다.

회사에서도 이러한 접근 방식을 사용하는 것은 드문 일이 아닙니다. 종종 아무도 응용 프로그램의 작동 방식을 완전히 이해하지 못합니다. 그리고 사람들은 당신을 보여줄 시간이 없습니다. 그들은 특정 사항에 대한 구체적인 질문을 선호하므로 직접 조사하고 실험해야합니다. 그런 다음 특정 질문을 받으면 응용 프로그램의 해당 부분에 대한 지식 소스를 분리하여 질문 할 수 있습니다.

---

'문제 영역'(급여 시스템입니까? 재고입니까? 실시간 제어 등)을 이해하는 것으로 시작하십시오. 사용자가 사용하는 전문 용어를 이해하지 못하면 코드를 이해하지 못할 것입니다.

그런 다음 개체 모델을 살펴보십시오. 이미 다이어그램이 있거나 다이어그램을 리버스 엔지니어링해야 할 수도 있습니다 (수동으로 또는 Doug가 제안한 도구를 사용하여). 이 단계에서 데이터베이스 (있는 경우)를 조사 할 수도 있습니다. 개체 모델을 따라야하지만 그렇지 않을 수도 있으므로 알고 있어야합니다.

변경 내역이나 버그 데이터베이스를 살펴보고 많이 나오는 영역이 있으면 먼저 해당 부분을 살펴보십시오. 이것은 그것이 잘못 쓰여졌다는 것을 의미하지는 않지만 모든 사람들이 사용하는 비트입니다.

마지막으로 메모를 보관하십시오 (나는 위키를 선호합니다).

• 기존 사람들은 당신의 가정을 온전하게 확인하고 당신을 도울 수 있습니다.
• You will need to refer back to it later.
• The next new guy on the team will really thank you.

---

I had a similar situation. I'd say you go like this:

• If its a database driven application, start from the database and try to make sense of each table, its fields and then its relation to the other tables.
• Once fine with the underlying store, move up to the ORM layer. Those table must have some kind of representation in code.
• Once done with that then move on to how and where from these objects are coming from. Interface? what interface? Any validations? What preprocessing takes place on them before they go to the datastore?

This would familiarize you better with the system. Remember that trying to write or understand unit tests is only possible when you know very well what is being tested and why it needs to be tested in only that way.

And in case of a large application that is not driven towards databases, I'd recommend an other approach:

• What the main goal of the system?
• What are the major components of the system then to solve this problem?
• What interactions each of the component has among them? Make a graph that depicts component dependencies. Ask someone already working on it. These componentns must be exchanging something among each other so try to figure out those as well (like IO might be returning File object back to GUI and like)
• Once comfortable to this, dive into component that is least dependent among others. Now study how that component is further divided into classes and how they interact wtih each other. This way you've got a hang of a single component in total
• Move to the next least dependent component
• To the very end, move to the core component that typically would have dependencies on many of the other components which you've already tackled
• While looking at the core component, you might be referring back to the components you examined earlier, so dont worry keep working hard!

For the first strategy: Take the example of this stackoverflow site for instance. Examine the datastore, what is being stored, how being stored, what representations those items have in the code, how an where those are presented on the UI. Where from do they come and what processing takes place on them once they're going back to the datastore.

For the second one Take the example of a word processor for example. What components are there? IO, UI, Page and like. How these are interacting with each other? Move along as you learn further.

Be relaxed. Written code is someone's mindset, froze logic and thinking style and it would take time to read that mind.

---

First, if you have team members available who have experience with the code you should arrange for them to do an overview of the code with you. Each team member should provide you with information on their area of expertise. It is usually valuable to get multiple people explaining things, because some will be better at explaining than others and some will have a better understanding than others.

Then, you need to start reading the code for a while without any pressure (a couple of days or a week if your boss will provide that). It often helps to compile/build the project yourself and be able to run the project in debug mode so you can step through the code. Then, start getting your feet wet, fixing small bugs and making small enhancements. You will hopefully soon be ready for a medium-sized project, and later, a big project. Continue to lean on your team-mates as you go - often you can find one in particular who is willing to mentor you.

Don't be too hard on yourself if you struggle - that's normal. It can take a long time, maybe years, to understand a large code base. Actually, it's often the case that even after years there are still some parts of the code that are still a bit scary and opaque. When you get downtime between projects you can dig in to those areas and you'll often find that after a few tries you can figure even those parts out.

Good luck!

---

You may want to consider looking at source code reverse engineering tools. There are two tools that I know of:

• SWAG Kit (Linux only) link
• Bauhaus academic commercial

Both tools offer similar feature sets that include static analysis that produces graphs of the relations between modules in the software.

This mostly consists of call graphs and type/class decencies. Viewing this information should give you a good picture of how the parts of the code relate to one another. Using this information, you can dig into the actual source for the parts that you are most interested in and that you need to understand/modify first.

---

I find that just jumping in to code can be a a bit overwhelming. Try to read as much documentation on the design as possible. This will hopefully explain the purpose and structure of each component. Its best if an existing developer can take you through it but that isn't always possible.

Once you are comfortable with the high level structure of the code, try to fix a bug or two. this will help you get to grips with the actual code.

---

I like all the answers that say you should use a tool like Doxygen to get a class diagram, and first try to understand the big picture. I totally agree with this.

That said, this largely depends on how well factored the code is to begin with. If its a gigantic mess, it's going to be hard to learn. If its clean, and organized properly, it shouldn't be that bad.

---

See this answer on how to use test coverage tools to locate the code for a feature of interest, without knowing anything about where that feature is, or how it is spread across many modules.

---

(shameless marketing ahead)

You should check out nWire. It is an Eclipse plugin for navigating and visualizing large codebases. Many of our customers use it to break-in new developers by printing out visualizations of the major flows.

참고URL : https://stackoverflow.com/questions/215076/whats-the-best-way-to-become-familiar-with-a-large-codebase