나쁜 방법이 나쁜 것이라고 이해하는 것이 먼저!

 

시대가 점점 복잡해지고 있습니다. 이 흐름에 살아남기 위한 경쟁력으로 연결과 상호작용이 필요하게 되었습니다. 모든 면에서 협업이 필요한 시기입니다. 협업이라는 개념 자체도 참여자들이 서로의 이익을 얻기 위해 공동으로 작업하는 전통적인 개념을 넘어섰습니다. 시간과 공간 등 모든 연결된 개체에 대한 상호작용 자체를 협업으로 봐야 된다는 것입니다. 이제 더 이상 ‘내 것’, ‘네 것’을 구분하지 않게 되었다고 봐야 합니다. 독자적 기술이란 이제 소용이 없어지는 시대가 될 것이라고도 합니다. 실시간으로 새로운 기술 또는 전혀 다른 비즈니스 모델이 그 기술을 빠르게 대체하고 있기 때문입니다.

현대의 프로그램 개발 업무 자체도 협업을 강조하고 있습니다. 시중에 공개되어 있는 대부분의 프로그램 소스코드들은 오픈된 공간을 통해 공유됩니다. 많은 사람들이 참여하여 생각을 더해 계속 발전되어 갑니다. 리눅스의 개발과 발전 과정을 보면 알 수 있습니다. 오픈소스 정신으로 대변되는 이 활동은 자신이 가진 기술을 공개하면 좀더 나은 기술이 될 수 있다는 정신을 바탕으로 합니다. 마이크로소프트도 깃허브를 인수하여 자신들의 소스를 공개하기 시작하였습니다.

서로 다른 나라의 두 사람이 만났을 때 상대방의 언어와 문화를 이해해야 합니다. 영어라는 공용어를 통해 의사소통을 시도하는 것도 이 때문일 것입니다. 프로그램이라는 언어도 마찬가지 입니다. 협업을 잘하기 위해 지켜야할 일반적인 규칙과 패턴이 있습니다. 이것을 우리는 기본기라고 말합니다.

 

동료들 뒷목 잡게 만드는 나쁜 프로그래밍 습관
칼 비쳐 저/황현우 역/체임 크라우스 감수 | 영진닷컴 | 2020년 03월 20일

 

개발의 세계에는 많은 나쁜 개발 방식이 존재한다. 그리고 이런 방식은 경험이 많은 개발자들이 분노로 얼굴이 붉어지거나, 땀에 흠뻑 젖은 채 두려움에 떨게 할 수 있다. 사실, 이런 반응을 불러일으킬 만한 코드를 경력 초반에 종종 작성하게 될 것이다. 개발자로서 당신의 개발 수준을 향상시키는 방법은 안 좋은 개발 방식이 무엇인지 읽히고 이것을 피하는 것이다.^7쪽

이 책은 왜 이렇게 개발하면 안되는 지를 알려줍니다. 하지만, 그 방법이 독특합니다. 실패하기 위한 조언들로 가득차 있습니다. 모든 규칙을 무시하라고 하고, 더 나쁘게 만들 수 있는 방법들을 설명합니다. 하지만 이런 글 뒤에 ‘주의하기!’라는 코너를 통해 왜 그렇게 하면 안되는지, 왜 그렇게 하면 나쁜지를 알려주는 방식입니다. 다소 가볍고 유머스러운 방식으로 재미있게 읽을 수 있도록 했다고 합니다.

책은 총 11개의 장으로 나눠져 있습니다. 변수, 조건문, 반복문 등 프로그래밍 관련 책의 구성과 다르지 않습니다. 하지만 각 장에 포함된 글꼭지들의 제목은 잘못된 프로그래밍 방법을 그대로 사용하였습니다. ‘불확실한 이름 사용하기’, ‘잘못된 타입 선택하기’, ‘서브루틴의 사이즈를 아주 크게 하기’와 같이 기존에 알고 있던 상식과는 반대되는 제목으로 부각한 것 같습니다. 책 제목에서 보듯이 동료들을 화나게 만드는 나쁜 프로그래밍 방법들 입니다. 이런 나쁜 방법들 뒤에 좋은 방법을 설명하는 것입니다. 어떤 것이 좋은 개발 방법인지 독자 스스로 비교하면서 배울 수 있도록 하였습니다.

책의 처음에 프로그래밍 도구에 대한 이야기부터 시작합니다. 프로그램을 위한 수많은 도구가 있고, 개발자마다 다른 도구를 사용합니다. 일반적인 회사에서 개발 도구를 표준화하기 위한 시도를 많이 합니다. 모두 생산성과 투입되는 리소스 관점의 효율성만 이야기되는 것 같습니다. 그보다 프로그램 개발의 본질이 무엇인지 아는 것이 중요할 것 같습니다. 도구 선정에 시간을 들이기 보다 좋은 결과물을 위해 고민하는 시간이 많아야 할 것입니다.

그 어떠한 도구도 생산성이나 만들어내는 결과물에 극적인 변화를 가져다주지 않는다. 소프트웨어 개발에 있어서 만병통치약이란 없다는 말이다(Brooks, 1995).

만약 이런 도구 선택에 관한 쓸데없는 주장을 계속한다면, 합리적으로 판단할 줄 아는 동료들이 개인의 선호는 때때로 필요에 따라 굽힐 줄도 알야야 한다고 지적할지도 모른다. 좋은 개발자는 어떤 도구를 쓰더라도 좋은 결과물을 만들어낼 수 있다는 데 자부심을 가져야 한다.^22쪽

초급 개발자들에게는 꼭 지켜야 할 기본적인 규칙을 알 수 있습니다. 초급 수준을 벗어나고 지금 현재 프로그래밍을 하고 있는 현업 개발자 분들도 본인의 프로그래밍 습관을 한번 돌아볼 수 있는 계기가 됩니다. 저도 읽으면서 놓치고 있었던 부분에 대해 많이 알게 되었습니다.

개발을 할 때 보통 애자일 형태로 많이 진행합니다. 처음엔 사용자 요구사항에 대해 동작가능한 프로그램을 우선 개발 합니다. 이후 예외 처리를 합니다. 오류 메시지를 정확하게 구현 합니다. 마지막 즈음에 성능 최적화를 위해 코드를 전체적으로 리팩토링을 합니다. 하지만, 프로그램 개발 막바지로 가면서 시간이 부족할 때가 많습니다. 이렇게 되면 후반부에 진행하기로 하였던 오류 메시지 구현, 성능 개선을 위한 코드 최적화 등을 마저 완료하지 못 합니다. 처음 개발시작부터 같이 어느정도는 고려하여 진행하면 후반부에 드는 시간을 조금 줄일 수 있을 것 같습니다.

문제를 보고할 때, 확인하는 사람에 따라 보고의 위치와 내용이 달라야 한다.
사용자용 오류 메시지는 사용자의 기술 수준을 고려해서 작성해야 한다. 사용자를 특정할 만한 방법이 없다면, 사용자가 프로그래머도 아니라 상상해야 한다. stack trace와 오류 코드는 그들에게 전혀 도움이 되지 않는다. 무엇이 잘못되었는지, 그리고 잘못된 것에 대해서 무엇을 할 수 있는지를 비기술적인 언어로 명확히 설명해야 한다.^155쪽

와일드카드를 사용해 임포트하는 것이 세계 최악의 프로그래밍 관행은 아니다. 시실, 몇몇 동료들은 아무 말 없이 이를 계속 밀고 나갈 수도 있다. 하지만 어떤 사람들은 이에 반대할 수도 있다.
모듈에서 가져온 것 대부분을 사용하지 않는데 모든 것을 가져오는 것은 자원을 불필요하게 차지하는 것이라는 반대 의견이 있을 수 있다. 그러나 이는 어떤 언어를 사용했느냐에 따라 다르다.
더 일반적인 반대 의견으로는, 와일드카드를 사용한 임포트가 무의식적으로 이름 충돌을 일으킬 수 있다는 것이다.^169쪽

내가 만든 프로그램 소스를 공개하는 일, 쉬운 것 같으면서도 어렵습니다. 공개하는 것 자체가 실력으로 평가받게 되는 우려가 있기 때문입니다. 오픈 소스로 진행되는 프로젝트에 참여하기 위해서도 두려움이 생깁니다. 실력보다는 참여하기 위한 많은 일반적인 규칙을 이해하는 것이 필요하기 때문입니다.

협업이 중요한 시대, 프로그램 개발자 관련 많은 커뮤니티에 참여할 수 있는 힘을 기르는 것이 필요합니다. 전문성을 인정받게 되는 좋은 방법입니다. 그 과정의 시작은 쉽고 읽기 쉬운 코드를 작성하는 것입니다. 프로그램 개발을 잘하느냐 못하느냐는 그 결과물이 동작하는 것도 중요하지만 누구나 읽고 이해하기 쉬운 코드를 작성해야 된다는 것 입니다. 그리고, 잘못된 개발 방법을 가능한 피하는 것 입니다. 이 책은 이러한 과정의 시작을 도와 줄 것입니다.