Medium - Why Most Code Sucks
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 왜 대부분의 코드가 형편 없을까요? 그리고 여러분의 코드를 개선시키기 위해 할 수 있는 것은 무엇일까요?
Photo by Albertina
제목이 무례했다면 사과드립니다. 꽤나 가혹한 말이죠. 그러나 중요한 것은 이 사실로부터 얻을 것이 있다는 것입니다. 여러분들은 아마 코드를 들여다보면서 완전 엉망진창이군.. 하고 생각하셨던 적이 있으실 겁니다.
완벽한 개발자는 없습니다. 여러분이 생각하시는 어떤 개발자라도 크고 작은 실수를 합니다. 잘못된 변수명, 함수명, 적절치 않은 아키텍쳐 선택, 중복된 코드 등등 다양한 실수가 있고 여러분들은 이런 실수들을 모두 보셨을 겁니다. 여러분이 스스로 실수를 만들고 다른 사람이 지적을 지적하는 과정이나 다른 개발자의 풀리퀘스트를 요청받는 과정에서 말이죠. 이 포스트에서는 여러분이 코드기반에서 이런 혼란을 줄이고 더 나은 코드를 만드는 방법에 대해서 알아볼 것입니다.
The Reason Most Code Sucks
좋은 코드는 특정 기준을 만족합니다. 가장 첫번째는 가독성이 좋다는 것입니다. 많은 코드들이 형편없는 이유는 가독성이 좋지 않기 때문입니다. 프로젝트는 혼자서 하는 것이 아니기 때문에 코드의 가독성은 매우 중요한 요소입니다. 그리고 혼자 개발을 하더라도 나중에 유지보수를 위해서 가독성은 중요합니다. 코드의 가독성을 높이기 위해서 여러분들이 할 수 있는 것은 매우 많습니다. 그 중 하나는 변수, 메소드, 클래스에 적절한 이름을 붙이는 것이죠. elasedTime도 꽤나 괜찮은 변수명이지만 elasedTimeInSeconds는 어떤가요? 더욱 알기 쉬운 이름이 되었습니다.
발음할 수 있는 변수명을 써야 의도를 알아보기 쉽고 오해를 줄일 수 있습니다. 변수명을 잘 짓는 것으로도 코드를 더욱 이해하기 쉽게 만들고 유지보수도 간결하게 만들어줍니다. 함수를 짧게 구성하면 가독성이 좋을 것입니다. 이것은 이해하기도 좋은 구성입니다. 여러 일을 하는 몇백줄 짜리 함수는 여러분이 원하는 것이 아닙니다. 함수는 한가지의 일을하도록 짧게 만드세요. 반드시 한가지 일만 하는 것입니다.
코드를 가독성좋게 만드는 다른 좋은 사례는 들여쓰기를 제한하는 것입니다. 들여쓰기가 너무 많은 코드는 갈수록 읽기가 어려워집니다. 중첩된 if-else 구조 대신에 여러분은 guard 구문을 사용할 수 있습니다. 이것은 필요한 들여쓰기를 줄이는데 도움이 됩니다. 그리고 한줄에 모든 것을 하려고 하지 마세요. 가독성이 매우 중요하기 때문에 코드를 줄이기 위해서 가독성을 해치시면 안됩니다.
코드는 작성하는 것보다 읽을 일이 훨씬 많다는 것을 기억하세요. Robert C. Martin은 가독성에 대해서 다음과 같이 말했습니다. 우리는 오래된 코드를 새로운 코드로 작성하는 노력을 꾸준히 해야한다. 가독성이 좋으면 코딩하기도 쉽다., 코드를 작성할 때는 타인이 이해하기 쉽도록 작성해야 한다.
코드가 가독성이 좋아도 이해하기 어려울 수 있습니다. 이해를 돕고 싶다면 주석을 추가하면 됩니다. 잘 작성된 코드는 무엇을 하려고 하는지 주석을 달 필요가 없지만 그래도 설명을 위해서 주석을 추가하는 선택을 할 수 있습니다. 주석은 프로젝트가 유지보수 단계로 접어들었을 때 무척이나 유용합니다. 그리고 이것이 왜 많은 코드들이 형편없는지 나타냅니다. 유지보수가 어렵기 때문입니다.
여러분은 아마 시간내에 개발을 하느라 진땀을 빼실 겁니다. 마감기한에 작업을 마치기 위해서는 몇가지를 포기해야 합니다. 이상적이지 않치만 그래도 뭐 감안할 수 있을겁니다. 하지만 결과적으로 여러분들은 크나큰 문제를 마주치게 될 것입니다. 시간이 엄청나게 소모되는 것이죠. 요구사항이 변하면 일반적으로 몇줄만 고치면 되지만 이제는 코드 일부분을 통째로 새로 작성해야 되는 것입니다.
여러분은 유지보수를 포기하신 겁니다.
그리고 재밌는 것은 유지보수성은 깨지고 나서야 잘못된 것을 알아채기 쉽다는 것입니다. 대체로 유지보수성은 개발자가 변경하는데 들인 시간이 많을 수록 감소하며 문제가 발생하기 쉽습니다. 유지보수성을 깨트리는 주된 이유중 하나는 코드 중복입니다. 편의를 위해서 종종 중복된 코드가 삽입되는데 많은 경우 이것이 새로운 버그로 이어집니다. 중복된 코드가 있을 경우 대개 한부분만 수정되고 나머지 부분은 잊혀지기 쉽습니다. 결과적으로 새로운 버그가 생기는 것이죠. 이것은 너무나 빈번히 발생합니다. 만약 좋은 코드를 만들고 싶다면 항상 중복 코드는 피해야 합니다.
중복 코드는 코드를 함수나 클래스로 옮기면 해결됩니다. 그리고 원래 사용되던 곳에 함수나 클래스를 호출하면 되죠. 장기적인 관점에서 이렇게 하는게 좋습니다.
그리고 마지막으로 테스트가 불가능한 코드들이 좋지않은 코드입니다. 사실 많은 개발자들이 테스트를 좋아하지 않습니다. 그리고 많은 개발자들이 적절한 테스트를 하는 기술이 부족하죠. 혹은 테스트를 하는 법을 아예 모르기도 합니다. 만약 여러분이 작성한 코드에 대한 테스트를 작성하지 못하면 여러분은 테스트 가능한 코드를 작성하지 못하는 것입니다. 그리고 자연히 여러분의 코드를 테스트 하지 않게 되죠.
어떻게 하면 여러분의 코드를 테스트 가능하게 만들까요?
테스트 가능한 코드는 작성된 코드와는 무관하게 확인되어야 합니다. 테스트 코드는 매개변수를 입력받아서 의존성을 주입받고 변조된 의존성을 주입해서 테스트가 되어야 합니다. 코드의 경로를 작게 하는 것이 직관적으로 테스트하기 쉽게 해줍니다. 모든 코드에 대해서 유닛 테스트를 하려면 모든 코드의 경로가 접근 가능해야 할 것입니다. 즉 모든 코드의 경로가 자체 유닛 테스트가 되는 것이죠.
Conclusion
좋은 코드는 몇가지 기준이 있습니다. 가독성이 좋고 이해하기 쉬우며 유지보수가 잘되고 테스트 하기 쉬워야 합니다. 코드가 이러한 기준에 부합하지 않는다면 뭔가 문제가 있는 것이죠. 여러분 코드의 질을 향상 시키는 법은 매우 많습니다. 가장 구현하기 쉬운 것을 먼저 적용해보세요. 모든 개발자들이 실수한다는 것을 기억하면서 너무 늦기전에 고치세요. 여러분의 코드를 유지보수하는 사람이 폭력적인 사이코패스에다 당신이 사는 곳을 알고있다고 생각하며 코딩하세요 - John Woods
Summary
- 좋은 코드는 가독성이 좋고 이해하기 쉽고 유지보수가 잘되고 테스트 하기 쉬워야 한다.
- 모든 개발자는 실수를한다. 그러니 항상 실수를 줄이려고 노력하자.
