소프트웨어 엔지니어로서 다른 사람의 코드를 읽는 것이 얼마나 중요합니까?

저는 신진 소프트웨어 엔지니어 (현재는 2 학년, CS 전공)이며 다른 사람들의 프로그램을 이해하기 위해 정말로 고심하고 있습니다. 이 기술 (혹은 부족)이 핸디캡이 될 수 있는지 알고 싶습니다. 그렇다면 그렇다면 어떻게 개발할 수 있습니까?

이건 필수이다.

당신이 그것을 개발하는 방법은 자신의 코드를 작성하는 것입니다 (많은 코드). 그렇습니다. 다른 사람들의 코드를 읽는 데 어려움을 겪고 있습니다.

물론 문제는 모든 사람이 당신이 생각하는 방식이 아니라는 것입니다. 나는 오래 전에 1 학년 자바 수업을 받았으며 우리에게는 과제가 주어졌습니다. 내가 믿었던 것과는 반대로 (대답이 3-4 개의 공통 솔루션으로 수렴 될 것이라는 점) 반의 모든 사람들은 과제에 대한 고유 한 솔루션을 가졌다.

좋은 코드를 읽어야 합니다.

이것이 디자인 패턴이 인기를 얻은 이유 중 하나이며이를 연구해야하는 이유 중 하나입니다. 디자인 패턴은 프로그래머가 의사 소통 할 수있는 공통 어휘를 제공하며 컴퓨팅 문제를 해결하기위한 "더 나은"방법으로 마음을 조정합니다.

알고리즘과 데이터 구조도 연구해야합니다.

결론 : 항상 다른 개발자가 쉽게 이해할 수있는 코드를 작성하려고 노력해야합니다.

그것은이다 매우 중요합니다.

일단 졸업하고 세상에 나가면, 대부분의 프로젝트는 다른 사람들이 작성한 코드를 가지고있을 것입니다. Lucky는 그린 필드 프로젝트에 모든 시간을 할애하는 프로그래머입니다!

그것은 연습과 인내를 통해 습득되는 기술이며, 많은 경우 많은 사람들이 졸업 후 첫 직장을 갖기 전까지는 실제로 많은 기회를 얻지 못하는 기술입니다 . 편하게 하다!

(학교가 협동 프로그램이있는 경우 있지만, 그 대부분은 다른 사람에 의해 작성되는 대형 프로젝트 작업에 당신이 사전 졸업에게 경험을 줄 것이다 및 이 가능한 경우에!보기에 뭔가를 당신에게 학점을 얻는다)

중요한 기술입니다 당신이 일하는 곳의 세부 사항의 따라, 심지어 코드 자체를 작성하는 것보다 더 중요 할 수있다.

다른 기술과 마찬가지로 연습도 완벽합니다! 다른 프로그래머의 코드를 읽고 디버깅하고 개인적으로 도움이되는 것은 작은 코드를 리팩터링하거나 개선하고 거기서부터 확장하는 것입니다.

코드 읽기와 쓰기에는 뚜렷한 기술이 있습니다.

• 하나는 구문입니다. 메소드 선언이 무엇인지 아는 것.
• 다른 하나는 의도입니다. 방법이 존재하는 이유와 그것이 제공되는 목적을 아는 것.

읽기 대 쓰기. 네 독서는 필수입니다.
많은 사람들을 돕는 몇 가지 최대 값은 다음과 같습니다.

• 코드는 기록 될 때마다 적어도 10 번 읽습니다.
• 다른 사람이 코드를 읽는 것은 종종 ... 나중에 코드를 읽는 중입니다.
• 나는 1 년 전부터 내 코드 스타일을 변호하지 않았으며 그 이후로 향상되었습니다.

승인. 그래서 모두 훌륭합니다. 지금 당신이 겪고있는 것까지.

세상에, 수십 긴 미친 종속성 및 모든 시간 라인의 수백 소스 코드의 라인 및 클래스의 수천이 괴물이 거대한 코드베이스가 나는 등 등 내 머리에 10 레벨을 유지해야 뭔가, 따라하려고
익숙한 사운드를 ? 네. 깊은 숨. 편하게 하다. 정상입니다. 그것은 생산 시스템이 만들어지는 것입니다. 이해할 수없는 것처럼 보이는 상황에서 사람들은 살아남고 (그리고 화려 함)

• (희망적으로) 테스트가 존재하며 시스템을 문서화하는 데 도움이됩니다.
• 프로그래머는 짝을 짓고 종종 두 배 이상의 결과를 가져옵니다.
• 좋은 프로그래머는 이해하기 전까지는 이해하지 못한다고 말합니다.
• 변경 사항은 종종 테스트 대상을 분리하는 데 도움이되는 하나 또는 몇 줄의 코드입니다.
• 코드 기반에 익숙해지는 데 몇 개월, 심지어 몇 년이 걸린다

이러한 답변의 대부분은 자체 개선에 대한 코드 읽기의 중요성에 중점을 둡니다. 나는 진심으로 동의하고 승인합니다.

조심해야 할 또 다른 각도가 있습니다-다른 접근법을 읽을 수는 없지만 (논쟁의 여지가 있기 때문에 ....) 신진 인 경우에도 여전히 코드를 읽는 방법을 알아야합니다. 기본적으로 대학 환경에는 존재하지 않는 개념 : 대부분의 산업 프로젝트는 브라운 필드 프로젝트 (즉, 기존 코드베이스와 통합되거나 기존 코드베이스와 통합)입니다.

기존 코드베이스와 프로세스를 이해하기 위해 코드를 읽을 필요가 있습니다. 코드에 대해 다른 개발자에게 질문하는 것이 항상 가능하지만 시간이 오래 걸릴 수 있습니다. 사람들은 떠나거나 프로젝트를 전환하거나 평범한 시간을 보냅니다. 낮은 수준의 세부 정보는 메모리 및 유지 관리 프로그래머로부터 사라져 패치를 적용합니다. 어떤 시점에서 코드 자체를 제외하고는 단일 한 진실의 원천이 없습니다.

좋은 코드 위생, 스타일 가이드, 코드 검토 및 문서 도움말이지만, 어느 시점에서 코드는 발생하는 사실에 대한 진실의 원천이며 답을 찾는 유일한 방법은 직접 얻는 것입니다. 자체 개발에서 사용하는 것 외에도 코드를 읽는 기능은 코드를 작성하는 것과는 별개의 기술입니다.

다른 사람의 코드를 이해하는 것은 팀에서 일하지 않아도 팀에서 일할 가능성이 높기 때문에 탈출 할 수없는 것입니다 .Google은 다른 것들을 Google로 보내고 샘플 코드를 이해해야합니다. 예, 필수입니다.

내가 느끼는 것은 모든 사람들이 처음 시작할 때 느낌이 다른 것보다 적을 수 있다는 것입니다. 읽고 쓰는 것뿐만 아니라 구조화 할 때 다른 사람보다 자신의 코드로 더 많은 시간을 보내면서 다른 코드보다 코드를 더 잘 이해합니다. 당신의 마음에. 다른 코드로 더 많은 시간을 보내고 먼저 어떤 종류의 구조 / 흐름이 사용되고 있는지 확인하려고하면 코드를 더 잘 이해하게됩니다.

1 년 전에 작성한 코드가 있으면 내 요지를 더 설득력있게하기 위해 다시 이해하려고하면 다른 코드보다 시간이 많이 걸리지 만 구조를 구성하는 방법에 대한 아이디어가 있음을 알 수 있습니다 암호.

이 도움을 바랍니다. 실망하지 마십시오. 완전히 정상입니다. 코드로 더 많은 시간을 보내면 결국 얻을 수 있습니다.

글쎄, 나는 다른 나라의 한 팀이 작성한 100,000 줄의 코드로 프로젝트를 받았으며, 많은 코드를 남기면서 다음 달에 코드 사본을 크게 변경해야합니다. 가능한 한 공통점이 있습니다.

다른 사람의 코드를 빨리 읽을 수있는 능력없이 어떻게 일을 할 수 있는지 말해 주실 수 있습니다. 다른 사람들의 코드를 읽을 수 없다면, 당신은 완전히 붙어 있습니다.