많은 다른 파일을 가진 프로젝트를 다룰 때, 나는 부품들이 서로 어떻게 상호 작용하는지 항상 느슨하게 보인다. 작은 구성 요소를 독립적으로 이해하는 데 실제로 많은 문제가 없었지만 프로젝트의 복잡성이 증가함에 따라 진행중인 일에 대한 정신적 이해를 구성 할 수 없습니다. 메소드와 소스 파일 수가 증가함에 따라 OOP 프로젝트에서 특히 주목할 만합니다.
내 배경 : 저는 독학 웹 프로그래머입니다. 나는 빠르고 더러운 스크립트를 위해 주로 파이썬을 다루었지만 몇 가지 기본적인 장고 프로젝트 도 수행했습니다 . 나는 flask 과 같은 웹 프레임 워크를 좋아 한다. 단일 파일 레이아웃의 단순성에서 진행중인 일을 쉽게 추적 할 수 있기 때문이다.
이제 다른 사람이 개발 한 대규모 Zend Framework PHP 프로젝트와 상호 작용해야하는 상황에 처하게되었으며 수많은 파일로 확산 된 코드를 이해하려고 노력하는 데 압도당했습니다.
다른 사람이 개발 한 큰 코드 기반을 이해하는 데 유용한 기술과 프로세스는 무엇입니까? 더 큰 그림을 파악하는 데 도움이되는 특정 다이어그램이 있습니까?
답변
큰 코드 기반을 이해하는 비결은 모든 코드 기반을 이해하려고 시도하지 않는 것입니다. 특정 크기 후에는 머리 전체에 정신 모델을 담을 수 없습니다. 먼저 작업해야하는 모든 작업에 적합한 고정 점으로 시작한 다음 거기서 시작하여 필요한 부분 만 학습하고 나머지 부분은 광고 된대로 작동한다고 신뢰합니다. 재귀를 이해하는 것과 같습니다. 머리 전체를 쌓으려고하면 뇌가 폭발합니다.
Grep, 디버거 및 인텔리전스가 여기에 있습니다. 함수가 어떻게 호출되는지 모르는 경우 중단 점을 설정하고 스택 추적을 진행하십시오.
주목해야 할 또 다른 사항은 큰 코드 기반이 어디에도 생겨나지 않는다는 것입니다. 크기가 클수록 경험이 많은 프로그래머가 많으므로 시작 위치를 구체적으로 지정하십시오. “새로운 결제 제공 업체를 추가해야합니다. 코드에서 어디를보아야합니까?”와 같은 질문을하십시오. 전체 코드베이스를 이해하려고 노력하는 대신 해당 작업에만 집중하면 익숙해 질 것입니다.
답변
바로 가기가 없습니다. 당신은 그것을 통해 고통을해야합니다.
다이어그램을 얻는 방법에 대한 질문에 대답하려면 doxygen을 사용하십시오 . AFAIK는 PHP와 함께 작동합니다.
더 일반적으로, 나는 새로운 코드베이스를 만날 때 대략 다음 단계를 밟습니다.
-
사용자 관점에서 무엇을하는지 이해하십시오. 실제로 응용 프로그램을 고급 사용자처럼 사용할 수 있습니다. 실제 최종 사용자가 어떻게 작업하는지 이해하십시오. 이것은 그들이하는 일에 대한 확실한 이해를 얻을 때까지 앉아 있어야 할 수도 있습니다.
-
가능하면 원래 개발자와 대화하십시오. 처음에는 최종 사용자 경험에 의해 건축 질문이 자극됩니다. 나중에, 엣지 케이스 및 세부 사항에 대한 구현 질문이 있습니다. 개발자로부터 답변을 얻을 수 있다면 어떤 의견이나 문서보다 훨씬 도움이 될 것입니다.
-
사용중인 프레임 워크에 대해 알아보십시오. 최소한 프로덕션 응용 프로그램으로 들어가기 전에 해당 프레임 워크를 사용하여 “hello world”또는 다른 간단한 응용 프로그램을 만들 수 있어야합니다.
-
전체 배포 프로세스를 파악하십시오 (원래 개발자가 손을 잡고있는 동안 가장 잘 수행됨). 현재 코드베이스를 가져 와서 빌드 / 테스트 / 검증 / 제품 환경을 통해 배포 할 수 없다면 건배입니다. 가장 작은 변화조차도 모든 배포 과정을 뛰어 넘을 필요가 있으므로이 부분을 즉시 내려 놓으십시오. 이렇게하면 앱에서 사용하는 모든 멋진 서버, 데이터베이스, 서비스 및 스크립트를 소개하게되며 “어디에 있는지”를 알게됩니다.
-
기능 테스트 (있는 경우)를 파악하십시오. 일이 제대로 진행되고 있는지 어떻게 알 수 있습니까? 응용 프로그램의 관리 및 공급을 위해 운영 담당자는 무엇을해야합니까?
-
앱의 로그를 이해하십시오. 필자는 PHP로 작업 한 적이 없지만, 심각하게 추측하여 심각한 PHP 응용 프로그램에 일종의 로깅이 있다고 말할 것입니다. 로그를 이해하면 디버깅 문제가 생길 때 좋은 출발점이 될 것입니다.
—- 여기까지는 코드베이스를 자세히 살펴 보지도 않았다는 점에 유의하십시오. 이 많은 당신도 코드를 보지 않고 큰 프로젝트에 대해 배울 수는. 물론 어느 시점에서 코드에 익숙해 져야합니다. 다음은 나를 도와줍니다.
-
다이어그램의 경우 doxygen 은 콜 그래프 및 기타 관계를 생성하는 훌륭한 도구입니다. PHP 기능이 있습니다! doxygen을 시도하지 않았다면 절대로 회전시켜야합니다. 프레임 워크 내부의 코드에 대한 이해가 쉽지만 보장 할 수는 없지만 도움이 될 수 있습니다. 독창적 인 개발자들은 종종 독창적으로 생성 된 코드 문서를 제시 할 때 충격을받습니다. 좋은 소식은 실제로 기억력을 자극하고 더 잘 도울 수 있다는 것입니다.
-
일련의 단위 테스트가있는 경우 자세히 살펴보면 응용 프로그램의 내부 작업에 대한 창이 제공됩니다. 이것들은 또한 변경하는 동안 당신이 도입했을 수있는 버그를 찾는 첫 번째 장소가 될 것입니다.
-
IDE 책갈피는 코드베이스에서 핫스팟에 태그를 지정하는 데 매우 중요합니다. 그것들을 빠르게 토글 할 수 있으면 이해가 증진 될 것입니다.
-
최신 버그 보고서와 그 해결 방법을 읽는 것도 핫스팟을 이해하는 데 유용하며 코드베이스의 가장 관련성있는 부분을 빠르게 파악하는 데 도움이됩니다.
답변
요청에 따라 답변으로 내 의견이 있습니다.
다른 사람들의 코드로 작업 할 때 정적 구조에 대한 개요를 제공하기 위해 UML 클래스 다이어그램을 만들거나 가능한 경우 생성하는 경향이 있습니다. 시각적 다이어그램은 나중에 다시 돌아가서 이미 수업의 맥락을 잊었을 때 특히 도움이됩니다. 가끔 collaborateurs 사이의 상호 작용을 일렬로뿐만 아니라 동적 인 동작을 위해 그것을 할,하지만 난 그렇게하지 않는 것을 자주.
코드베이스에 테스트 (통합 또는 단위)가 포함 된 경우 때때로 검사 할 가치가 있습니다.
답변
실제로 새로운 클라이언트가 다른 개발자가 남긴 제품을 개선해야하는 이번 주 과정에서이 작업을 시작하려고합니다. 수행해야 할 단계는 다음과 같습니다.
a) 사용 된 프로그래밍 프레임 워크를 식별하여 응용 프로그램의 흐름을 파악하는 데 도움이됩니다.
b) 공통 서비스 식별-로깅, 예외 처리, MVC, 데이터베이스 연결, 감사,보기 (페이지 생성). 우리가 가장 많이 사용하는 부분이기 때문입니다.
c) 응용 프로그램에서 일반적인 사용자 흐름을 실행 한 다음 코드가 어떻게 배치되는지에 맞게 조정하십시오.
d) 변경을 시도하고 어떻게 나오는지보십시오. 변경을 시작할 때까지 코드가 여전히 블랙 박스이기 때문에 이것이 가장 큰 단계입니다.
다음 2 주 동안 어떤 아이디어를 얻을 수 있는지 알려 드리겠습니다
답변
내 생각은 문서를 읽어야한다는 것입니다. 해커가 “코드는 문서입니다”라고 말하고 문서를 작성하지 않는 변명으로 사용하지만 잘못되었습니다. 수백만 줄의 코드로 구성된 방대한 소프트웨어 프로젝트 인 Linux 커널을 살펴보십시오. 책을 읽지 않고 책을 읽지 않고서도 실제로 새로운 사람이 나오지 않을 것이라고 생각합니다. 작업중 인 코드가 문서화되어 있지 않거나 (작은 프로젝트 인 경우 주석이 달린) 코드가 아닐 수도 있습니다.
답변
제로 문서가없는 정말 큰 무언가로 작업하고 있다면 (나도 거기에 있었지만 거칠 었습니다!), 내가 찾은 것은 작업중 인 부분을 분리하는 데 도움이됩니다. 코드의 해당 부분에서 데이터 / 이벤트 / 메시지 / 상호 작용이 해당 장치로 어떻게 들어오고 나가는 지 알아냅니다. 즉, 인터페이스를 리버스 엔지니어링하십시오. 받아 적어. 다음에 다른 장치에서 작업 할 때 (먼저 작업 한 장치와 통신하는 경우 보너스) 동일한 작업을 수행하십시오. 모든 문서를 보관하십시오. 몇 달이 지나면 사물이 어떻게 흘러가는지에 대한 멋진 그림을 보게 될 것입니다.
작업중인 하나의 소형 장치의 인터페이스를 파악하고 나중에 참조 할 수 있도록 기록하십시오. 시간이 지남에 따라 대부분의 작동 방식을 하나로 묶습니다. 프로그램이 수행하는 작업을 찾고 해당 메시지의 흐름을 추적하십시오. 예를 들어, 시스템이 일부 입력 네트워크 메시지를 가져 와서 출력 메시지를 보내는 경우 모든 세부 사항에 대해 걱정하지 않고 해당 메시지가 시스템을 통해 어떻게 흐르는 지 추적하십시오.
답변
내가하는 일은 java에서 UML로 되돌려 진 모든 파일에서 단일 UML 모델을 만드는 것입니다. 이 접근법은 모델이 더 이상 프로젝트의 추상적 인 관점이 아니라 프로젝트 자체가 MOF 및 UML에 완전히 매핑되었음을 의미합니다.
내가 얻는 것은 분류 자 등으로 구성된 패키지로 구성된 여러 하위 모델로 구성된 큰 단일 모델입니다. 다중 프로젝트 수준에서 작업하면 다중 프로젝트 수준에서 각 분류 자 및 메서드 호출을 추적 할 수 있습니다. 같은 방법으로 프로젝트 A에서 하나의 분류자를 호출하고 프로젝트 B에서 다른 분류자를 호출 할 수 있습니다. 프로젝트의 전체 구조를 보는 유일한 방법은 두 가지를 동시에 뒤집는 것입니다. 구성 요소 다이어그램을 작성할 시간이 없으며 정보가 실제로 정확하지 않습니다. 나는 컴퓨터가 전체 프로젝트를 취소하도록 요청하는 것을 선호합니다. 팀과 반복 할 때마다 역순으로 모든 다이어그램이 즉시 업데이트됩니다. 리버스 엔지니어링은 점진적이고 Java에서 UML ID 맵핑을 사용합니다. 각 자바 요소는 리팩토링 되더라도 모든 프로젝트 수명 동안 동일하게 유지되는 단일하고 고유 한 MOF 요소에 매핑됩니다. 그렇게하면 UML 모델링에 더 이상 제한이없고 매우 크고 복잡한 프로젝트 모델링이 가능합니다. 귀하의 정보를 위해 5 000 000 라인 이상의 OOP 코드가있는 프로젝트로 작업합니다. 내 모든 프로젝트가 올바르게 반전되어 그래픽 탐색이 가능합니다
UML 모델에서 항상 최신 상태의 뷰를 작성할 수 있으므로 클래스 다이어그램 만 사용합니다. 매우 복잡한 프로젝트를 모델링 할 수도 있습니다.