모두 수락하지만, 아무것도 이해하지 못한다
코드 제안을 수락하기 위해 엔터를 누르는 것이 스크롤을 내려 지나치는 것보다 노력이 덜 듭니다. 키 하나만 누르면 코드는 당신의 것이 됩니다. 하지만 그 코드를 읽고 이해하는 속도는 전혀 빨라지지 않았습니다.
코드를 수락하는 속도와 이해하는 속도 사이에는 간극이 존재합니다. 이 간극에서 실수가 발생합니다.
기술 부채에는 과거에 명확한 원인이 있었습니다. 촉박한 마감 기한이 있었거나, 편법을 썼거나 하는 식이었죠. 원인을 분명히 짚어낼 수 있었습니다. 이제는 평온한 화요일에도 부채를 쌓습니다. 코드가 괜찮아 보인다는 이유로 여섯 개의 제안을 연달아 수락합니다. 아무도 재촉하지 않았지만, 코드는 검토되지 않은 채 남겨집니다.
브라이언 커니핸(Brian Kernighan)은 1974년에 디버깅은 프로그램을 작성하는 것보다 두 배 더 어렵다고 말했습니다. 그는 인간이 작성한 코드를 두고 한 말입니다. 적어도 인간은 자신이 한 일을 이해하니까요.
오늘날의 제안은 린터(linter)를 통과하고 테스트까지 통과할 수 있습니다. 하지만 여전히 잘못된 가정에 기반할 수 있습니다. 이는 사람들이 제안을 '코드'가 아닌 '결과물(output)'로 읽기 때문에 발생합니다. 보기 좋은 결과물은 그대로 승인됩니다.
만약 모델이 코드와 테스트를 모두 작성한다면, 당신은 학생이 직접 쓴 답안지로 숙제를 채점하고 있는 셈입니다. 이는 로직이 타당한지 알려주지 않습니다. 예외 케이스(edge cases)가 처리되었는지도 알려주지 않습니다. 코드가 자신의 에디터에 자신의 스타일로 나타나면 이 사실을 잊기 쉽습니다.
이는 실질적인 문제를 일으킵니다:
- 읽어본 적 없는 코드를 디버깅하게 됩니다. 몇 주 뒤 무언가 고장 나면, 처음부터 다시 시작해야 합니다.
- 예외 케이스에서 실패합니다. 제안된 코드는 해피 패스(happy path)는 잘 처리합니다. 널 체크(null check)도 포함되어 있죠. 하지만 비즈니스에 필요한 특정 로직은 놓치고 있습니다.
- 자신의 풀 리퀘스트(pull request)를 방어할 수 없습니다. 리뷰어가 왜 이 메서드를 선택했는지 물으면 답할 말이 없습니다. 당신이 결정을 내린 것이 아니라, 그저 거절하지 않았을 뿐이니까요.
이 도구들은 유용합니다. 코드베이스를 탐색하거나 새로운 기능을 계획하는 데 도움을 줍니다. 문제는 당신의 태도입니다. 모든 제안을 단순히 훑어보는 것이 아니라, 읽고 결정해야 할 대상으로 대해야 합니다.
보일러플레이트(boilerplate)나 간단한 스크립트라면 속도가 중요할 수 있습니다. 하지만 비즈니스 로직이나 보안 문제라면 접근 방식이 달라져야 합니다. 마치 그 코드를 당신이 책임져야 할 것처럼 읽으십시오. 실제로 그렇게 될 것이기 때문입니다.
대신 다음과 같이 하십시오:
- 코드를 요청하기 전에 모델과 해결 방안을 먼저 논의하십시오.
- 마치 직접 작성한 것처럼 diff를 검토하십시오.
- 코드를 수락하기 전에 도구에게 그 근거를 설명해 달라고 요청하십시오.
- 제안을 주니어 개발자의 작업물처럼 대하십시오. 유용하지만 절대적인 진리는 아닙니다.
- 의외라고 느껴지는 줄에서는 속도를 늦추십시오. 의외성은 하나의 신호입니다.
키 입력의 비용은 낮아졌지만, 당신의 책임은 낮아지지 않았습니다. 이해 없는 속도는 그저 빠른 부채를 쌓는 것일 뿐입니다.
Source: https://dev.to/cloudx/accept-all-understand-none-4dob
Optional learning community: https://t.me/GyaanSetuAi