나는 1 년의 코딩 경험이 거의 없다. 작업을 시작한 후에는 대부분 기존 코드 위에 새 기능을 추가하거나 기존 기능을 수정하여 다른 사람의 코드 작업을하고있었습니다. 실제 코드를 작성한 사람은 더 이상 회사에서 작동하지 않습니다. 그의 코드를 이해하고 내 작업을 수행하는 데 어려움을 겪고 있습니다. 코드를 수정하려고 할 때마다 작동 기능이 엉망이되었습니다. 다른 사람의 코드를 작업하면서 어떤 점을 명심해야합니까?
답변
코드에 단위 테스트가 있습니까? 그렇지 않으면, 나는 강하게 당신이 그들을 추가 시작하는 것이 좋습니다. 이렇게하면 테스트 실패로 새로운 기능 / 버그 수정을 작성한 다음 테스트가 통과 한 코드를 수정할 수 있습니다. 빌드 한 것들이 많을수록 추가 된 코드가 다른 것을 깨뜨리지 않았다는 자신감이 커집니다.
완전히 이해하지 못하는 코드에 대한 단위 테스트를 작성하면 해당 코드를 이해하는 데 도움이됩니다. 물론 기능 테스트가없는 경우 추가해야합니다. 나는 OP 질문에 이미 존재했다는 인상을 받았다. 그 시점에서 내가 틀렸다면 이러한 기능 테스트가 첫 번째 단계입니다.
Eagle76dk는 하게 좋은 점 Eagle76dk의 게시물에 대한 자세한 내용 -이 일을 위해 보드에 관리자보기에 대한합니다.
또한 이러한 테스트를 작성할 때 메소드가 코드 동작이 아니라 달성하려고 시도한 비즈니스 동작을 검증 할 수 있도록 테스트를 작성하도록 권장합니다. 또한 코드에 표시되는 비즈니스 동작이 올바른 것으로 가정하지 마십시오. 응용 프로그램에서 수행해야하는 작업을 알려줄 수있는 사람이있는 경우 코드에서 알 수있는 것보다 더 가치있는 경우가 많습니다.
답변
단위 테스트를 언급 한 또 다른 답변 외에도 모든 것이 버전 관리에 있는지 확인하여 변경 사항을 쉽게 되돌릴 수 있도록 제안합니다. 코드를 유지 관리하기 쉽도록 약간만 변경하면됩니다.
답변
제 생각에는 다른 사람의 코드를 배우는 가장 빠른 방법은 (특히 설명에 따라 변경 사항이 예기치 않은 동작을 유발할 때) 디버거를 사용하여 코드 를 단계별로 실행하는 것 입니다.
프로그램의 주요 루프 / 주요 메소드 인 것으로 단계별로 시작하십시오. 스텝 인 및 스텝 아웃 기능을 사용하여 다양한 방법의 기능을 확인하십시오. 이것은 코드의 일반적인 구조를 알려줄 것입니다.
그 후, 프로그램의 다른 부분을 심층적으로 학습하고 학습함으로써 나누고 정복하십시오. 대부분의 디버거에서는 변수 와 현재 값을 연구 할 수 있습니다 . 그들이 어떻게 그리고 언제 바뀌는 지 연구하십시오.
관심있는 동작을 트리거하는 메소드에 중단 점 을 설정하십시오 . 예를 들어 프로그램에서 텍스트를 변경하려고 할 때 텍스트가 원래 값으로 계속 변경되는 경우 텍스트가 변경되는 모든 위치에 중단 점을 설정하거나 이러한 변경 사항을 하나의 단일 방법으로 이동하십시오. 콜 스택 을 사용 하여이 메소드가 호출 된 위치 등을 확인하십시오.
코드 행을 변경 하면 다른 위치에서 예기치 않은 변경이 발생하는 경우 해당 행에 중단 점을두고 예를 들어 범위 내에서 현재 변수의 값을 확인하거나 단계를 사용하거나 호출 스택을 통해 어디서 발생하는지 확인하십시오. 전화가왔다.
이 작업을 많이 수행하면 코드 구조를 놀랍게도 빠르게 배울 수 있습니다. 나는 당신이 처음 프로그래밍 작업을 시작한 것처럼 몇 년 전에 쓰여졌 고 수년 동안 많은 사람들에 의해 변경된 많은 코드를 가지고 시작했습니다. 이 코드는 다른 사람들이 동시에 작업을 수행 한 이후로만 작성된 것이 아닙니다. 그 시점에서 모든 것을 다시 쓸 수 없었습니다. 모든 코드에 대한 테스트를 작성하는 데 몇 달 또는 몇 년이 걸렸습니다. 디버거가 실제로 저를 구했습니다. 코드없이 코드를 어떻게 배울 지 모르겠습니다 …
답변
가장 먼저 명심해야 할 것은 코드를 작성하는 것보다 코드를 읽는 데 더 많은 시간이 소요된다는 것입니다. 다른 사람의 작업 방식, 즉 자신의 스타일과 문제에 대한 접근 방식을 이해하기 위해 시간을 보내십시오.
가능한 한 기존 스타일을 채택하십시오. 그렇지 않으면 남자가 두 배로 조정해야합니다.
다른 사람의 코드를 다루는 것은 예외가 아닌 표준입니다. 다른 사람이 어떻게 문제를 해결하거나 기능을 구현했는지 파악하는 데 능숙해야합니다. 일단 그렇게하면 그의 코드를 다루기가 더 쉬울 것입니다.
답변
다른 사람의 코드가 악취가 났다고 가정하지 마십시오.
그러나 항상 의심하십시오.
그러나 다른 개발자의 코드를 이해하려면 시간이 걸립니다. 시스템의 여러 부분에서 기능이나 객체를 많이 사용할수록 더주의해야합니다. 증상에 더 가깝게 문제를 해결할 수 있다면 때로는 도움이 될 수 있습니다. 예를 들어, 데이터가 전달 된 후 다른 상황이 발생하기 전에 펜스의 문제 객체쪽에있는 다른 객체에서 들어오는 데이터를 정규화합니다.
한 가지를 바꾸면 다른 것이 예기치 않게 깨질 때 나쁜 징조입니다. 다른 숙련 된 개발자가 도움을 필요로하는 경우 문제를 일으키는 원인을 찾아 보도록 권장합니다. 최소한 디버그를 지켜 보는 몇 가지 항목을 선택할 수 있습니다.
답변
이상적인 환경에서 특정 개발자가 작성한 모든 코드는 사용자가 예상 한 결과를 얻었는지 확인하기 위해 사용자가 실행하는 단위 테스트 및 사용 사례 스크립트와 같은 자동 도구를 사용하여 문서화되고 체계적으로 구성되며 이해하기 쉽게 테스트됩니다.
그러나 가장 먼저 배울 것은 이상적인 세계에 살지 않는다는 것입니다!
많은 개발자들이 코드를 제대로 문서화하지 않고, 비즈니스 로직과 관련이없는 코드를 섞은 경우, 유일하게 수행 할 수있는 유일한 테스트는 일반적인 사용 사례가 될 것으로 예상되는 것을 신속하게 실행하는 것입니다.
이와 같은 코드로 작업 할 때 가장 먼저해야 할 일은해야 할 일을 설정하는 것입니다. 의견이 있으면 힌트를 줄 수 있지만 의지하지는 마십시오. 많은 코더가 자신을 설명하는 데 능숙하지 않으며 내 의견을 남기더라도 의미가 없을 수도 있습니다. 그러나 회사의 유일한 코더가 아니라면 누군가 코드의 목적과 코드의 의도에 대한 기본 아이디어를 가지고 있어야합니다. 주위에 물어보세요!
당신이 단위 테스트를한다면, 그들은 당신의 인생을 훨씬 쉽게 만들 것입니다. 그렇지 않은 경우 코드베이스 학습의 일부로 이미 존재하는 코드에 대한 단위 테스트 작성이 필요할 수 있습니다. 일반적으로 이것은 기존 코드에 맞게 단위 테스트를 작성하면 코드가 그대로 작동한다고 생각하는 단위 테스트로 끝날 것입니다 (실제로 버그 인 행동을 가정하여 작성됩니다) 맞습니다), 그러나 최소한 그것은 당신에게 기준을 제공합니다. 나중에 옳다고 생각한 일부 동작이 실제로 잘못되었다는 것을 발견 한 경우 코드가 지금 제공하는 결과가 아니라 예상 결과가 무엇인지 테스트하기 위해 단위 테스트를 변경할 수 있습니다. 단위 테스트가 완료되면 변경을 수행하고 변경 사항에 따른 부작용을 평가할 수 있습니다.
마지막으로, 문서화되지 않은 코드를 처리 할 때 가장 좋은 리소스는 최종 사용자에게 문의하는 것입니다. 코드에 대해서는 아무것도 모르지만 응용 프로그램이 원하는 것을 알고 있습니다. 요구 사항 수집은 모든 프로젝트의 첫 단계이며, 개발 될 시스템의 잠재 사용자와 대화하는 것이 항상 중요한 부분입니다. 방금 이미 만들어진 새로운 프로젝트에 대한 요구 사항 캡처 단계를 수행한다고 생각하십시오.
잘 작성되고 잘 문서화 된 코드조차도 외부인이 이해하기 어려울 수 있습니다. 코드는 본질적으로 당시에 코드를 작성한 사람이 어떻게 생각하고 있었는지에 대한 표현이며 모든 사람은 고유 한 사고 과정을 가지고 있습니다. 약간 인내심을 갖고 배우는 법을 배워야합니다. 다른 사람의 사고 과정에 들어갈 수는 어렵지만 기존 코드를 유지 관리하는 프로그래머에게는 필수적인 기술입니다. 대부분의 코딩 (약 70 %)은 기존 코드 유지와 관련이 있기 때문에 배우는 데 중요한 기술입니다.
아, 그리고 문서화가 안되고, 테스트되지 않고 뒤죽박죽이 된 코드가 야기 할 수있는 고통을 보았으므로, 다음의 빈약 한 개발자에게 다가 가지 않을 것입니다. 🙂 전임자의 실수로부터 배우고, 코드를 잘 주석 처리하고, 모든 모듈에 명확하게 정의 된 책임이 있는지 확인하고, 먼저 TDD 방법론에 대해 작성하는 포괄적 인 단위 테스트 세트가 있는지 확인하십시오. 적어도 개발중인 코드와 함께.
답변
작성하지 않은 코드를 읽는 기능은 코드를 작성하는 것보다 훨씬 가치있는 기술이라는 점을 명심하십시오. 불행히도, 이것은 학교에서 널리 과소 평가되고 있습니다.
내가 말하려는 것은 처음 읽을 때 항상 코드를 이해하지 못하는 것이 정상이라는 것입니다 (처음으로 완벽한 코드를 작성하지 않는 것이 정상인 것처럼). 외국 코드를 얻는 데 시간이 걸린다는 점을 받아들이면 추가 노력을 기울이지 않아도됩니다. 작은 요약 :
-
단위 테스트는 이상적이지만 항상 현실적인 것은 아닙니다. 특히 관료주의가 큰 대기업에서 일하는 경우.
-
버전 관리 시스템을 올바르게 사용하는 법을 배우십시오. 당신은 기존의 것을 결코 깨지 않을 것입니다 (실제로는 결코 아니지만 좋은 안전망입니다).
-
당신이 그것을 즉시 이해하지 못하기 때문에 그것이 나쁘다고 가정하지 마십시오. 그것이 효과가 있기 때문에 단순히 좋다고 가정하지 마십시오. 중요한 것은 이전 관리자의 코드 스타일을 이해하고 추가 한 줄을 그의 스타일에 맞게 조정하는 것입니다. 당신이 오는 관리자는 고마워 할 것입니다.
-
불행히도 일부 회사에서는 코드를 읽는 데 어려움을 과소 평가할 수 있습니다. 이는 공정이 엄격한 대기업에서 일반적입니다. 그들은 종종 (암시 적으로) 깨끗한 것을 작성하는 데 시간이 걸리지 않고 빠르게 작동하는 코드를 푸시하는 것을 선호합니다. 이 시점에서 팀이 어디에 서 있는지 결정하기 위해 당신에게 맡길 것입니다.
-
마지막으로, 코드를 읽는 것이 기술 이라는 것을 잊지 마십시오 . 더 많이할수록 더 잘 얻을 수 있습니다. 이것을 말하는 또 다른 방법 은 그것을 잘하는 유일한 방법은 그것을 여러 번 연습하는 것입니다. 위에서 언급 한 것처럼, 코드를 읽는 것은 글을 쓰는 것보다 훨씬 더 큰 일입니다.