큰 코드 기반으로 어떻게 뛰어들습니까?

알려지지 않은 코드베이스를 탐색하고 학습하기 위해 어떤 도구와 기술을 사용합니까?

내가 좋아하는 도구로 생각하고 grep, ctags, 단위 테스트, 기능 테스트, 클래스 다이어그램 발전기, 그래프를 호출과 같은 코드 메트릭 sloccount등등합니다. 귀하의 경험, 귀하가 사용하거나 작성한 도우미 및 귀하와 함께 일한 코드베이스의 크기에 관심이 있습니다.

코드 기반에 익숙해지는 것은 시간이 지남에 따라 발생하는 프로세스이며 친숙 함은 "코드를 요약 할 수 있습니다"에서 "리팩토링 및 크기의 30 %로 축소 할 수 있음"에 이르기까지 모든 것을 의미 할 수 있습니다. 그러나 어떻게 시작 하는가?

내가 항상 한 일은 다음과 같습니다.

내 편집기 (Visual Studio / Eclipse / Whatever)의 여러 복사본을 연 다음 디버그하고 줄 바꿈을 통해 코드를 단계별로 실행하십시오. 코드의 흐름을 확인하고, 트레이스를 쌓아서 핵심 포인트가 어디 있는지 확인한 다음 그 지점으로 이동하십시오.

메소드 후 메소드를 볼 수는 있지만 무언가를 클릭 한 다음 코드에서 실행되고 따라 오는 위치를 볼 수 있으면 좋습니다. 개발자가 작업하기를 원하는 방식에 대해 알아 보겠습니다.

코끼리는 어떻게 먹습니까?

한 번에 한 입 :)

진지하게, 나는 코드 작성자에게 먼저 이야기하려고합니다.

작업이 완료 될 때까지 해킹해야합니까

대체로 그렇습니다 (죄송합니다).

고려할 수있는 접근법 :

1. 비즈니스 측면에서 코드가 수행해야 할 작업을 찾아보십시오.
2. 아무리 나쁘더라도 존재하는 모든 문서를 읽으십시오.
3. 코드에 대해 알고 있는 사람에게 이야기 하십시오.
4. 디버거에서 코드를 단계별로 실행하십시오.
5. 작은 변화를 소개하고 어떤 부분이 깨지는 지보십시오.
6. 코드를 좀 더 명확하게 변경하십시오.

코드를 명확히하기 위해 수행하는 작업 중 일부는 다음과 같습니다.

1. 코드 사전 설정기를 실행하여 코드를 멋지게 형식화하십시오.
2. 내가 할 수 있다고 생각하는 것을 설명하기 위해 의견을 추가하십시오.
3. 리팩토링 도구를 사용하여 변수 이름을 명확하게 변경
4. 특정 기호의 모든 용도를 강조하는 도구 사용
5. 코드에서 혼란을 줄이십시오-주석 처리 된 코드, 의미없는 주석, 무의미한 변수 초기화 등.
6. 리팩토링 도구를 사용하여 현재 코드 규칙을 사용하도록 코드 변경
7. 의미있는 루틴으로 기능 추출 시작
8. 가능하면 테스트를 추가하기 시작하십시오.
9. 매직 넘버 제거
10. 가능한 경우 중복 줄이기

... 그리고 당신이 할 수있는 다른 간단한 개선 사항들.

점차적으로 그 배후의 의미가 더 명확 해져야합니다.

시작하는 곳은? 아는 것부터 시작하십시오. 입력 및 출력을 제안합니다. 당신은 종종 이것들이 무엇인지, 그것들이 무엇을하는지에 대한 핸들을 얻을 수 있습니다. 응용 프로그램을 통해 데이터를 추적하고 데이터 이동 위치 및 변경 방법을 확인하십시오.

내가 가진 모든 문제 중 하나는 동기 부여입니다. 그것은 진짜 슬로 그일 수 있습니다. 그것은 전체 사업을 퍼즐로 생각하고, 아무리 작더라도 내가 만들고있는 발전을 축하하는 데 도움이됩니다.

당신의 상황은 실제로 일반적입니다. 작업 할 기존 코드가있는 새 작업을 수행해야하는 사람은 그 일부 요소를 처리해야합니다. 시스템이 실제로 불쾌한 레거시 시스템 인 경우 설명한 것과 매우 유사합니다. 물론 현재 문서가 없습니다.

첫째, 많은 사람들이 Michael Feathers의 레거시 코드 로 효과적으로 작업 하도록 권장했습니다 . "이 클래스를 테스트 하네스에 넣을 수 없습니다"또는 "응용 프로그램에 구조가 없습니다"와 같은 유용한 장이 포함 된이 책은 실제로 좋은 책입니다. 때때로 깃털은 솔루션보다 더 많은 동정을 줄 수 있습니다. 특히,이 책과 그 예는 주로 중괄호 언어에 맞춰져 있습니다. 울퉁불퉁 한 SQL 프로 시저로 작업하는 경우 유용하지 않을 수 있습니다. "이 코드를 충분히 이해하지 못해 코드를 이해하지 못했습니다"라는 장이 문제에 대한 것이라고 생각합니다. 페더는 여기에 메모 작성 및 리스팅 마크 업과 같은 명백한 사항을 언급하지만 소스 제어가있는 경우 사용하지 않는 코드를 삭제할 수 있다는 점을 지적합니다. 많은 사람들이 주석 처리 된 코드 섹션을 그대로두고

다음으로, 귀하의 제안 된 접근법이 확실히 좋은 단계라고 생각합니다. 먼저 코드의 목적이 무엇인지 높은 수준에서 이해해야합니다.

질문에 대한 답변이 필요한 경우 멘토 나 팀원과 확실히 협력하십시오.

또한 결함이 밝혀지면 코드를 지원할 기회를 가지십시오 (때때로 자원 봉사를 할 필요는 없지만 결함이 발견 될 수 있습니다!). 사용자는 소프트웨어의 용도 및 결함이 소프트웨어에 미치는 영향을 설명 할 수 있습니다. 소프트웨어의 의미를 이해하려고 할 때 종종 매우 유용한 지식이 될 수 있습니다. 또한 공격 할 목적이있는 코드로 코드에 들어가면 "짐승"에 직면했을 때 집중하는 데 도움이 될 수 있습니다.

정말 큰 소스 파일이있을 때 다음을 수행하고 싶습니다.

• 전체 혼란을 클립 보드에 복사
• Word / 텍스트 메이트에 붙여 넣기
• 글꼴 크기를 최소로 줄이십시오.
• 코드의 패턴을 보면서 아래로 스크롤

일반 편집기로 돌아갈 때 코드가 얼마나 익숙한 지 놀랄 것입니다.

시간이 걸린다

레거시 코드베이스, 특히 익숙하지 않은 기술 / 언어 / 프레임 워크를 사용하는 경우 레거시 코드베이스를 이해하려고 할 때 너무 서두르지 마십시오. 시간이 걸리는 피할 수없는 학습 곡선 일뿐입니다.

한 가지 방법은 관련 기술에 대한 코드와 자습서 사이를왔다 갔다하는 것입니다. 튜토리얼을 읽거나 본 다음 코드를 살펴보면 이전과 유사한 기능과 차이점을 지적하고 메모를하고 기존 개발자에게 질문을하는 방식으로 이전 모델이 수행 한 방식을 확인할 수 있습니다.

"왜이 부분을 이런 식으로 했습니까?"

"대부분의 온라인 사람들이 이런 식으로 일을하고있는 것을 눈치 채 셨고, 여러분 모두 다른 방법으로 일을하셨습니다. 왜 그렇습니까?"

"모든 것이 기술 Y보다 기술 X를 선택한 이유는 무엇입니까?"

이 질문에 대한 답변은 프로젝트의 역사와 설계 및 구현 결정의 근거를 이해하는 데 도움이됩니다.

결국, 당신은 당신이 물건을 추가 / 수정을 시작할 수있을 정도로 익숙해집니다. 모든 것이 혼란스러워 보이거나 너무 많은 "마법"이 진행되는 것처럼 보이면, 그것을보고 소화하고 다이어그램으로 만드는 데 충분한 시간을 소비하지 않은 것입니다. 다이어그램 (시퀀스 다이어그램, 프로세스 플로우 다이어그램 등)을 작성하면 복잡한 프로세스를 이해하고 "다음 사람"에게 도움이됩니다.

cscope는 C에 대해 ctags가 수행 할 수있는 모든 작업을 수행 할 수 있으며 모든 현재 함수가 호출 된 위치를 나열 할 수도 있습니다. 또한 매우 빠릅니다. 수백만의 LOC로 쉽게 확장 할 수 있습니다. emacs 및 vim에 깔끔하게 통합됩니다.

C 및 C ++ 코드 카운터-cccc는 html 형식의 코드 메트릭을 생성 할 수 있습니다. LOC를 얻기 위해 wc도 사용했습니다.

doxygen은 HTML로 구문 강조 표시 및 상호 참조 코드를 생성 할 수 있습니다. 큰 코드 기반을 탐색하는 데 유용합니다.

Drupal에서 권장하는 방식은 실제로 Drupal과는 다릅니다. 이슈 트래커부터 시작하십시오. 오래되고 닫히지 않은 버그 리포트가있을 것입니다. 그것들을 재현 할 수 있습니까? 그렇다면 티켓을 확인하여 업데이트하십시오. 그렇지 않은 경우 닫습니다. 이 방법으로 소프트웨어를 사용할 수있는 다양한 방법을 찾을 수 있으며 충돌이 발생하는 코드베이스를 엿볼 수 있습니다. 또는 코드를 단계별로 시작하여 코드가 충돌하는 위치에 어떻게 도달하는지 확인할 수 있습니다. 이렇게하면 코드베이스를 이해하기 시작할뿐만 아니라 많은 업장을 쌓을 수 있으며 커뮤니티는 귀하의 질문을 따뜻하게 환영합니다.

해야 할 중요한 일은 툴링을 사용하여 하향식 탐색 코드 아키텍처에 대한 종속성 그래프 를 생성하는 것 입니다. 먼저 .NET 어셈블리 또는 jar 사이의 그래프를 시각화하면 기능과 레이어가 구성되는 방법에 대한 아이디어를 제공 한 다음 네임 스페이스 종속성 (하나 또는 몇 개의 친척 .NET 어셈블리 또는 jar 내부)을 분석하여보다 세밀한 코드 아이디어를 얻을 수 있습니다. 마지막으로 클래스 종속성을 살펴보고 일련의 클래스가 협업하여 기능을 구현하는 방법을 이해할 수 있습니다. 예를 들어 NDepend for .NET 과 같이 아래 그래프를 생성하는 종속성 그래프를 생성하는 몇 가지 도구가 있습니다.

한때 꽤 환상적인 소프트웨어 엔지니어에게 가장 비싼 코드 분석 및 유지 관리 형태는 코드를 한 줄씩 살펴 보는 것이 었습니다. 물론, 우리는 프로그래머이며, 그 일이 거의 함께합니다. 제 생각에 행복한 매체는 (순서대로) 다음과 같습니다. 1. 작동하는 코드를 이해하는 방법에 대한 메모를 작성하고 시간이 지남에 따라 코드를 추가 할 수있는 노트를 얻습니다. 코드 3에 대한 설명서를 참조하십시오. 코드 기반을 지원 한 작성자 또는 다른 사람들과 이야기하십시오. 그들에게 "브레인 덤프"를 요청하십시오. 4. 세부적인 수준의 클래스 관계를 이해하고있는 시점까지 코드의 단계별 디버깅을 수행하여 코드의 작동 방식과 실제 작동 방식 간의 합성을 수행하십시오. 코드가 실제로 작동하는 방식.

먼저 그것이 무엇을 의미하는지 이해하십시오-그것이 횡설수설하지 않을 것입니다. 사용자와 대화하고 설명서를 읽으십시오.

그런 다음 실행을 누르고 핵심 기능인 것처럼 보이는 코드를 걷기 시작하십시오.

나누고 정복하십시오. 각 기능과 관련 코드를보고, 단계별로 살펴보고 다음 단계로 넘어 가면서 전체 그림을 천천히 만듭니다.

프로젝트에 단위 테스트가 있다면 그것들도 통과하는 것을 좋아합니다. 그들은 항상 매우 밝고 밝습니다.

1. 있는 경우 모든 테스트를 실행하고 어떤 코드가 적용되고 어떤 코드가 적용되지 않는지 확인하십시오.
2. 변경해야 할 코드가 포함되지 않은 경우이를 테스트하기 위해 테스트를 작성하십시오.
3. 코드를 변경하십시오. 테스트를 중단하지 마십시오.

Michael Feathers의 레거시 코드를 효과적으로 사용하는 방법 보기

내 짧은 목록은 다음과 같습니다.

1. 가능하면 누군가가 코드에 대한 높은 수준의 뷰를 제공하도록하십시오. 고려 된 패턴, 어떤 종류의 컨벤션 등을 기대할 수 있습니까? 처음에는 약간의 라운드가있을 수 있습니다. 코드에 익숙해지면 새로운 질문이 생길 수 있습니다. 기존 프로젝트의 양파를 통해 작업 할 때 묻습니다.

2. 코드를 실행하고 시스템이 어떻게 보이는지 확인하십시오. 버그가 몇 개 이상있을 수 있지만 이것이하는 일에 대한 아이디어를 얻는 데 유용 할 수 있습니다. 이것은 코드를 변경하는 것이 아니라 어떻게 실행되는지 보는 것입니다. 다양한 부분이 어떻게 전체 시스템으로 통합됩니까?

3. 코드의 내부 정신 모델을 구축하는 데 도움이 될 수있는 테스트 및 기본 문서의 기타 지표를 찾으십시오. 문서와 테스트가 극히 적은 경우가 아니라면 적어도 며칠 동안 제안 할 것입니다.

4. 이 프로젝트에 사용 된 언어와 프레임 워크를 얼마나 잘 알고 있습니까? 여기서 중요한 것은 몇 가지 사항을보고 "예, 수십 번 전에 알고 그것을 상당히 잘 알고있다"는 것과 "세계에서 무엇을 시도하고 있습니까? 누가 이것이 좋은 생각이라고 생각합니까?"의 차이입니다. 큰 소리로 말하지는 않지만, 매우 깨지기 쉬운 레거시 코드를 볼 때 특히 코드를 작성한 사람들이 사용할 수 없거나 이유를 기억하지 못하는 경우 특히 궁금 할 것입니다. 상황은 원래대로되었습니다. 새로운 영역의 경우 구조가 무엇인지,이 코드에서 어떤 패턴을 찾을 수 있는지 알기 위해 시간을 좀 더 투자하는 것이 좋습니다.

마지막으로, 예상되는 것에 대한 다음과 같은 몇 가지 아이디어를 고려할 때 각 시점에서해야 할 일과 관련하여 프로젝트를 실행하는 사람들의 기대치를 알고 있어야합니다.

• 새로운 기능을 사용하고 있습니까?
• 버그를 수정하고 있습니까?
• 코드를 리팩토링하고 있습니까? 표준은 당신에게 새로운 것이거나 매우 친숙한가?
• 코드베이스에 익숙해 져야합니까?

모든 프로그램에는 하나 (예 : main 메소드, main class, init 등)가 있기 때문에 항상 프로그램의 진입 점으로 시작하고 시작합니다. 그러면 무엇이 시작되고 때로는 어떻게 연결되어 있는지 알려줍니다.

그 후 나는 드릴 다운합니다. 데이터베이스와 DAO가 어딘가에 구성되어 있으므로 물건이 어떻게 저장되는지 알 수 있습니다. 아마도 어떤 종류의 전역 인스턴스 클래스도 시작되어 거기에 무엇이 저장되어 있는지 알 수 있습니다. 그리고 좋은 굴절 도구로 누가 무엇을 부르는지 알아낼 수 있습니다.

그런 다음 정보의 다음 진입 점이므로 인터페이스가 구성되고 처리되는 위치를 찾으려고 시도합니다. 굴절, 검색 및 디버깅 도구가 검색에 도움이됩니다. 그런 다음 모든 클래스 파일을 통해 정보 처리가 시작되고 끝나는 위치를 파악할 수 있습니다.

그런 다음 처음에는 물건을 머리에 감아 서 종이에 흐름을 적어 둡니다. 제출 버튼은 일반 검증으로 전달 된 다음 DAO 또는 데이터베이스로 전달 된 다음 데이터베이스에 저장됩니다. 이것은 대부분의 앱을 지나치게 단순화 한 것이지만 일반적인 아이디어입니다. 펜과 종이는 여기에서 매우 유용합니다. 모든 것을 빠르게 기록 할 수 있고 도움이되는 프로그램의 서식에 대해 걱정할 필요가 없기 때문입니다.

나는 문서 등으로 시작한다고 말하지만, 내 경험상 문서의 깊이와 지역 지식은 종종 시스템의 나이, 크기 및 복잡성에 반비례합니다.

즉, 나는 보통 두 개의 기능적 스레드를 식별하려고 시도합니다. 기능적으로는 로그인, 고객 목록 등을 내리는 것과 같은 것을 의미합니다. 패턴이 전혀 일치하지 않으면 하나의 스레드가 시스템의 완전한, 완전한 단면을 제공해야합니다. 패턴이 일관성이 있는지 확인하는 가장 좋은 방법은 소수의 스레드를 분석하는 것입니다.

나는 이것이 말할 필요도 없다고 생각하지만, 제 생각에는 기술적 인 관점보다는 기능적인 관점에서 시스템을 이해하는 것이 좋습니다. 나는 일반적으로 사용중인 도구 (ORM, 로깅 라이브러리 등)에 대해 너무 걱정하지 않고 사용중인 패턴 (MVP 등)에 더 집중합니다. 내 경험상 도구는 일반적으로 유동적입니다.

나는 너무 많이 ...

여기에 "뭔가 작동하는"상황이있을 때의 현재 접근 방식은 "다른 방법으로 작동"해야합니다.

1. 목표를 달성하면 해당 시스템이 해결해야합니다 (작성하지 않은 경우). 가능한 경우 전직 관리자, 다른 직원에게 문의하십시오. 고객에게 요청하거나 문서를 검색하십시오.
2. 구체화하십시오. 존재하지 않으면 작성하십시오. 존재하지 않는 것처럼 누군가에게 물어 보는 것은 가치가 없으며, 다른 사람이별로 신경 쓰지 않는 상황에 처해 있습니다. 따라서 자신의 글을 쓰는 유일한 방법입니다 (나중에 더 쉽게 참조 할 수 있습니다).
3. 디자인하십시오. 존재하지 않음-작성하십시오. 가능한 한 모든 문서와 소스 코드를 참조하십시오.
4. 변경해야 할 부분에 자세한 디자인을 작성하십시오.
5. 테스트 방법을 정의하십시오. 따라서 이전 코드와 새 코드가 동일한 방식으로 작동하는지 확인할 수 있습니다.
6. 한 번에 시스템을 구축 할 수 있습니다. 그리고 오래된 코드로 테스트하십시오. 아직 SVC에 넣지 마십시오.
7. 변경 사항을 구현하십시오. 일찍이 아닙니다.
8. 한 달 정도 지나면 아무것도 깨지지 않았는지 확인하십시오.

각 단계 사이에 필요할 수있는 또 하나의 선택적인 작업 : f "이러한 변경은 이미 어제 완료되었습니다"라고 관리자 (프로젝트 소유자)에게 맡깁니다. 몇 번의 프로젝트를 거친 후, 그는 사양과 문서를 미리 얻도록 도울 수도 있습니다.

그러나 일반적으로 (특히 스크립트의 경우) 비즈니스 범위에서는 불가능합니다 (비용은 너무 높고 가치는 낮습니다). 한 가지 옵션은 임계 질량에 도달하고 시스템이 생산에서 벗어날 때까지 (예 : 새로운 시스템이 출시 될) 또는 경영진이이 모든 것이 가치가 있다고 결정하기 전까지는 변경을 수행하지 않는 것입니다.

추신 : 다른 설정을 가진 5 명의 클라이언트에 사용 된 하나의 코드를 기억합니다. 그리고 각각의 변경 (새로운 기능)은 "어떤 부분이 사용되는지"와 "구성 클라이언트가 무엇을 가지고 있는지"를 생각하여 아무 것도 제동하지 않고 코드를 복사하지 않아야했습니다. cvs를 프로젝트에 설정하고 스펙을 작성하면이 사고 시간이 거의 0으로 줄어 듭니다.

소스 코드를 인쇄하고 읽어보십시오. 특히 큰 경우에는 선택된 부분 만 인쇄하여 이해하기 쉽고 필요한만큼 메모 / 의견을 작성하십시오.

실행 시작부터 시작하여 프로그램을 추적하십시오. 코드베이스의 특정 부분에 할당 된 경우 해당 부분 내에서 실행을 추적하고 어떤 데이터 구조가 사용되는지 파악하십시오.

객체 지향 언어를 사용하는 경우 일반 클래스 다이어그램을 작성하십시오. 이것은 당신에게 좋은 개괄적 인 개요를 줄 것입니다.

불행히도 결국에는 가능한 많은 코드를 읽어야합니다. 운이 좋으면 이전 프로그래머는 가능한 한 많은 문서를 작성하여 진행 상황을 이해하는 데 도움을줍니다.

새로운 코드베이스를 배울 때 가장 먼저해야 할 일은해야 할 일, 사용 방법 및 사용법에 대해 배우는 것입니다. 그런 다음 아키텍처 문서를 살펴보고 코드가 어떻게 배치되는지 알아보고이 시점에서 데이터베이스가 어떻게 나타나는지 살펴보십시오. 동시에 아키텍처를 배우는 것은 프로세스 흐름이나 사용 사례 문서를 검토하기에 좋은시기입니다. 그런 다음 큰 그림을 이해 한 후에는 다이빙을 시작하고 코드를 읽기 시작하지만이 코드에서 수행중인 작업과 관련된 코드 만 모든 코드를 읽으려고 시도하지 마십시오. 코드가 X를 수행하는 방식보다 X를 수행하는 위치를 아는 것이 더 중요합니다. 코드는 항상 코드를 찾을 수 있는지 알려줍니다.

코드를 배우는 것 이상의 목표없이 코드를 뛰어 들고 읽으려는 것은 일반적으로 비생산적이며, 작은 변경을 직접 수행하거나 다른 사람의 변경 코드를 검토하는 것은 시간을 훨씬 더 생산적으로 사용하는 것으로 나타났습니다.

코드베이스가 큰 경우 현재 작업중인 부분에주의를 집중하십시오. 그렇지 않으면 압도 감을 느끼며 머리가 터질 수 있습니다. 높은 수준의 개요가 유용하다고 생각하지만 (사용 가능한 경우) 디버거에서 프로그램 흐름을 따르는 데 많은 시간을 소비 할 가능성이 있습니다. 응용 프로그램의 개요를보고 사용 방법을 확인하는 것이 좋습니다. 따라서 코드가 어떻게 / 무엇 / 왜 사용되는지 이해할 수 있습니다.

나는 일반적으로 문제 영역이 어디 있는지 알려주기 위해 코드에서 일종의 코드 복잡성 도구를 실행합니다. 점수가 높은 영역은 업데이트하기가 매우 어렵습니다. 예를 들어, 나는 순환 스케일에서 450 점을받는 함수를 만났다. 충분히, 수백 개의 IF. 그것을 유지하거나 변경하기가 매우 어렵습니다. 따라서 최악의 상황에 대비하십시오.

또한 기존 개발자, 특히 시스템에서 작업 한 경우 기존 개발자에게 질문하는 것을 두려워하지 마십시오. 당신의 내면의 생각을 스스로 유지하고 문제 해결에 집중하십시오. 다른 개발자를 화나게 할 수있는 의견은 피하십시오. 결국, 그것은 자신의 아기 일 수 있으며 아무도 자기의 아기가 못 생겼다는 말을 좋아하지 않습니다.

작은 단계 만 수행하면 아무리 작은 코드 변경이라도 큰 영향을 줄 수 있습니다.

프로그램 코드 흐름을 생각해내는 것이 도움이되므로 변경하는 경우 종속성 검색을 수행하여 어떤 메서드 / 함수가 무엇을 호출하는지 확인할 수 있습니다. 방법 C를 변경한다고 가정하십시오.

하나의 메소드 / 함수 만 C를 호출하면 꽤 안전한 변경입니다. 100 개의 메소드 / 함수가 C를 호출하면 더 큰 영향을 미칩니다.

코드베이스가 잘 설계되고 작성되고 유지되기를 바랍니다. 그렇다면 이해하는 데 약간의 시간이 걸리지 만 결국 조류가 바뀔 것입니다.

그것이 큰 진흙 공이라면, 당신은 그것의 내부 작용을 결코 이해하지 못하거나 이해하고 싶을 수도 있습니다.

내가하는 일 ...

1) 소스 모니터 와 같은 소스 분석 도구 를 사용하여 다양한 모듈 크기, 복잡성 메트릭 등을 결정하여 프로젝트에 대한 느낌을 얻고 사소하지 않은 영역을 식별하십시오.

2) Eclipse 에서 코드를 위에서 아래로 뚫습니다 (참조 등을 탐색 할 수있는 편집기가 있어야 함). 코드 진행 상황과 코드베이스의 위치를 ​​알 수 있습니다.

3) 때때로 Visio 에서 다이어그램을 그려서 아키텍처를 더 잘 파악할 수 있습니다. 이것은 프로젝트의 다른 사람들에게도 도움이 될 수 있습니다.

이것은 많이 일어난다. 오픈 소스 플랫폼에서 작업을 시작하기 전까지는 코드에 몇 가지 '질투'가 있다는 승인으로 시작하지 않은 작업을 시작한 것으로 생각하지 않습니다.

단계 디버거와 많은 강점으로 먼 길을 갈 수 있습니다. 불행히도 종종 큰 진흙 덩어리를 배우는 데 시간과 경험이 필요하며 수년이 지난 후에도 아무도 모르는 하위 ​​시스템이있을 수 있습니다.

진흙 공에 물건을 바꾸기 전에 단위 테스트를 작성하는 것이 좋습니다. 그리고 테스트를 통과하기에 충분한 코드 만 변경하십시오. 리팩토링 할 때는 사전에 단위 테스트를 추가하여 리팩토링으로 비즈니스 기능이 중단되지 않았 음을 알 수 있습니다.

페어 프로그래밍은 옵션입니까? 다른 사람이 아이디어를 튕겨내는 것은 그 정도의 불쾌감을 처리하는 좋은 아이디어입니다.

중복을 제거하기 위해 사용하는 절차는 다음과 같습니다.

• 중복에 대한 표준 주석 접두사를 선택합니다 ( [dupe]댓글 표시 바로 뒤에 사용 합니다).
• 복제 절차에 사용할 이름에 대해 팀과 함께 사양을 작성하십시오.
• 1 라운드 : 모두가 일부 파일을 가져 와서 [dupe][procedure_arbitrary_name]복제 된 프로 시저 앞에 추가 합니다.
• 두 번째 라운드 : 모든 사람은 절차 또는 절차의 하위 집합을 취하고 서로 다른 동일한 목적 구현의 유사성 순서를 나타내는 값을 할당합니다 (문자열은 다음과 같습니다 [dupe][procedure_arbitrary_name][n]).
• 세 번째 라운드 : 각 절차의 책임은 관련 클래스에서 다시 작성합니다.
• 넷째 라운드 : grep행복합니다!

가장 중요한 것 중 하나는 간단한 기능을 사용하고 생각할 수있는 가장 간단한 것을 선택하여 구현하는 것입니다. 위시리스트가 유지되는 경우 해당 코드를 사용하거나 코드베이스에 익숙한 사람에게 문의하여 기능을 제안하도록하십시오. 일반적으로 이것은 5 ~ 20 LOC로 변경 될 것으로 예상합니다. 중요한 점은 매우 멋진 기능을 추가하는 것이 아니라 코드 기반으로 작업하고 전체 워크 플로우를 진행한다는 것입니다. 당신은해야 할 것

1. 수정중인 구성 요소를 이해하기위한 코드 읽기
2. 코드를 변경하고 주변 시스템에 미치는 영향을 이해하십시오.
3. 변경 사항을 테스트하고 구성 요소가 서로 상호 작용하는 방식을 식별
4. 테스트 케이스를 작성하고 하나 또는 두 개의 테스트 케이스를 깨뜨려 서 수정하여 시스템의 불변성을 이해하십시오.
5. 물건을 만들거나 CI가 그것을 만든 다음 배송하십시오.

목록은 계속되지만 포인트는 이와 같은 미니 프로젝트가 시스템에 익숙해지기 위해 점검 목록의 모든 항목을 안내하고 생산적인 변경을 수행한다는 것입니다.

내가 추가하고 싶은 작은 것 :

최근에 이런 종류의 문제에 사용하기 시작한 도구 중 하나는 마인드 매핑입니다. 내 머릿속에서 어떻게 구현되는지에 대한 모든 세부 사항을 작성하려고하는 대신, 내가 겪고있는 시스템의 작동 방식을 설명하는 마인드 맵을 작성합니다. 그것은 실제로 무슨 일이 일어나고 있는지 그리고 내가 아직도 알아 내야 할 것을 더 깊이 이해하는 데 도움이됩니다. 또한 매우 정확한 규모로 변경해야 할 사항을 추적 할 수 있습니다.

엄청나게 많은 마인드 매핑 중에서 자유면을 사용하는 것이 좋습니다 .

문서가 없거나 스캔 한 문서가 없거나 오래된 문서입니다. 존재하는 모든 문서를 찾으십시오. 팀 저장소에있는 경우 사본을 작성하지 마십시오. 그렇지 않은 경우 관리자에게 요청하여 관리자에게 요청하여 조직 할 수있는 권한을 요청하십시오.

팀의 저장소에 모든 것을 넣고 용어를 추가하십시오. 모든 기지에는 전문 용어가 있습니다. 용어집에 문서화하십시오. 도구, 제품, 고객 별 등을위한 섹션을 만듭니다.

소프트웨어 환경 작성 문서를 작성 / 업데이트하십시오. 모든 도구, 단점, 설치 선택 등이 여기에 있습니다.

그런 다음 "ProductName"시작하기 문서 등을 업로드하십시오. 시간이 지남에 따라 마음이 흐르고 스스로 조직하십시오. 그런 다음 오래된 문서를 통해 최신 상태로 되돌립니다. 다른 개발자들은이 점에 감사하며 코드를 배우는 동안 고유 한 방식으로 기여할 것입니다. 특히 당신을 혼란스럽게하거나 잘못 명명되었거나 반 직관적 인 것들을 모두 문서화하십시오.

기울어 진 곡선이 끝나고 나면 설명서 업데이트에 대해 걱정하지 마십시오. 다음 새 사람이 그렇게하도록하세요. 그가 도착하면 그에게 당신의 일을 지적하십시오. 그가 계속 당신에게 답을 구할 때 대답하지 마십시오. 오히려 문서에 질문을 추가 한 다음 URL을 넘겨주십시오. 낚시대.

한 가지 부작용은 잊어 버렸을 때 몇 달 동안 스스로 참조 할 수있는 도구를 만들었 기 때문입니다.

문서화는 아니지만 관련 문제는 팀원이 수행하는 거의 기발하고 수동적 인 절차입니다. 배치, SQL 스크립트 등으로 자동화하고 공유하십시오. 결국 절차 적 지식은 새로운 환경에서 생산성을 얻는 관점에서 선언적 지식만큼 클 것입니다. 그것이 무엇이든,하지 마십시오. 오히려 스크립트를 작성하고 스크립트를 실행하십시오. 낚싯대가 다시칩니다.

이 주제에 대해 상당히 긴 글을 썼습니다. 여기 발췌가 있습니다

나는이 문제에 대해 오랫동안 생각했다. 개인 프로세스를 일반적인 프로세스로 작성하기로 결정했습니다. 내가 문서화 한 단계는 다음과 같습니다.

1. 어휘 시트 작성
2. 응용 프로그램을 배우십시오
3. 사용 가능한 설명서 찾아보기
4. 가정 만들기
5. 타사 라이브러리 찾기
6. 코드 분석

이 프로세스는 큰 데스크톱 응용 프로그램과 관련하여 작성되었지만 일반적인 기술은 여전히 ​​웹 응용 프로그램 및 더 작은 모듈에 적용 할 수 있습니다.

:에서 가져온 새로운 코드베이스를 배우기위한 과정

내가 공유 할 수있는 몇 가지 작은 팁이 있습니다.

기존 제품의 경우 집중적으로 테스트를 시작합니다. 작업을 지정 / 취득하면 특정 기능에 더 중점을 둘 것입니다.

• 다음 단계는 침입하여 탐색을 시작할 수있는 코드를 찾는 것입니다. 도중에 종속 모듈, 라이브러리, 프레임 워크 등을 찾을 것입니다.

• 다음 단계는 책임이있는 간단한 클래스 다이어그램을 만드는 것입니다 (CRC 카드처럼).

• 사소한 변경을 시작하거나 사소한 버그를 수정하여 커밋하십시오. 프로젝트의 작업 흐름을 배울 수 있습니다. 코드 만이 아닙니다. 종종 대형 제품은 승인 및 감사를 위해 일종의 장부 보관을해야합니다 (예 : 건강 관리 프로젝트).

• 이미 프로젝트를 진행중인 사람들과 대화하십시오. 아이디어, 생각을 표현하고 그 대가로이 프로젝트 작업에 대한 경험과 견해를 오랫동안 얻으십시오. 팀과 잘 지내는 데 도움이되기 때문에 이것은 매우 중요합니다.

내가 큰 코드 기반으로 뛰어 들어야했기 때문에 오랜 시간이 걸렸습니다. 그러나 최근 몇 년 동안 나는 새로운 개발자를 기존의 코드 기반을 가진 팀으로 만들기 위해 여러 번 시도했습니다.

그리고 우리가 성공적으로 사용했으며 IMHO에 의문의 여지없이 가장 효과적인 방법은 페어 프로그래밍입니다.

지난 12 개월 동안 우리는 팀에 4 명의 새로운 멤버를 가졌으며, 매번 새로운 멤버는 코드베이스에 대해 잘 알고있는 다른 멤버와 쌍을 이룰 것입니다. 처음에는 나이 많은 팀원이 키보드를 가지고있었습니다. 약 30 분 후에 우리는 키보드를 새로운 멤버에게 넘겨 줄 것이며, 그 멤버는 이전 팀 멤버의지도하에 일할 것입니다.

이 프로세스는 매우 성공적인 것으로 입증되었습니다.