이해하지 못하는 것을 개발하는 데 동의하지 마십시오

2018년 초부터 저는 팀에서 리드/보스/리드 개발자 직책을 맡고 있습니다. 원하는 대로 부르세요. 하지만 요점은 모듈 중 하나와 작업하는 모든 개발자에 대해 전적으로 책임이 있다는 것입니다. 그 위에. 이 직책을 통해 저는 더 많은 프로젝트에 참여하고 의사 결정에 더욱 적극적으로 참여하게 되면서 개발 과정에 대한 새로운 관점을 갖게 되었습니다. 최근에는 이 두 가지 덕분에 이해도가 코드와 애플리케이션에 얼마나 큰 영향을 미치는지 문득 깨달았습니다.

제가 강조하고 싶은 점은 코드(및 최종 제품)의 품질이 코드를 설계하고 작성하는 사람들이 자신이 하는 일에 대해 얼마나 인식하고 있는지와 밀접한 관련이 있다는 것입니다.

지금 당장 “고마워요, 캡틴. 물론, 당신이 쓰고 있는 내용을 전반적으로 이해하는 것이 좋을 것입니다. 그렇지 않으면 원숭이 무리를 고용해 임의의 키를 누르고 그대로 두는 편이 나을 것입니다.” 그리고 당신은 절대적으로 옳습니다. 따라서 나는 당신이 하고 있는 일에 대한 일반적인 생각을 갖는 것이 필요하다는 것을 깨닫는 것을 당연하게 생각합니다. 이는 이해도 제로 수준이라고 할 수 있으므로 자세히 분석하지는 않겠습니다. 우리는 정확히 무엇을 이해해야 하는지, 그것이 매일 내리는 결정에 어떤 영향을 미치는지 자세히 살펴볼 것입니다. 이러한 사항을 미리 알았더라면 낭비되는 시간과 의심스러운 코드를 많이 절약할 수 있었을 것입니다.

아래에서는 한 줄의 코드도 볼 수 없겠지만, 나는 여기서 언급된 모든 내용이 고품질의 표현력 있는 코드를 작성하는 데 매우 중요하다고 믿습니다.

첫 번째 이해 수준: 왜 작동하지 않나요?

개발자는 일반적으로 경력 초기에 이 수준에 도달하며 때로는 다른 사람의 도움 없이도 도달합니다. 적어도 내 경험으로는 그렇습니다. 버그 보고서를 받았다고 가정해 보겠습니다. 애플리케이션의 일부 기능이 작동하지 않아 수정해야 합니다. 어떻게 진행하시겠습니까?

표준 구성표는 다음과 같습니다.

1. 문제를 일으키는 코드 조각을 찾으십시오. (이를 수행하는 방법은 별도의 주제이므로 레거시 코드에 관한 책에서 다룹니다.)
2. 이 스니펫을 변경하세요.
3. 버그가 수정되었고 회귀 오류가 발생하지 않았는지 확인하세요.

이제 두 번째 사항인 코드 변경에 집중하겠습니다. 이 프로세스에는 두 가지 접근 방식이 있습니다. 첫 번째는 현재 코드에서 정확히 무슨 일이 일어나고 있는지 조사하고 오류를 식별하고 수정하는 것입니다. 둘째: 느낌에 따라 이동합니다. 예를 들어 조건문이나 루프에 +1을 추가하고 함수가 원하는 시나리오에서 작동하는지 확인한 다음 다른 것을 시도하는 등 무한히 계속합니다.

첫 번째 접근 방식이 정확합니다. Steve McConnell이 자신의 저서 Code Complete(제가 적극 권장하는 책)에서 설명했듯이, 코드에서 무언가를 변경할 때마다 그것이 애플리케이션에 어떤 영향을 미칠지 확신을 가지고 예측할 수 있어야 합니다. 나는 기억에서 인용하고 있지만 버그 수정이 예상한 대로 작동하지 않으면 매우 놀라야 하며 전체 실행 계획에 의문을 제기해야 합니다.

지금까지 말한 내용을 요약하면, 코드 품질을 저하시키지 않는 좋은 버그 수정을 수행하려면 코드의 전체 구조와 특정 문제의 원인을 모두 이해해야 합니다.

두 번째 수준의 이해: 왜 작동하는가?

이 수준은 이전 수준보다 훨씬 덜 직관적으로 이해됩니다. 아직 초보 개발자였던 나는 상사 덕분에 그것을 배웠고, 이후에 신입사원들에게 문제의 본질을 반복해서 설명했습니다.

이번에는 두 개의 버그 보고서를 동시에 받았다고 가정해 보겠습니다. 첫 번째는 시나리오 A에 관한 것이고 두 번째는 시나리오 B에 관한 것입니다. 두 시나리오 모두에서 뭔가 잘못된 일이 발생합니다. 따라서 첫 번째 버그를 먼저 해결합니다. 레벨 XNUMX 이해를 위해 개발한 원칙을 사용하여 문제와 관련된 코드를 깊이 파고들어 응용 프로그램이 시나리오 A에서와 같이 작동하는 이유를 파악하고 원하는 결과를 생성하도록 합리적으로 조정합니다. . 모든 것이 잘 진행되고 있습니다.

그런 다음 시나리오 B로 이동합니다. 오류를 유발하기 위해 시나리오를 반복하지만 놀랍게도! — 이제 모든 것이 정상적으로 작동합니다. 추측을 확인하기 위해 버그 A 작업 중에 변경한 내용을 취소하면 버그 B가 다시 나타납니다. 귀하의 버그 수정으로 두 가지 문제가 모두 해결되었습니다. 운이 좋은!

당신은 이것을 전혀 믿지 않았습니다. 시나리오 A의 오류를 수정하는 방법을 생각해 냈는데 왜 시나리오 B에서 작동했는지 알 수 없습니다. 이 단계에서는 두 작업이 모두 성공적으로 완료되었다고 생각하기 쉽습니다. 이것은 매우 논리적입니다. 요점은 오류를 제거하는 것이었습니다. 그렇지 않습니까? 그러나 작업은 아직 완료되지 않았습니다. 시나리오 B에서 귀하의 작업으로 인해 오류가 수정된 이유를 계속 파악해야 합니다. 이유는 무엇입니까? 잘못된 원칙에 따라 작동할 수 있으므로 다른 방법을 찾아야 합니다. 다음은 그러한 사례의 몇 가지 예입니다.

• 솔루션이 오류 B에 맞게 조정되지 않았으므로 모든 요소를 ​​고려하여 무의식적으로 기능 C가 손상되었을 수 있습니다.
• 동일한 기능과 관련된 세 번째 버그가 어딘가에 숨어 있을 수도 있으며, 시나리오 B에서 시스템이 올바르게 작동하려면 버그 수정이 이에 따라 달라집니다. 지금은 모든 것이 좋아 보이지만 언젠가는 이 세 번째 버그가 발견되어 수정될 것입니다. 그런 다음 시나리오 B에서는 오류가 다시 발생하며 거기만 있으면 좋습니다.

이 모든 것이 코드에 혼란을 더하고 언젠가는 가장 부적절한 순간에 머리에 떨어질 것입니다. 모든 것이 작동하는 것처럼 보이는 이유를 이해하는 데 시간을 할애하려면 의지력을 모아야 하지만 그만한 가치가 있습니다.

세 번째 수준의 이해: 왜 작동하는가?

나의 최근 통찰력은 정확히 이 수준과 관련이 있으며, 아마도 내가 이 아이디어를 더 일찍 얻었다면 나에게 가장 큰 이점을 주었을 것입니다.

더 명확하게 하기 위해 예를 살펴보겠습니다: 모듈은 함수 X와 호환 가능해야 합니다. 함수 X에 특별히 익숙하지는 않지만 함수 X와 호환하려면 F 프레임워크를 사용해야 한다는 말을 들었습니다. X와 통합되는 모듈은 그와 정확히 작동합니다.

귀하의 코드는 생애 첫날부터 F 프레임워크와 전혀 접촉하지 않았으므로 구현이 그리 쉽지는 않습니다. 이는 모듈의 일부 부분에 심각한 결과를 초래할 수 있습니다. 하지만 개발에 전념합니다. 코드 작성, 테스트, 파일럿 버전 출시, 피드백 받기, 회귀 오류 수정, 예상치 못한 합병증 발견, 원래 합의된 기한을 지키지 못함, 추가 코드 작성, 테스트, 피드백 커뮤니케이션 받기 등 몇 주를 소비합니다. 회귀 오류 수정 - 이 모든 것은 F 프레임워크를 구현하기 위한 것입니다.

그리고 어느 시점에서 프레임워크 F가 기능 X와의 호환성을 전혀 제공하지 않을 수도 있고, 그 모든 시간과 노력이 완전히 잘못되었을 수도 있다는 것을 갑자기 깨닫거나 누군가로부터 듣게 될 수도 있습니다.

제가 담당했던 프로젝트를 진행하면서 비슷한 일이 한번 있었습니다. 왜 이런 일이 일어났나요? X라는 기능이 무엇인지, 프레임워크 F와 어떤 관련이 있는지에 대한 이해가 거의 없었기 때문입니다. 어떻게 해야 합니까? 다른 모듈에서 수행된 작업을 단순히 반복하거나 X 기능이 수행해야 하는 작업이라고 자신의 말을 받아들이는 대신, 개발 작업을 할당한 사람에게 의도된 작업 과정이 어떻게 원하는 결과로 이어지는지 명확하게 설명하도록 요청하세요.

이 프로젝트의 경험을 통해 우리는 특정 작업을 수행하도록 요청받는 이유를 명확히 이해할 때까지 개발 프로세스를 시작하지 말아야 한다는 점을 배웠습니다. 단호히 거절하세요. 작업을 받으면 첫 번째 충동은 시간을 낭비하지 않기 위해 즉시 작업을 수행하는 것입니다. 그러나 "모든 세부 사항을 확인할 때까지 프로젝트를 동결"하는 정책을 사용하면 낭비되는 시간을 대폭 줄일 수 있습니다.

그들이 당신에게 압력을 가하고 일을 시작하도록 강요하더라도 그 이유를 이해하지 못하더라도 저항하십시오. 먼저, 왜 그러한 임무를 부여받았는지 파악하고 이것이 목표를 향한 올바른 길인지 결정하십시오. 나는 이 모든 것을 힘들게 배워야 했습니다. 나의 모범이 이 글을 읽는 사람들의 삶을 더 쉽게 만들어 주기를 바랍니다.

네 번째 이해 수준: ???

프로그래밍에는 항상 배울 것이 더 많이 있습니다. 그리고 저는 이해라는 주제의 표면만 긁었을 뿐이라고 믿습니다. 수년 동안 코드 작업을 하면서 다른 어떤 수준의 이해를 발견했습니까? 코드와 애플리케이션의 품질에 긍정적인 영향을 미친 결정은 무엇입니까? 어떤 결정이 잘못된 것으로 판명되어 귀중한 교훈을 주었나요? 의견에 귀하의 경험을 공유하십시오.

출처 : habr.com