원 저자 : [Jay]
더 나은 개발자가 되는 8 가지 방법
이 글은 NewRelic 블로그의 “8 Ways to Become a Better Coder” 라는 글의 한글 번역입니다. 오역이 있을 수 있습니다.
당신의 프로그래밍 스킬을 향상시키는 방법에 대해 진지하게 얘기해 봅시다. 시작!
“쩌는 프로그래머 되기”는 커리어 향상 목표로 삼기에 좋아 보이지만 사실 간단한 일은 아닙니다. 예를 들어 “더 잘하고 싶다” 는 말에는 “더 잘”하는게 어떤 건지 알고 있어야 한다는 가정이 필요하죠. 사실 많은 사람들이 더 나아지기를 원하지만 어떻게 해야하는지에 대해서는 전혀 모르는 경우가 많습니다.
그래서 제가 프로그래밍 스킬을 향상시킬 수 있는 8가지 실행 가능한 가이드라인을 알려드릴게요. 순서대로 따라하시면 됩니다. 이 지혜의 조각들은 컴퓨터 산업의 지난 35년 간 축적되었고 이를 밝히고 기록한 사람들은 이를 발에 있는 메뚜기로 사용해 왔습니다.
1. 배울 것이 얼마나 많은지 상기하세요.
무언가를 배우는 첫 걸음은 그것을 모른다는 것을 깨닫는 것입니다. 어찌보면 당연한 얘기지만, 경험 많은 프로그래머들은 스스로 알고 있다는 착각을 극복하는데 얼마나 많은 시간이 필요했는지 알고 있습니다. 많은 전산과 학생들이 “나는 존잘” 이라는 허세, 모든 것을 알고 있다는 강한 확신과 그것을 직장에 가서 동료들에게 증명해보이고픈 강한 욕망을 가지고 학부를 졸업합니다. 다시 말해 “나는 내가 뭘 하고 있는지 알아!” 라는 태도는 새로운 것을 배우는 길에서 멀어지게 합니다.
2. 당신이 맞다는걸 증명하려고 하지 마세요
(단지 잘 하는게 아니라) 훌륭해지기 위해서는 반드시 경험에서 배워야 합니다. 하지만 경험은 우리에게 잘못된 행동을 반복하게 하고 나쁜 습관을 만들어 줄 수도 있으니 조심해야 합니다. 아마 8년 경력의 프로그래머… 8년 간 똑같은 경험만 8번 반복한 프로그래머를 본 적이 있을겁니다. 그렇게 되지 않기 위해서는 당신이 하는 모든 일을 다시 돌아보고 스스로에게 질문하세요. “어떻게 하면 이걸 더 잘 할 수 있지?”
초짜 개발자들(그리고 너무 경험이 많은 개발자들)은 자기 코드를 보면서 그 놀라움에 스스로 감탄합니다. 그들은 자기 코드가 잘 돈다는것을 증명하기 위해서 테스트를 작성합니다. 코드가 잘 못 도는 경우를 찾는게 아니라요. 진정으로 훌륭한 프로그래머는 적극적으로 어디가 잘 못 됐는지를 찾습니다. 자기가 놓친 결함은 결국 사용자가 발견하게 되리라는 것을 알고 있기 때문이죠.
3. “동작하는 코드” 는 끝이 아니라 시작입니다.
네, 첫 걸음은 항상 스펙에 따라 동작하는 소프트웨어를 작성하는 것이죠. 평균적인 프로그래머들은 여기서 끝내고 다음으로 이동합니다.
하지만 일단 “끝”났다고 거기서 멈추는 것은, 스냅 사진을 한 장 찍고 그것이 예술 작품이 되기를 기대하는 것과 같습니다. 훌륭한 프로그래머들은 첫 반복은 그저 첫 반복일 뿐이라는 것을 알고 있습니다. 당신이 작성한 소프트웨어는 동작하지만 — 축하드립니다! — 끝난 것은 아닙니다. 자 이제, 더 낫게 만드세요.
이 과정의 일부는 무엇이 “더 나은” 것인지를 정의하는 것입니다. 더 빠르게 하는 것이 가치있는지? 더 문서화하기 쉽게? 더 재사용하기 편하게? 더 신뢰성있게? 대답은 각 어플리케이션에 따라 달라지지만, 이 과정 자체는 동일합니다.
4. 세 번 다시 작성하세요.
좋은 프로그래머들은 동작하는 소프트웨어를 작성합니다. 훌륭한 프로그래머들은 엄청나게 잘 동작하는 소프트웨어를 작성합니다. 첫 시도에서 그렇게 만들기는 매우 어렵습니다. 최고의 소프트웨어들은 보통 세 번 다시 작성됩니다:
- 우선, 스스로(혹은 고객)에게 그 해결책이 가능한 것임을 증명하기 위한 소프트웨어를 작성하세요. 다른 사람들은 그게 개념 증명인지 눈치채지 못 할 지도 모르지만 당신을 그렇게 생각하고 만듭니다.
- 두 번째, 동작하게 만드세요.
- 세 번째, 올바르게 만드세요.
최고의 개발자들의 작업을 보면 이런 단계로 일하는 것에 확신이 서지 않을 수도 있습니다. 그들이 하는 모든게 끝내주는 것 처럼 보이지만, 사실 록스타 개발자들 조차 그들의 소프트웨어를 다른 사람들에게 보여주기 전에 보통 저 첫 번째, 두 번째 버전을 이미 만들었고 내다 버렸을 겁니다. 만든 코드를 버리고 다시 짜는 것은 “더 낫게 만들기”를 당신의 작업 흐름에 녹여넣을 수 있는 강력한 방법이 될 수 있습니다.
다른 건 제쳐두고라도 “세 번 다시 작성하기”는 최소한 당신의 문제에 얼마나 많은 접근법이 있는지를 가르쳐 줄 수 있습니다. 관습적인 방법에만 얽매이는 걸 막아주기도 하고요.
5. 코드를 읽으세요. 많이 읽으세요.
아마 이 조언은 나올 거라고 생각했을 겁니다. 사실 프로그래밍 스킬을 향상시키는 가장 일반적이면서도 가장 값진 방법입니다. 다른 사람의 코드를 읽는 것이 왜 그렇게 중요한지, 그 이유를 말하는 건 조금 덜 뻔할지도 모르겠네요.
다른 사람의 코드를 읽으면 다른 사람들이 프로그래밍 문제를 어떻게 푸는 지를 볼 수 있습니다. 그걸 단지 문자 그대로 보지만 말고 하나의 수업이나 도전 과제로 생각해보세요. 더 잘하기 위해서 스스로 이렇게 질문해 보세요:
- 나라면 저 코드 블록을 어떻게 짰을까? 어떻게 다르게 할 수 있을까? 다른 해결책이 있나?
- 뭘 배웠나? 저 기술을 내가 짰던 코드에 어떻게 적용시킬 수 있을까?(“나는 저기 recursive descent를 쓰는 건 생각도 못해봤어…”)
- 이 코드를 어떻게 하면 개선할 수 있을까? 만약에 확실히 개선할 수 있고 그게 오픈 소스 프로젝트라면? PR을 보내자!
- 원 작성자의 스타일로 코드 작성해보자. 이 연습은 그 코드를 만든 사람의 머리 속으로 들어가는 연습이 되고, 당신의 공감 능력을 향상시키는데 도움이 됩니다.
이 단계들을 그저 생각만 하지 말고 직접 대답을 적어보세요. 개인 저널이든, 블로그든, 코드 리뷰 프로세스에서든, 아니면 다른 개발자들과의 커뮤니티에서든 다 좋습니다. 그냥 도움을 줄 수 있는 친구에게 문제를 설명하는 것처럼 당신의 생각을 적고 공유하는 것은 왜 당신이 어떤 다른 사람의 코드를 보고그런 생각을 했는지 이해하는데 도움을 줄 수 있습니다. 이모든 것은 당신의 강점과 약점을 냉정하게 판단— 아까 언급한 자기 반성 — 할 수 있게 해줍니다.
경고: 단지 코드를 많이 읽는다고 해서 훌륭한 프로그래머가 되지는 않습니다. 위대한 문학 작품을 많이 읽기만 한다고 작가가 되는 건 아니죠. 수 많은 개발자가 답을 찾기 위해서 오픈 소스나 다른 소프트웨어들을 보지만 대개 비슷한 문제를 해결하는 것 처럼 보이는 코드를 복사해서 붙여넣기만 합니다. 이렇게 하는 것은 다른 사람의 지혜를 생각 없이 맹목적으로 받아들이는 것이기 때문에 사실상 당신을 더 나쁜 프로그래머로 만듭니다.
6. 코드를 작성하세요. 숙체처럼 하지 말고요.
개인적인 프로그래밍 프로젝트를 진행하는 것에는 많은 장점이 있습니다. 우선 당신의 현재 직장에서는 사용하지 못하지만 당신의 다음 직장을 위한 시장 가치를 여줄 수 있는 도구나 기술을 배울 수도 있죠. 오픈 소스 프로젝트에 기여를 하든 지역 사회 단체의 공익 사업 작업을 맡든 당신은 새로운 기술과 자신감을 얻을 수 있을 겁니다. (개인 프로젝트는 미래의 고용주에게 당신이 배움을 멈추지 않는 사람이라는 증거가 되어줄 수도 있습니다.)
취미로 코드를 작성하는 것의 또 다른 장점은 당신 혼자서 해내야만 한다는 점입니다. 어려운 일이라고 해서 다른 사람에게 넘길 수 없으니 너무 일찍 도움을 요청해버리거나 하는 일은 없습니다.
프로 팁: 개인 프로젝트를 할 때 실패하지 않을 것만 하지는 마세요. 오히려 실패할 필요가 있습니다! 회사 일에서는 실패하고 싶지 않겠지만요.
7. 어떤 방법으로든 다른 개발자와 일대일로 일해보세요.
다른 사람의 말을 듣는 것은 도움이 됩니다. 짝프로그래밍일 수도 있고, 해커톤에 참가할 수도 있고, 아니면 프로그래밍 사용자 그룹에 들어가는 것일 수도 있습니다. 오픈 소스 프로젝트에 기여 중이라면 다른 개발자나 사용자들의 피드백에 주의를 기울여 보세요. 그 사람들의 비판에 어떤 공통점이 있나요?
운이 충분히 좋다면 코딩 기술에서부터 커리어 결정까지 모든 부분에서 당신이 믿고 따를 수 있는 개인적인 멘토를 만나게 될지도 모릅니다. 이런 기회가 있다면 놓치지 마시길.
8. 도구가 아니라 기법을 배우세요.
프로그래밍 언어, 도구, 방법론 등은 흥했다가도 없어집니다. 그래서 가능한 한 많은 경험을 가능한 한 다양한 언어와 프레임워크에서 쌓는게 좋습니다. 프로그래밍의 근본에 집중하세요. 기본은 절대 변하지 않습니다. 프로그래밍하는 것 보다 아키텍쳐에 더 주의를 기울이세요. 만약 어떤 일을 하는데 오직 하나의 올바른 방법만 있다는 확신이든다면 아마도 현실성 검사가 필요한 때 일겁니다. 도그마는 당신이 새로운 것을 배우고 변화를 받아들이는데 족쇄가 될 수 있습니다.
좀 더 얘기할 수도 있습니다만, 자기 향상의 핵심 교리는 멈춰야 할 때를 아는 것이랍니다.