다양한 수준의 우수성을 지닌 JavaScript 개발자 간의 차이점

“탁월함은 결코 우연이 아닙니다. 탁월함은 항상 강한 의지, 성실한 헌신, 현명한 행동으로 이루어집니다. 우연이 아니라 당신의 운명을 결정합니다. " - 아리스토텔레스 우리 모두는 자신의 분야에서 최고가 되기를 원합니다. 최고이지만 자신이 원하는 것을 달성하기 위해 시간과 노력을 투자하는 사람은 거의 없습니다. 어떤 직업이든 좋은 사람이 되기는 어렵습니다.

JavaScript 개발자의 우수성을 평가하는 것은 매우 어렵습니다.

훌륭한 JavaScript 개발자의 조건은 무엇인가요?

우리는 다양한 기준에 따라 판단을 내릴 수 있습니다.

코드 품질, 정시 배송, 티켓의 적시 해결(참고: 티켓은 github의 문제와 유사합니다. 여기를 참조하세요)은 참조할 수 있는 몇 가지 표준입니다. 물론 다른 팀원이 티켓을 해결하도록 돕는 것도 포함됩니다.

위의 사항은 정확한 측정값을 제공하지 못하는 것 같습니다. 어떤 식으로든 도움이 되지 않는 것을 리팩터링하고 싶기 때문에 아름다운 코드를 작성하기 위해 전체 프로젝트를 두 달 동안 연기합니다. 우리 모두는 티켓을 닫는 것이 아무 의미가 없다는 것을 알고 있습니다.

고려해야 할 변화 요인이 많습니다. 10명의 프로그래머에게 좋은 개발자가 무엇이라고 생각하는지 묻는다면, 나는 10가지의 다른 대답을 듣게 될 것이라고 확신합니다.

여러분도 지금 그 정의에 대해 고민하고 계시리라 믿습니다.

한동안 이 정의에 대해 고민하고 있었기 때문에 한번 알아보기로 했습니다.

일에 집중하세요

개발자라면 누구나 하는 일을 찾고, 그 일을 어떻게 하는지에 따라 개발자의 성과를 분류하고 싶습니다.

한 가지만으로 업계의 좋은 평가를 내리기에는 너무 단순하지만 그래도 한번 시도해 보려고 합니다.

이제 소금 한알 넣어도 됩니다.

좋은 선택이었다는 것을 증명하도록 노력하겠습니다. 이는 모든 개발자가 하는 일이며 좋은 개발자와 평범한 개발자를 구분합니다.

모든 개발자는 때때로 형편없는 코드를 작성합니다.

현실을 직시하자면, 당신과 나는 때때로 너무 쓰레기이고 부끄러워서 누구에게도 보여주고 싶지 않은 코드를 작성합니다.

우리 모두는 때때로 형편없는 코드를 작성하는 이유가 있습니다. 우리 각자는 자신만의 타당한 이유가 있기 때문에 타당한 이유가 무엇인지 논의하지는 않겠습니다.

코딩의 잔혹함을 보여주기 전에 우리가 형편없는 코드를 작성하는 이유를 살펴보겠습니다. 그러면 우리는 코드 냄새로 인해 막히거나 어려움을 겪는 것을 피할 수 있습니다.

정크 코드를 작성하는 일반적인 이유

1. 시간에 쫓기다

현재 정크 코드를 작성하는 가장 일반적인 이유는 “시간 부족”입니다. 고객에 대한 약속, 빡빡한 일정, 보류 중인 새 릴리스 등이 모두 원인일 수 있습니다.

　2. 깊은 고통에 빠진다

기존 코드 베이스가 너무 쓰레기라서 좋은 코드를 작성하려고 애쓰고 싶지도 않다. 당신은 당신이 무엇을 하든 어느 시점에서 붕괴될 이 쓰레기 코드 기반을 저장할 방법이 없다는 것을 알고 있습니다.

　3. “일만 끝내고 퇴근합니다”

　 개발자로서 우리는 가끔 서로 다른 프로젝트 그룹에서 일할 때가 있습니다. 마지막 몇 줄의 코드를 작성한 후 새로운 프로젝트로 이동해야 한다면 이는 다른 사람들에게 큰 영향을 미치지 않습니다.

이 프로젝트에 대한 귀하의 시간이 거의 끝나가고 있으며 더 이상 아무도 귀하의 코드를 검토하지 않을 것이라는 점을 알아 두십시오. 따라서 커밋하고 푸시한 다음 단위 테스트를 사용하여 문제가 없는지 확인하면 됩니다.

진실을 보세요

우리 모두는 때때로 쓰레기 코드를 작성합니다. 이것은 우리 모두가 나쁜 개발자라는 뜻인가요?

당연하지. 모든 사람이 때때로 나쁜 코드를 작성하기 때문에 그것만으로는 아무 의미가 없습니다.

하지만 시간이 지나면서 저는 점차 개발자에 대한 놀라운 사실을 발견하게 되었습니다.

정크 코드를 작성한 후 우리가 어떻게 행동하는가는 개발자 자격에 대한 근본적인 테스트입니다.

좀 믿기지 않지만 사실이에요. 가비지 코드를 작성하고 있다는 인식과 향후 이러한 일이 다시 발생하지 않도록 방지하기 위해 취하는 조치는 코드 작성 방법과 일반적인 코드 작성 접근 방식을 반영합니다.

개발자의 우수성을 평가하는 데 정크코드가 얼마나 관련이 있나요?

관련이 많습니다.

론을 예로 들어보겠습니다. Ron은 오늘 잘못된 코드를 작성했고 그것에 대해 불만을 느꼈습니다. 5단계 깊이의 불쾌한 Backbone 모델 상속 체인으로 인해 Ron은 모든 것을 손상시키지 않고는 단 한 줄의 코드도 변경할 수 없었습니다.

Ron은 이 문제를 우회하기 위해 아주 쓰레기 코드를 작성했습니다. Ron이 제 시간에 코드를 전달했기 때문에 모두가 행복했습니다. 론 자신만 빼고요.

그는 팀장에게 무슨 일이 있었는지 말했습니다. 그들은 함께 문제를 해결하는 방법을 고민했습니다. 그들은 상속 체인을 깨고 이를 수평적 구성 모듈로 나누는 것이 최선의 해결책임을 분명히 했습니다.

Ron은 상사에게 상사와 방금 논의한 재건 계획을 실행할 시간을 달라고 요청했습니다.

Roger도 오늘 끔찍한 코드를 작성했습니다. 그는 동료 개발자들에게 이상한 5레벨 심층 Backbone 모델 상속 체인을 우회하기 위해 놀라운 해킹을 사용했다고 말했습니다. 그는 전체 구조를 돌아보고 제 시간에 맞춰 배송할 준비가 되어 있었습니다.

로저 본인도 매우 만족했고 더 이상 개선할 필요가 없다고 느꼈습니다.

JavaScript 개발자의 네 가지 유형

쓰레기 코드 작성에 대한 태도에 따라 프로그래머를 가난한 사람부터 우수한 사람까지 네 가지 범주로 나눌 수 있습니다.

네 가지 유형의 개발자를 동시에 만나본 적이 없다고 말씀해 주세요.

Barney - 나쁜 JavaScript 개발자

Barney는 자신이 형편없는 코드를 작성하고 있다는 사실에 개의치 않습니다. 그가 관심을 갖는 것은 일을 제 시간에 완료하는 것뿐입니다. 코드가 정상적으로 실행된다면 문제가 없을 것입니다.

Barney가 작성한 가비지 코드는 때때로 전체 프로젝트 진행을 방해합니다. 코드 작업을 할 때 항상 많은 문제가 발생하고 이로 인해 전체 프로젝트의 진행이 지연됩니다. 반면 Barney는 새로운 것을 배울 필요가 없다고 생각합니다.

그는 이미 작업을 완료하기 위해 JavaScript에 대해 알아야 할 모든 것을 알고 있습니다.

Bill - 평범한 JavaScript 개발자

Bill은 자신이 쓰레기 코드를 작성하고 있다는 사실을 깨닫지 못합니다. 그는 팀의 합의와 린트 규칙을 따랐으며 자신이 한 일에는 아무런 문제가 없다고 생각했습니다. 그러나 그는 전체 프로젝트 구조와 다양한 구성 요소가 서로 상호 작용하는 방식을 이해하는 데 시간을 투자하지 않았습니다.

결과는 안타깝게도 혼란입니다.

Bill은 주요 디자인을 선택하기 전에 누구와도 상의하지 않았습니다. 그는 원하는 것은 무엇이든 합니다. 그는 자신의 결정에 도움이 된 1년 전 블로그 게시물 세 개를 읽었습니다.

나는 Bill의 코드에 들어가는 것이 내 전쟁처럼 느껴진다고 자주 말하는데, 한 번의 잘못된 움직임으로 모든 것이 눈앞에서 터져버릴 것입니다.

Roger - 좋은 JavaScript 개발자

앞서 Roger의 유형에 대해 언급했습니다. 쓰레기 코드를 작성하고 있다는 점을 충분히 인식하십시오. 그는 자신이 코드를 잘 작성하고 싶다면 코드가 어떤 모습일지 알고 있습니다. 그는 등을 두드리며 계속해서 이런 쓰레기 같은 글을 썼습니다.

Roger의 가장 큰 문제는 변화를 시도하지 않았다는 것입니다. 그는 요청받은 일을 잘했고 그 일을 잘 해냈습니다. 그러나 그는 상황을 변화시키기 위해 시간과 노력을 들기보다는 상황을 있는 그대로 놔두기를 원합니다.

Ron – 뛰어난 JavaScript 개발자

Ron은 뛰어난 프로그래머이지만 가끔 쓰레기 코드를 작성해야 하는 경우도 있습니다.

론이 남들과 다른 점은 론이 그 쓰레기 코드를 작성할 때 자신에게도, 다른 누구에게도 이런 상황이 다시 발생하지 않도록 하는 방법에 대해 진지하게 고민한다는 점입니다. Ron은 어떤 유형의 리팩토링이 필요한지, 어떤 기술 솔루션을 변경하거나 개선할 수 있는지 파악합니다.

그런 다음 Ron은 이러한 조사 결과를 바탕으로 이러한 변경 사항을 홍보하기 위한 조치를 취할 것입니다.

냉철한 현실

회개해야 합니다. 저는 여기 로저입니다. 하지만 나도 론이에요. 나는 또한 나도 모르게 한 번 이상 우연히 Bill이 되었다고 믿습니다. 바니처럼 살아본 적은 없는 것 같은데, 누가 알겠어요? 우리 모두는 지속적인 우수성을 향한 길을 오가고 있습니다. 때로 우리는 평범할 때도 있고, 때로 선하거나 탁월할 때도 있습니다. 항상 나쁜 사람이 되지 않으려고 노력해요.

우리가 가장 오래 지속하는 역할이 우리가 어떤 개발자인지를 결정합니다.

솔직히 말해서 평범한 개발자에서 좋은 개발자가 되기 위해서는 다른 것보다 더 많은 지식과 경험의 축적이 필요합니다. 하지만 좋은 것에서 위대한 것으로 도약하려면 태도 하나만 바꾸면 됩니다.

“기억하세요. 훌륭해지기 전에 먼저 나빠져야 합니다. 하지만 나빠지기 전에 먼저 노력해야 합니다.

위 내용은 JavaScript 개발자의 우수성 수준의 차이입니다. 자세한 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요.