좋은 책을 읽으며 좋은문구가 많기에 시간을 들여 조금씩 옮겨보고자 한다.
실제로 개발을 하다보면 다른사람이 짠 코드나 오픈소스를 사용하게 된다.
이때의 문제점은 다른사람이 짠 코드는 못알아 보겠다는 것이고 , 오픈소스의 경우는 열어봤을 때 프로젝트의 크기가 너무나 커서 어디부터 봐야할지 막막하다는 점이다.
회사에서 개발을 한다고 해도 개발문서가 형편없을 때도 있으며(심지어는 존재하지 않을때도 있다.), 업데이트를 하면 할때마다 문서를 바꿔야 하는데 그걸 깜빡 잊는 개발자가 있다던가...
중견기업에 다니는 친구가 있는데 이 친구의 고민은 프로젝트의 크기가 너무나도 커서 모두 이해하려면 시간이 많이 걸린다는 것이다.
이런 사람들을 위해 이 책에선 "소스를 읽는 법을 배워야 한다" 라고 하고 있다.
좋은문구가 있길래 옮겨본다.
"루크 소스를 읽는 법을 배우게"
해커뉴스에서 블랜드 블룸이 쓴 글이다.
15살쯤에 나는 마이크로소프트 플랫폼을 기반으로 개발 경력을 시작했다.
마이크로소프트에서 비주얼 스튜디오로 각종 기능을 통합하는 소프트웨어 개발자로 근무하기 시작한 것이다. 그리하여 나는 비주얼 베이직 코드를 처음 작성한 이래로 10년 정도의 시간이 흐르자 내부를 들여다 볼 수 없도록 닫혀 있는 라이브러리는 더 이상 사용하고 싶지 않게 됐다.
소프트웨어를 사용하는 것은 소프트웨어를 만드는 것과 다르다. 어떤 소프트웨어를 그것이 담고 있는 핵심 기능을 위해 사용하는 경우에는 작업 자체가 잘 알려진 경로를 따른다. 그 경로를 따라가던 많은 사람들이 이미 이러저러한 문제에 봉착했을 것이며, 소프트웨어를 제작한 사람에게 그러한 문제를 해결해 달라고 요청했을 것이다. 하지만 소프트웨어를 만드는 경우에는 뭔가 새로운 경로를 밟게 된다. 그러한 경로는 너무나 많기 때문에 아무도 가지 않은 길을 걷게 되는 것이 드문 일이 아니며, 그래서 종종 낯선 구석이나 아직 충분히 검증되지 않은 코드의 경로를 밟게된다. 근본적인 문제를 해결하지 못하고 그저 우회해서 피해간 예외적인 상황도 경험하게 될 것이다.
문서는 때로 불완전하다. 심지어는 잘못된 정보를 담고 있는 경우도 있다. 하지만 소스코드는 거짓말하지 않는다.
숙련된 개발자라면 문서보다 소스코드를 읽는 편이 더 빠를때가 많다. 특히 그가 소프트웨어 패키지의 아키텍처에 이미 익숙한 경우라면 더욱 그렇다.
나는 지금 중간 정도 규모의 팀에서 일하고 있다. 이 팀은 여러 개의 스타트업 회사와 함께 프로젝트를 수행한다. 그런데 각 회사의 CTO나 엔지니어들이 우리 팀으로 찾아와서 조언을 구하는 일이 있다.
이 사람들이 자기가 이용하는 기술적 스택에 문제가 있다고 보고하면 나는 이렇게 대답한다.
"소스코드는 읽어보셨나요?"
나는 개발자들에게 자기 프로젝트에서 사용되는 소프트웨어 제품의 소스코드를 로컬 폴더에 복사해 두고 수시로 살펴보라고 권장한다. 많은 사람들이 처음에는 이렇게 하길 두려워한다.
"그 프로젝트는 너무 커요, 원하는 내용을 찾을 수 없다고요!"
"나는 그것을 이해할 만큼 똑똑하지 않답니다."
"그 코드는 정말 끔찍하군요! 도저히 살펴볼 엄두가 안 납니다."
라고 말한다.
하지만 소스코드 전체를 살펴보라는 것이 아니다. 그저 필요한 경로를 따라가면서 부분적으로만 이해하면 된다. 자신의 소프트웨어가 기초로 삼고 있는 플랫폼을 이해하지 못하면서 어떻게 자기가 만든 소프트웨어를 이해할 수 있겠는가? 숙련되지 못한 개발자들이 아름답다고 말하는 것은 대개 표면적인 것에 그칠 때가 많다. 그리고 그들이 끔찍하다고 말하는 것은 최고의 해커가 작성한, 실전에서 단련되어 실제 제품으로 사용될 준비가 돼 있는 견고한 코드인 경우가 많다.
이러한 조언을 하고 나서 1,2년 뒤에, 나에게 찾아와서 자신을 다른 사람이 작성한 코드 속에서 허우적거리면서 헤엄치게 했던 것에 감사를 표하는 사람들이 있었다. 그들은 이제 전보다 나은 개발자가 돼 있다. 그리고 도대체 어떻게 예전에는 소스코드를 읽지도 않으면서 일을 했는지 알 수 없다는 식으로 말하기도 한다.
회사를 운영하는 경우를 생각해보자. 당신의 소프트웨어에서 버그가 발견됐다면 고객들은 그것이 당신의 잘못인지 아니면 리누스나 레일스 개발자의 잘못인지를 따지지 않는다. 그들에게는 당신의 소프트웨어에 버그가 있다는 사실이 중요하다. 다른 소프트웨어에서 발생하는 버그조차 모두 나의 것이 되기 때문에 그들의 소프트웨어도 나의 소프트웨어인 것과 마찬가지다. 뭔가가 잘못됐다면 무엇이 잘못됐는지 원인을 찾아 수정해야 한다. 위험, 유지보수 비용, 그리고 수정하는데 필요한 시간을 최소화하려면 정확한 지점에서 문제를 고쳐야 한다. 경우에 따라서는 재빨리 문제를 우회하는 편이 나을 때도 있다. 때로는 사용하던 컴파일러를 새로 컴파일해야 하는 경우도 있다. 어떤 경우에는 스택의 위쪽에 있는 다른 사람에게 문제를 수정해 달라고 부탁할 수 있을 때도 있지만 버그를 스스로 수정해야 하는 경우도 그만큼 자주 발생한다.
- 내부를 공개하지 않는 소프트웨어 회사의 제품을 사용하는 경우에는 두가지 선택이 있다. 하나는 관용에 호소하는 것이고 다른 하나는 문제를 우회하는 것이다.
- 실력이 부족한 개발자에게 의존하는 오픈소스 회사의 경우에는 위와같이 내부를 공개하지 않는 소프트웨어 회사와 동일한 방식으로 행동하는 경우가 많다.
- 오래된 회사는 제품의 변종이나 패치 등을 유지보수하는데 필요한 근육을 아주 느리게 단련하는 경향이 있다.
진정한 해커는 이러한 사실을 받아들인다. 그것이 내 컴퓨터 위에서 작동하는 것이라면 그건 내 소프트웨어다. 그것에 대해 나는 모든 것을 책임진다. 나는 그 소프트웨어를 잘 이해해야 한다. 소스코드를 이용해 소프트웨어를 만드는 것은 당연한 일이지 예외적인 일이 아니다. 나는 내 환경을 전적으로 통제해야 하며, 내가 사용하는 다른 소프트웨어도 모두 통제해야 한다.
댓글 없음:
댓글 쓰기