답변:
코드로 시작합니다. 별도의 설계 문서가있는 경우 잘못되었거나 오해 될 가능성이 있습니다. 따라서 코드를 통한 간단한 흐름을 추적하여 시작합니다. 웹 애플리케이션 인 경우 요청 또는 요청 시퀀스 일 수 있습니다. 일단 그렇게하면 더 많은 이해를 돕기 위해 일종의 골격이 생깁니다. 그런 다음, 돌아가서 디자인이나 다른 문서를 읽을 수 있지만, 그 시점에서 그것들을 관련시키고 검증 할 구체적인 내용이 있으므로 더프 정보를 감지 할 수 있습니다. 아니면 코드를 읽거나 테스트 케이스 등을 계속 수행 할 수도 있습니다.
나는 더 높은 수준에서 시작합니다. 설명서를 사용하는 사용자가있는 경우-사용 설명서 또는 안내서. 실패하면 요구 사항 사양을 살펴보고 소프트웨어가 수행해야 할 작업에 대한 아이디어를 얻습니다. 디자인을보고 코드 파일에 매핑하려고합니다. 바라건대 이것들은 합리적인 방식으로 폴더로 구성됩니다. 그런 다음 디자인의 일부를 선택하고 파일로 이동하여 코드의 흐름을 따르지 않고 세부 사항에 너무 신경 쓰지 않습니다.
개발자 시스템을 설정하는 것으로 시작합니다. 문서화 된 절차를 사용합니다. 이를 통해 가방에서 고양이가 실제로 얼마나 많은 문서를 동기화 할 수 있는지 알 수 있습니다.
또한 종속성이 무엇인지 알려줍니다. 이것은 중요하다.
이제 개발자 설정이 완료되었으므로 설정 문서를 수정 사항으로 표시하여 버전을 만듭니다. 나는이 단계 전체에 걸쳐 질문을합니다.
이제는 사용 설명서에서 소개 연습을 수행했습니다. 이것은 시스템이 실제로 무엇을하는지 대략적으로 말해줍니다.
이제 시스템에 대한 부분적인 단서가 있으며 디자인 문서를 읽었습니다.이 문서는 지금까지 문서가 얼마나 잘못되었는지에 비례합니다.
실제 행동 문서에 도달하면 코드를 살펴보고 실제로 무엇이 있는지 볼 수 있습니다. 그들은 결코 줄을 서 있지 않지만 이제는 얼마나 믿을 지 압니다.
그런 다음 "todo"및 "fixme"주석에 대한 IDE 출력을 살펴 봅니다. "버전 2.0의 수정 사항"과 같은 것들도 팁입니다.
따라서 진실성을 배우는 것이 중요하며 사람들이 지적한대로 별도의 디자인 문서가 최신 정보 나 정확하지는 않지만 사람들이 특정 시점에서 생각한 내용을 알려줍니다. 물론, 그 사람들은 아마도 심문을하지 않을 것입니다.
디자인을 시작하여 프로젝트 개요를 얻고 세부 사항을 살펴보기 전에 주요 기능 및 / 또는 구조를 이해하려고합니다.
복잡한 소프트웨어는 마치 새로운 개발 프로젝트 인 것처럼 거의 접근 할 것입니다. 비전, 맥락, 범위, 이해 관계자와 같은 큰 아이디어로 시작하십시오. 일부 사용자 설명서를 읽고 사용 방법에 대한 아이디어를 얻으십시오. 가능하면 소프트웨어를 사용하여 일부 사용자 교육을받습니다. 그런 다음 요구 사항과 설계 문서를 살펴보고 그것이 어떻게 높은 수준에서 작동하는지에 대한 아이디어를 얻으십시오. 디자이너가 여전히 주변에 있다면 이야기하십시오. 다른 관점에서 시스템 아키텍처를 살펴보십시오. 여기에서 핵심 기능을 파고 코드를 살펴보고 필요에 따라 요구 사항과 디자인으로 돌아갑니다. 코드를 볼 때 소프트웨어를 실행하여 실제로 작동하는지 확인하십시오. 그 동안 나중에 참조 할 수 있도록 요약 문서를 컴파일하십시오. 그것이 어떻게 작동하고 잘 어울리는 지에 대해 꽤 좋은 아이디어가 나올 때까지 가지만 작업 할 부품에 집중하십시오. 이제 전체 시스템 또는 최소한 적용 할 수있는 부품에 대한 전반적인 이해가 가능합니다.
물론, 실제로는 더 큰 프로젝트에서 손이 더러워지기 전에이 모든 과정을 거치지 않아도됩니다. 그러나 이것이 나에게 달려 있다면 그렇게 할 것입니다.
코드 자체와 디자인 문서 사이를 오가며 작업해야합니다.
코드 나 디자인에서 시작할 수 있으며 실제로 중요하지 않습니다. 건강하고 혼란 스러울 때까지 코드를 읽은 다음 디자인 문서를 확인하십시오. 또는 디자인 문서를 읽고 높은 수준의 그림을 얻은 다음 코드를보고 모양을 확인하십시오. 코드 작업을하는 한 거의 무한정 반복하십시오.
디자인 문서는 거의 항상 구식이며 여러 가지면에서 잘못되었습니다. 그러나 이러한 요점을 명심하는 한 오래된 문서는 여전히 과거의 어느 시점에서 저자의 마음을 이해하는 데 도움이됩니다. 많은 높은 수준의 문제와 우려 사항은 여전히 유효하며, 저자가 원래 의도했던 위치에 대한 날짜가 표시된 사진조차도 코드가 어디에 있는지에 대한 정보를 더 빨리 이해할 수있을 것입니다. 가다.
코드와 디자인을 진행하면서 오늘날 코드에 대한 이해를 설명하는 문서를 직접 만드십시오. 어쩌면이 문서들은 간단한 스케치 일 수도 있고 위키에 글을 쓰는 것일 수도 있고 다른 것일 수도 있습니다. 너무 복잡하게 만들지 마십시오. 30 페이지 단어 문서가 없습니다. 아이디어를 내려 놓으면 자신의 생각이 크게 명확 해집니다.
디자인 문서부터 시작하겠습니다. 특히, 사양-보고있는 것의 의도를 알려줍니다.
가능하면 디자인 노트와 문서를보고 그것이 어떻게 이루어 졌는지, 사고 과정, 관련 사람들의 스타일과 성격에 대한 일반적인 맛을 얻습니다.
가능하다면 나는 그 일을 한 사람들과 대화를 나눈다-어떻게 하는가? 어떻게? 왜? 시체는 어디에 묻혀 있습니까?
개발자들 사이에서 코드를 뛰어 넘는 경향이 있습니다 : "이 코드를 보여 드리겠습니다." 이것은 그들에게는 좋지만 저의 요구를 가로채는 경향이 있습니다. 저수준의 물건에 대한 맥락을 제공하는 높은 수준을 이해하는 것입니다.
그것은 엄청난 양의 두뇌 능력을 사용하여 완전한 맥락에서 약간의 코드를보고 의미있는 것을 이해합니다. 따라서 가능한 경우 개발자가 PRINCIPLE, 구조, 단위, 모듈에 대해 이야기하게되면 모든 것이 작업에 대한 감사로 이어집니다.
그래야만 코드에 들어 가려고 노력할 가치가 있습니다.
큰 계획에서 코드를 보는 것은 0과 1로 가득 찬 페이지를 보는 것과 같습니다. 의미가 있지만 알아내는 데 시간이 오래 걸립니다. 볼 위치와 의미있는 부분을 맛보면 검색 공간을 좁히는 데 도움이됩니다.
doco가없고 사람들이없고 코드 만있을 때 말한 모든 것은 코드를 보는 것 외에는 아무것도 없습니다.
이 경우 일반적으로 느리게 읽는 것으로 이해하지 못하고, 빠른 패스를 수행하고 모든 것을 읽습니다. 때때로 이것은 단지 파일을 열고 page-down 키를 눌러 앉아 있습니다. 이렇게하면 큰 그림에 대한 놀라운 감사를 얻을 수 있습니다. (어떤 경우에는 실행 파일을 문자열 덤프하고 파일을 트롤링하여 서명과 패턴을 찾고 있습니다. 지난 20 년 동안 놀랍도록 유익했습니다.)
테스트부터 시작합니다. 단위 테스트와 통합 테스트가 잘 작성된 경우 사용 사례를 설명합니다. 그것들이 잘 작성되지 않았거나 전혀 작성되지 않은 경우 (슬프게도 이것은 대부분의 경우입니다), 코드의 진입 점으로 시작하여 디자인과 일치시킵니다.
그런 다음 진입 점을 조사한 후 찾은 트리에서 발견 한 각 유스 케이스에 대한 테스트를 작성하여 코드를 조사하고 코드 범위 유틸리티를 사용하여 누락 된 항목을 확인합니다. 이 테스트는 코드 작동 방식을 정확하게 알려줍니다.
나는 항상 내가 바라는 것에 가치를 더하려고 노력합니다. 테스트 작성, 코드 정리, 큰 (20 줄 이상) 함수 리팩토링
문서를 만드는 것만으로는 코드와 상호 작용하지 않으므로 코드에 실제 가치를 추가하지 않습니다.
먼저 디자인하고 코드를 작성하고 원하는 경우 하향식으로 작업해야하므로 모든 수준의 컨텍스트를 이해해야합니다.
그러나 보고서 또는 계산 수정과 같이 매우 구체적인 변경을 수행 해야하는 경우 코드를 살펴보십시오.
보다 구체적으로, "디자인 우선"접근 방식은 다음과 같습니다.
도메인 모델이있는 경우 도메인 모델로 시작합니다. 아무 것도 없으면 기본 모델을 구축합니다 (좋은 출발점은 데이터 모델입니다). 응용 프로그램의 "용어집"과 객체 (클래스) 간의 관계를 정의합니다.
그것은 "어플리케이션이 어떤 객체를 다루는가"를 응용하여 보여줍니다.
그런 다음 유스 케이스 모델을 찾아 애플리케이션에서 "어떤 프로세스가 수행되는지"를 찾으십시오. 프로세스 맵이 하나 인 경우 프로세스 순서를 보여주는 프로세스 맵을 선호합니다.
그런 다음 응용 프로그램에 대한 멋진 그림을 가져 와서 변경 디자인을 진행할 수 있습니다.
그런데 위의 답변은 비즈니스 응용 프로그램과 관련이 있습니다.
코드는 거짓말하지 않습니다. 프로젝트의 개요를 먼저 이해하여 프로젝트의 기능을 이해 하는 것이 좋습니다. 그러나 프로젝트가 어떻게 작동하는지에 대한 자세한 이해를 얻는 것이라면, 적어도 나를 위해 코드를 보는 것은 각 클래스별로 보는 것을 제외하고 조각 퍼즐을 하나씩 보는 것과 같습니다. 직소 퍼즐 조각. 코드가 잘 구조화되어 있으면 클래스의 기능을 조사하지 않고도 클래스 이름에서 패턴이 형성되는 것을 볼 수 있습니다. 대부분의 경우 코드에서 힌트와 힌트를 얻을 수 있습니다.
마지막으로, 당신은 프로그램이 무엇을하는지에 대한 결정적인 아이디어, 완성 된 직소 퍼즐을 얻습니다. 문서가 불완전하거나 부정확 할 수 있지만 코드는 절대 존재하지 않습니다. 이 모든 것은 각 개별 방법이 무엇을하는지 파악하지 않고도 할 수 있습니다. 모든 사람이 이런 식으로 프로젝트에 대해 배울 수있는 것은 아니지만, 자주 프로젝트를 수행하면 몇 시간 동안 공부하면서 중간 크기의 응용 프로그램의 요지를 얻을 수 있다는 것은 말할 것도없이 더 쉽습니다. 비록 모든 것이 선호에 달려 있다고 생각합니다.
가장 중요한 모듈 / 응용 프로그램의 코드를 본 후 : 코드를보고 디자인의 우수성을 확인할 수 있습니다.
예:
재무보고에 대한 웹앱의 응용 프로그램 관리 작업을 수행해야합니다.
메시지, 시작 및 종료 응용 프로그램 (db의 가능한 잠금),보고해야 할 데이터 등의 마스터 프로세스에 대한 코드를 읽은 후 (예 : 가스 저장에서 마스터 프로세스는 공급 및 주입을 통해 고객의 저장 영역에서 가스 재고 계산; 보조 프로세스는 이전에 계산 된이 데이터에 대한 청구입니다.)