다른 사람의 코드 작업 [폐쇄]

나는 1 년의 코딩 경험이 거의 없다. 작업을 시작한 후에는 대부분 기존 코드 위에 새 기능을 추가하거나 기존 기능을 수정하여 다른 사람의 코드 작업을하고있었습니다. 실제 코드를 작성한 사람은 더 이상 회사에서 작동하지 않습니다. 그의 코드를 이해하고 내 작업을 수행하는 데 어려움을 겪고 있습니다. 코드를 수정하려고 할 때마다 작동 기능이 엉망이되었습니다. 다른 사람의 코드를 작업하면서 어떤 점을 명심해야합니까?

코드에 단위 테스트가 있습니까? 그렇지 않으면, 나는 강하게 당신이 그들을 추가 시작하는 것이 좋습니다. 이렇게하면 테스트 실패로 새로운 기능 / 버그 수정을 작성한 다음 테스트가 통과 한 코드를 수정할 수 있습니다. 빌드 한 것들이 많을수록 추가 된 코드가 다른 것을 깨뜨리지 않았다는 자신감이 커집니다.

완전히 이해하지 못하는 코드에 대한 단위 테스트를 작성하면 해당 코드를 이해하는 데 도움이됩니다. 물론 기능 테스트가없는 경우 추가해야합니다. 나는 OP 질문에 이미 존재했다는 인상을 받았다. 그 시점에서 내가 틀렸다면 이러한 기능 테스트가 첫 번째 단계입니다.

Eagle76dk는 하게 좋은 점 Eagle76dk의 게시물에 대한 자세한 내용 -이 일을 위해 보드에 관리자보기에 대한합니다.

또한 이러한 테스트를 작성할 때 메소드가 코드 동작이 아니라 달성하려고 시도한 비즈니스 동작을 검증 할 수 있도록 테스트를 작성하도록 권장합니다. 또한 코드에 표시되는 비즈니스 동작이 올바른 것으로 가정하지 마십시오. 응용 프로그램에서 수행해야하는 작업을 알려줄 수있는 사람이있는 경우 코드에서 알 수있는 것보다 더 가치있는 경우가 많습니다.

단위 테스트를 언급 한 또 다른 답변 외에도 모든 것이 버전 관리에 있는지 확인하여 변경 사항을 쉽게 되돌릴 수 있도록 제안합니다. 코드를 유지 관리하기 쉽도록 약간만 변경하면됩니다.

제 생각에는 다른 사람의 코드를 배우는 가장 빠른 방법은 (특히 설명에 따라 변경 사항이 예기치 않은 동작을 유발할 때) 디버거를 사용하여 코드 를 단계별로 실행하는 것 입니다.

프로그램의 주요 루프 / 주요 메소드 인 것으로 단계별로 시작하십시오. 스텝 인 및 스텝 아웃 기능을 사용하여 다양한 방법의 기능을 확인하십시오. 이것은 코드의 일반적인 구조를 알려줄 것입니다.

그 후, 프로그램의 다른 부분을 심층적으로 학습하고 학습함으로써 나누고 정복하십시오. 대부분의 디버거에서는 변수 와 현재 값을 연구 할 수 있습니다 . 그들이 어떻게 그리고 언제 바뀌는 지 연구하십시오.

관심있는 동작을 트리거하는 메소드에 중단 점 을 설정하십시오 . 예를 들어 프로그램에서 텍스트를 변경하려고 할 때 텍스트가 원래 값으로 계속 변경되는 경우 텍스트가 변경되는 모든 위치에 중단 점을 설정하거나 이러한 변경 사항을 하나의 단일 방법으로 이동하십시오. 콜 스택 을 사용 하여이 메소드가 호출 된 위치 등을 확인하십시오.

코드 행을 변경 하면 다른 위치에서 예기치 않은 변경이 발생하는 경우 해당 행에 중단 점을두고 예를 들어 범위 내에서 현재 변수의 값을 확인하거나 단계를 사용하거나 호출 스택을 통해 어디서 발생하는지 확인하십시오. 전화가왔다.

이 작업을 많이 수행하면 코드 구조를 놀랍게도 빠르게 배울 수 있습니다. 나는 당신이 처음 프로그래밍 작업을 시작한 것처럼 몇 년 전에 쓰여졌 고 수년 동안 많은 사람들에 의해 변경된 많은 코드를 가지고 시작했습니다. 이 코드는 다른 사람들이 동시에 작업을 수행 한 이후로만 작성된 것이 아닙니다. 그 시점에서 모든 것을 다시 쓸 수 없었습니다. 모든 코드에 대한 테스트를 작성하는 데 몇 달 또는 몇 년이 걸렸습니다. 디버거가 실제로 저를 구했습니다. 코드없이 코드를 어떻게 배울 지 모르겠습니다 ...

가장 먼저 명심해야 할 것은 코드를 작성하는 것보다 코드를 읽는 데 더 많은 시간이 소요된다는 것입니다. 다른 사람의 작업 방식, 즉 자신의 스타일과 문제에 대한 접근 방식을 이해하기 위해 시간을 보내십시오.

가능한 한 기존 스타일을 채택하십시오. 그렇지 않으면 남자가 두 배로 조정해야합니다.

다른 사람의 코드를 다루는 것은 예외가 아닌 표준입니다. 다른 사람이 어떻게 문제를 해결하거나 기능을 구현했는지 파악하는 데 능숙해야합니다. 일단 그렇게하면 그의 코드를 다루기가 더 쉬울 것입니다.

다른 사람의 코드가 악취가 났다고 가정하지 마십시오.

그러나 항상 의심하십시오.

그러나 다른 개발자의 코드를 이해하려면 시간이 걸립니다. 시스템의 여러 부분에서 기능이나 객체를 많이 사용할수록 더주의해야합니다. 증상에 더 가깝게 문제를 해결할 수 있다면 때로는 도움이 될 수 있습니다. 예를 들어, 데이터가 전달 된 후 다른 상황이 발생하기 전에 펜스의 문제 객체쪽에있는 다른 객체에서 들어오는 데이터를 정규화합니다.

한 가지를 바꾸면 다른 것이 예기치 않게 깨질 때 나쁜 징조입니다. 다른 숙련 된 개발자가 도움을 필요로하는 경우 문제를 일으키는 원인을 찾아 보도록 권장합니다. 최소한 디버그를 지켜 보는 몇 가지 항목을 선택할 수 있습니다.

이상적인 환경에서 특정 개발자가 작성한 모든 코드는 사용자가 예상 한 결과를 얻었는지 확인하기 위해 사용자가 실행하는 단위 테스트 및 사용 사례 스크립트와 같은 자동 도구를 사용하여 문서화되고 체계적으로 구성되며 이해하기 쉽게 테스트됩니다.

그러나 가장 먼저 배울 것은 이상적인 세계에 살지 않는다는 것입니다!

많은 개발자들이 코드를 제대로 문서화하지 않고, 비즈니스 로직과 관련이없는 코드를 섞은 경우, 유일하게 수행 할 수있는 유일한 테스트는 일반적인 사용 사례가 될 것으로 예상되는 것을 신속하게 실행하는 것입니다.

이와 같은 코드로 작업 할 때 가장 먼저해야 할 일은해야 할 일을 설정하는 것입니다. 의견이 있으면 힌트를 줄 수 있지만 의지하지는 마십시오. 많은 코더가 자신을 설명하는 데 능숙하지 않으며 내 의견을 남기더라도 의미가 없을 수도 있습니다. 그러나 회사의 유일한 코더가 아니라면 누군가 코드의 목적과 코드의 의도에 대한 기본 아이디어를 가지고 있어야합니다. 주위에 물어보세요!

당신이 단위 테스트를한다면, 그들은 당신의 인생을 훨씬 쉽게 만들 것입니다. 그렇지 않은 경우 코드베이스 학습의 일부로 이미 존재하는 코드에 대한 단위 테스트 작성이 필요할 수 있습니다. 일반적으로 이것은 기존 코드에 맞게 단위 테스트를 작성하면 코드가 그대로 작동한다고 생각하는 단위 테스트로 끝날 것입니다 (실제로 버그 인 행동을 가정하여 작성됩니다) 맞습니다), 그러나 최소한 그것은 당신에게 기준을 제공합니다. 나중에 옳다고 생각한 일부 동작이 실제로 잘못되었다는 것을 발견 한 경우 코드가 지금 제공하는 결과가 아니라 예상 결과가 무엇인지 테스트하기 위해 단위 테스트를 변경할 수 있습니다. 단위 테스트가 완료되면 변경을 수행하고 변경 사항에 따른 부작용을 평가할 수 있습니다.

마지막으로, 문서화되지 않은 코드를 처리 할 때 가장 좋은 리소스는 최종 사용자에게 문의하는 것입니다. 코드에 대해서는 아무것도 모르지만 응용 프로그램이 원하는 것을 알고 있습니다. 요구 사항 수집은 모든 프로젝트의 첫 단계이며, 개발 될 시스템의 잠재 사용자와 대화하는 것이 항상 중요한 부분입니다. 방금 이미 만들어진 새로운 프로젝트에 대한 요구 사항 캡처 단계를 수행한다고 생각하십시오.

잘 작성되고 잘 문서화 된 코드조차도 외부인이 이해하기 어려울 수 있습니다. 코드는 본질적으로 당시에 코드를 작성한 사람이 어떻게 생각하고 있었는지에 대한 표현이며 모든 사람은 고유 한 사고 과정을 가지고 있습니다. 약간 인내심을 갖고 배우는 법을 배워야합니다. 다른 사람의 사고 과정에 들어갈 수는 어렵지만 기존 코드를 유지 관리하는 프로그래머에게는 필수적인 기술입니다. 대부분의 코딩 (약 70 %)은 기존 코드 유지와 관련이 있기 때문에 배우는 데 중요한 기술입니다.

아, 그리고 문서화가 안되고, 테스트되지 않고 뒤죽박죽이 된 코드가 야기 할 수있는 고통을 보았으므로, 다음의 빈약 한 개발자에게 다가 가지 않을 것입니다. :) 전임자의 실수로부터 배우고, 코드를 잘 주석 처리하고, 모든 모듈에 명확하게 정의 된 책임이 있는지 확인하고, 먼저 TDD 방법론에 대해 작성하는 포괄적 인 단위 테스트 세트가 있는지 확인하십시오. 적어도 개발중인 코드와 함께.

작성하지 않은 코드를 읽는 기능은 코드를 작성하는 것보다 훨씬 가치있는 기술이라는 점을 명심하십시오. 불행히도, 이것은 학교에서 널리 과소 평가되고 있습니다.

내가 말하려는 것은 처음 읽을 때 항상 코드를 이해하지 못하는 것이 정상이라는 것입니다 (처음으로 완벽한 코드를 작성하지 않는 것이 정상인 것처럼). 외국 코드를 ​​얻는 데 시간이 걸린다는 점을 받아들이면 추가 노력을 기울이지 않아도됩니다. 작은 요약 :

• 단위 테스트는 이상적이지만 항상 현실적인 것은 아닙니다. 특히 관료주의가 큰 대기업에서 일하는 경우.

• 버전 관리 시스템을 올바르게 사용하는 법을 배우십시오. 당신은 기존의 것을 결코 깨지 않을 것입니다 (실제로는 결코 아니지만 좋은 안전망입니다).

• 당신이 그것을 즉시 이해하지 못하기 때문에 그것이 나쁘다고 가정하지 마십시오. 그것이 효과가 있기 때문에 단순히 좋다고 가정하지 마십시오. 중요한 것은 이전 관리자의 코드 스타일을 이해하고 추가 한 줄을 그의 스타일에 맞게 조정하는 것입니다. 당신이 오는 관리자는 고마워 할 것입니다.

• 불행히도 일부 회사에서는 코드를 읽는 데 어려움을 과소 평가할 수 있습니다. 이는 공정이 엄격한 대기업에서 일반적입니다. 그들은 종종 (암시 적으로) 깨끗한 것을 작성하는 데 시간이 걸리지 않고 빠르게 작동하는 코드를 푸시하는 것을 선호합니다. 이 시점에서 팀이 어디에 서 있는지 결정하기 위해 당신에게 맡길 것입니다.

• 마지막으로, 코드를 읽는 것이 기술 이라는 것을 잊지 마십시오 . 더 많이할수록 더 잘 얻을 수 있습니다. 이것을 말하는 또 다른 방법 은 그것을 잘하는 유일한 방법은 그것을 여러 번 연습하는 것입니다. 위에서 언급 한 것처럼, 코드를 읽는 것은 글을 쓰는 것보다 훨씬 더 큰 일입니다.

실수로 물건을 깰 때의 문제로 판단하면 코드에 자동화 된 테스트가 적용되지 않는다고 가정합니다. # 0 단계는 즉시 Michael Feathers의 레거시 코드 로 작업 하기를 주문하고 읽는 것 입니다. 그것은 단순히 귀중합니다.

내가 제안 할 기본 단계 :

• 현재 기능을 다루는 테스트로 코드를 다루십시오.
• 이해할 때까지 리팩터링하십시오.
• 새로운 기능 또는 수정 된 기능에 대한 테스트를 작성하십시오.
• 새로운 기능을 구현하십시오.
• 만족할 때까지 리팩토링하십시오.

나는 의도적으로 테스트의 풍미 (단위, 통합 등)를 지정하지 않고 자동 테스트 범위를 얻습니다.

(예, 레이아웃 및 이름 지정 측면에서 코딩 스타일을 따르십시오)

앞에서 언급했듯이 현실 세계에 오신 것을 환영합니다. 나는 이전 답변에만 동의 할 수 있습니다. 시간 예상치에 대한 업무 경험만으로 답변을 확장하고 싶습니다.

상사를 명확하게하기위한 좋은 제안, 다른 개발자의 생각을 배우려면 시간이 걸릴 것입니다. 일반적으로 현재 솔루션은 개발자의 연령과 경험에 따라 달라집니다.

운이 좋으면 수작업을 분석하고 문서를 이해하면 많은 도움이 될 것입니다 (그러나 종종 그렇지 않습니다).

내 경험은 다른 코드를 수정할 때 현재 작업과 관련이없는 코드를 변경하지 마십시오. 더 나은 솔루션을 알고 있거나 더 직관적 인 방법으로 작성할 수 있지만 변경하면 종종 다음과 같은 문제가 발생합니다.

• 작업이 오래 걸리고 상사가 이해하지 못할 것입니다.
• 변경 한 코드는 테스트해야하며 비용이 듭니다. 현재 솔루션은 테스트 및 승인되었습니다.
• 어떤 변화가 현재의 과제를 해결하는지, 그리고 어떤 것이 '정확한'정정인지는보기 어려울 것입니다.

그러나 당신이 생각해야하는 것이 다르다고 생각되면 주저하지 말고 생각하십시오 (그냥 생각할 수 있음을 보여줍니다).

마지막으로, 솔루션을 만들기에 충분한 시간이 있는지 확인하십시오. 더 빠른 솔루션은 경험과 함께 제공됩니다. 그러나 이것이 오류 및 유지 불가능한 코드의 첫 번째 / 주요 이유이기 때문에 빠른 솔루션은 거의 없습니다.

사람에 대한 작업을 수행하는 것처럼 생각하십시오.

내부에서 수정해야 할 문제를 찾아보고 대부분의 동맥 등이 원하는 방식으로 설정되지 않았 음을 알 수 있습니다. 따라서 자신에게 맞는 모양으로 잘라서 잘라내어 문제를 해결하십시오.

놀랍게도 환자는 거의 즉시 사망합니다.

레거시 응용 프로그램은 동일합니다. 그들은 이미 작동하는 방법을 가지고 있습니다-소프트웨어의 다양한 구성 요소와 서로 관련되는 방법을 이해 한 다음 변경 사항이 동일한 방식으로 작동하도록해야합니다. 창의력을 돋보이게하는 것은 흥미롭지 않지만 개인 프로젝트에서 할 수는 있습니다.

수석 엔지니어에게 매주 월요일 한 시간 정도 함께 앉아 시스템의 다른 측면을 설명해달라고 부탁합니다. 그가 말한 내용을 메모하고 관리자와 추가 할 내용이 있는지 확인하기 위해 그와 관리자에게 전자 메일로 보냅니다. 이렇게 빨리 속도를 내야합니다.

문제를 해결하는 방법에 관해서는 우선 시스템의 기능을 이해해야합니다. 시험하기 전에-변경하고 시험하십시오. 마법의 공식은 없습니다. 당신이 경험을 얻을 때 당신은 더 나아질 것입니다-또는 해고 될 것 같아요!

내가 실제로 보지 못한 것 중 하나 는 섬에서 작동하지 않습니다.

당신이 당신의 복장에서 유일한 프로그래머 않는 한,있을 바인딩 누군가 당신이 의지 할 수있는 당신보다 더 많은 경험을 가지고 있으며, 아마도 많은 사람들이.

질문. 그들 중 많은.

다른 사람에게 "성가신"것에 대해 걱정하지 마십시오. (이유 내에서)-정상적인 개발주기 동안 누군가가 나중에 프로덕션 환경에서 불을 피우는 것보다 한두 가지 질문으로 나를 방해했습니다.

체크인 할 준비가되면 멘토와 함께 검토하십시오. 그들은 무언가가 다른 것을 깨뜨릴 수있을뿐만 아니라 더 중요한 이유를 알려줄 수 있어야합니다. 코드를 검토하면 멘토가 더 나은 프로그래머가되어 시스템을 자주 볼 수없는 시각을 갖게됩니다.

기억하십시오-신입 사원이해야 할 것처럼 시스템을 배우는 것이 아니라 프로그래머가되는 방법도 배우는 것입니다.

그리고 5 년 후, 다음 New Guy가 당신을 멘토로 사용하도록 장려하십시오.

코드 디버깅과 관련하여 항상 이유가 있습니다. 며칠 동안 같은 멍청한 벌레를 찾아 고치려고했지만 진전이 없다면 다음 중 하나 이상을 생각하고 싶은 유혹이 있습니다.

• 이 코드가 어떻게 작동하는지 알아낼만큼 똑똑하지 않습니다.

• 이 코드를 작성한 사람은 자신이 무엇을하고 있는지 전혀 몰랐습니다.

• 마술이 관여합니다 : 매우 흑 마술

그것들은 모두 포기하는 형태입니다. 해독제는 컴퓨터가 결정 론적이라는 것을 항상 기억하는 것입니다. 컴퓨터가하는 일에는 항상 이유가 있습니다. 코드는 어류 통조림에서 간조 냄새가 나고 거대한 언어의 그릇과 비슷하지만, 끊임없이 합리적이고 열린 마음을 유지함으로써 그것을 알아낼 수 있습니다.

가능한 경우 단위 테스트를 작성하든 수정중인 코드와 관련된 작은 응용 프로그램을 작성하든 논리를보고 이해 한 다음 문서화해야합니다.

코드가 주로 작동하는 것처럼 들리면 스타일에 관계없이 해당 모듈의 코드 형식을 유지합니다. 그것은 일을 균일하게 유지합니다. 그러나 좋은 의견은 결코 스타일에서 벗어나지 않습니다.

테스트 시스템과 테스트 플랫폼에서 프로덕션 환경을 유지하면서이 코드를 수정하고 테스트 할 수있는 것이 좋습니다.

라이브러리에서 코드 요소를 제거 할 수 있다면 라이브러리에서 작업하지 않는 한 그렇게 할 것입니다.

시간이 지남에 따라 일단 논리를 이해하면 다시 작성하고 테스트 할 수 있습니다.

이 조언은 사용중인 언어, 테스트 베드를 얻는 기능 및 기타 제약 조건에 따라 결정됩니다.

일부 코드 분석기 도구를 사용하여 삭제할 수있는 사용하지 않는 코드를 찾으십시오. 따라서 최소한이 코드에 대해 걱정할 필요가 없습니다.

위에서는 코드의 세부 사항뿐만 아니라 시스템의 목적을 이해해야한다고 언급했습니다. 주문 입력 시스템을 작성하는 데 충분한 경험이있는 프로그래머는 일반적으로 제품 선택, 송장 형식화 및 지불 처리와 같은 '이동'부분에 익숙합니다. 그들이 막히는 곳은 사용자가 '걱정하지 않음'을 결정하고 거래를 취소하기 시작하거나 지불 처리에 오류가 발생하여 '뒤로'버튼을 누르는 경우입니다. 이 시점에서 많은 프로그래머들이 코드가 '어딘가에 나타나지 않음'을보고 왜 거기에 있는지 알아낼 수 없기 때문에 플럭스 옥스를 당합니다.

간단히 말해서, '정상적인 흐름'뿐만 아니라 누군가 실수를하거나 마음이 바뀔 때 필요한 모든 역 추적을 이해해야합니다. 일부 코드는 특정 계정 권한으로 만 실행할 수있는 감독자 재정의로 인해 더욱 악화됩니다.

누군가가 1 년에 10,000 줄의 코드를 작성하고 응용 프로그램에 10 년의 수명이있는 경우 다른 사람의 작업을 담당하는 프로그래머는 10 만 줄의 코드를 이해해야합니다. 이것을 페이지 당 50 행으로 나누면 2000 페이지입니다. 프로그램이 디자인 패턴으로 작성된 경우, 프로그래머는 하나의 '블록'에 대한 이해가 나머지 대부분에 대한 일반적인 이해로 이어진다는 것을 알게 될 것입니다. 그렇지 않다면 모든 마지막 줄을 읽어야합니다.

일부 프로그래머는``그들이하는 것을 그냥하고 ''스파게티를 씁니다. 그들은 '큰 그림'을 이해하지 못합니다. 사용자가 불평 할 때 단순히 수정을합니다. 이러한 상황에서는 가능한 모든 것을 적절한 패턴으로 마이그레이션하는 것이 좋습니다. 결국 이것은 '파손되지 않은'레코딩을 의미 할 수 있습니다. 걱정하지 마십시오. 프로젝트 일수록 점진적으로 유지 관리가 가능한지 확인하십시오.

여기에 정말 좋은 답변이 있습니다. 그러나 좋은 디자인 패턴에 대해 얼마나 많은 친숙 함을 언급 할 가치가 있다고 생각합니다. 기존 코드를 읽고 (잘 작성) 읽고 읽을 수있는 코드를 작성하는 데 도움이 될 수 .

물론 팩토리 패턴을SomethingFactory 따르지 않는 기존 코드에서 발생할 때 매우 혼란 스러울 수 있습니다 . 그러나 팀과 프레임 워크가 허용하는 한 그러한 사례를 최소한으로 유지하는 것이 유리할 수 있습니다.

비즈니스 요구 사항에 맞는 디자인 패턴을 따르면 코드 중복을 크게 줄여 향후 수정시 버그를 줄일 수 있습니다.

디자인 패턴에 대한 좋은 소스는

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

그리고 물론 책

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

비즈니스 로직의 멘탈 맵을 개발할 때는 방법 간의 제어 흐름을 추적하는 것이 매우 중요합니다.

우리의 솔루션은 레거시 시스템에 접근 할 때 사용 가능한 몇 안되는 신뢰할 수있는 정보 중 하나가 실행중인 시스템이라는 점을 인정하는 것입니다. 우리의 접근 방식은 실행 추적을 유지하고 로직 프로그래밍을 사용하여 테스트를 표현합니다.

워크 플로 데이터 모델을 생성하는 것이 모든 코드 경로를 분석하는 가장 좋은 방법입니다.

실제로 레거시 과학 워크 플로에서는 코드 검토가 다루기 어려워집니다. 이러한 워크 플로의 시작은 소프트웨어 엔지니어링 사례가 개발 중에 적용되지 않았을 수 있으며, 코드 기반이 효과적으로 난독 화 될 수 있습니다. 정적 분석은 데이터 흐름 분석을위한 기술을 잘 개발했지만 실제 워크 플로에서의 동작을 지원하지 않습니다. 예를 들어, 데이터 처리 방법을 결정하기 위해 구성 파일을로드해야하는 경우 또는 동적 코드 평가가 사용되는 경우를 예로들 수 있습니다.

워크 플로를 시각화하는 것이 이상적입니다.

시각적 개발 자체를 빌려주는 일반적인 주제는 워크 플로를 그래프로 표현하는 것입니다. 이를 통해 리소스와 실행의 기본 복잡성으로부터 사용자를 보호합니다

참고 문헌

• 런타임 분석을 통한 레거시 워크 플로 이해 (pdf)
• 객체 지향 레거시 시스템 추적 기반 논리 테스트 (pdf)
• console.trace ()-웹 API | MDN
• 프록시를 통한 메소드 호출 추적
• 루비 메소드를 감시하는 방법
• Python에서 중첩 함수 호출을 쉽게 추적-Eli Bendersky 웹 사이트
• 분석법 입력 / 종료 로깅 – Mebyon Kernow
• 추적 : 함수 호출을 표시하는 계측
• -Xtrace-
• GitHub-johnno1962 / SwiftTrace : 추적 스위프트 및 Objective-C 메소드 호출
• 디버그 :: 추적-서브 루틴 호출을 추적하기위한 Perl 확장-metacpan.org

현재 파일에서 물건을 찾는 데 도움이되는 프로그램을 사용하고 있는지 확인하십시오. 찾고있는 것을 아는 것보다 더 나쁜 것은 현재 파일에 있지만 스크롤하고 스크롤하여 찾을 수 없습니다. 코드를 편집하는 데 사용하는 도구의 개요보기는 해당 문제를 해결하는 데 실제로 도움이됩니다.