David J. Malan (데이비드 J. 말란)
들어가기 전에
규모가 큰 프로그램을 작성할 때는 보통 한 사람이 아닌 여러 사람들이 함께 작업을 진행하게 됩니다. 이 때는 내가 기여한 부분이 프로그램에 오류를 발생시키지 않도록 주의를 기울여야 합니다. 또한 코드의 내용 뿐만 아니라 그 형식도 신경써야 합니다. 같은 내용이라 하더라도 어떻게 표현하느냐에 따라 코드를 이해하고 수정하는 속도가 달라질 수 있기 때문입니다. 코드의 정확성과 디자인을 어떻게 잘 관리할 수 있을지 배워봅니다.
학습 목표
코드의 정확성과 디자인을 관리하는 방법을 설명할 수 있습니다.
핵심 단어
강의 듣기
check50
check50 프로그램을 이용하면 과제를 잘 수행했는데 자동으로 검사할 수 있습니다.
물론 이 프로그램은 cs50 강의를 위해서만 작성되었지만, 실제로 많은 사람들이 함께 작업하는 환경에서 이와 같은 자동 검사 프로그램은 많은 도움이 됩니다.
여러 사람들이 각자 한 부분을 맡아 코드를 작성할 때 각자가 수정한 코드가 전체 프로그램의 정확성을 해치지 않는지 쉽게 확인할 수 있기 때문입니다.
style50
style50 프로그램을 이용하면 코드가 심미적으로 잘 작성되어 있는지 검사할 수 있습니다.
공백의 수나 줄바꿈과 같은 것들은 코드의 실행에 직접적으로 영향을 주지는 않지만 코드를 작성하는 사람들이 코드를 읽고 이해하는데 영향을 주기 때문입니다.
가령 아래와 같이 for 루프를 작성할 때도 사람에 따라 여러 방식으로 작성할 수 있습니다.
for (int i = 0; i <= 10; i++)
{
printf("#\n");
}for (int i = 0; i <= 10; i++){
printf("#\n");
}for (int i = 0; i <= 10; i++){ printf("#\n"); }많은 회사들은 사내에서 코드를 작성할 때 특정한 스타일 가이드를 따르도록 합니다.
여러 사람들이 코드를 작성하기 때문에 서로 불필요한 오해를 없애고, 코드를 이해하는 데 드는 비용을 최소화하기 때문입니다.
고무 오리
때로는 코드에 포함된 오류를 해결할 때 앞서 소개한 help50, debug50, check50과 같은 프로그램들이 존재하지 않거나, 있다 하더라도 디버깅에 큰 도움이 안 될 수 도 있습니다.
이 때는 먼저 한숨 돌리고 직접 곰곰히 생각해보는 수 밖에 없습니다.
한가지 유명한 방법으로 ‘고무 오리’와 같이 무언가 대상이 되는 물체를 앞에 두고, 내가 작성한 코드를 한 줄 한 줄 말로 설명해주는 과정을 거쳐볼 수 있습니다.
이를 통해 미처 놓치고 있었던 논리적 오류를 찾아낼 수도 있습니다.
생각해보기
만약 여러 사람들이 함께 참여하는 프로젝트에서, 각자가 작성하는 코드 스타일 서로 다르다면 어떤 비효율적인 일이 발생할까요?
comment
서로의 스타일이 다를 경우 서로가 예측 불가능한 위치에 코드를 갖다 두거나 메서드 사용법, 이름 규칙 등이 달라지게 된다.
이로 인해 각자의 코드를 이해하는 데 걸리는 시간은 물론 타인의 코드를 사용할 때도 쉽게 사용할 수 없게된다.
예를 들어 Data를 가져올 때 누군가는 get을 사용하고, 다른 사람은 fetch를 사용하는 상황에서
다시 또 누군가는 get을 연산 결과를 얻을 때 사용한다면
서로 메서드가 구현되어있음을 인지하지 못하거나 잘못된 메서드를 호출하는 등의 문제가 생길 수 있겠다.
각자가 작성하는 코드 스타일이 다른 경우, 서로가 의도한 동작과 부합하더라도 작성 형태가 다르기 때문에 이해하는 데 시간이 걸릴 수 있다.
이를 위해 코드 스타일 하나로 통일하는 것을 합의하면, 좀 더 쉽고 빠르게 코드를 이해할 수 있을 것이다.
서로가 만든 코드를 이해하거나 수정하기가 어려울 것 같습니다.
정확하게 구조를 이해하지 못 할 것이고, 그렇기 때문에 통합된 결과물이 아닌 복잡하고 파편화된 결과물이 만들어져 유지보수에 어려움을 겪을 것이다.
에러가 발생 했을때 이를 수정하거나 유지보수하는일이 매우 어려워짐
코드 스타일이 서로 다르면 가독성과 이해도가 떨어질 것입니다.
또한 이슈 발행 시 해결이 어려울 것입니다
코드 스타일이 통일되지 않아서 코드의 가독성이 떨어져 유지 보수하는 일이 힘들어 질것이다.
각자 작성하는 코드 스타일이 다르다면 코드 읽기가 매우 힘들 것 같습니다.
만약 코드에서 버그가 발생해 디버깅을 할 때에도 많은 불편함이 따를 것입니다.
서로의 코드를 알아보기가 어려워 협업이 힘들 것 같습니다
일단 상대방이 만든 코드를 내가 이해하기 힘들어짐으로서 소통이 힘들어지고, 나중에 각자의 몫을 합치는 과정에서 여러가지 복잡한 문제를 마주할 가능성이 높아짐.
코드를 이해하는데 불필요한 시간이 발생하고, 경우에 따라 코드를 잘못 해석할 수도 있다. 따라서 코드의 유지보수가 어려워진다.
여러 사람이 참여하는 프로젝트에서 코드 스타일이 일관되지 않으면 다음과 같은 문제가 발생할 수 있어
각 개발자가 다른 스타일로 코드를 작성하면, 다른 사람이 그 코드를 이해하거나 수정하는 데 시간이 더 많이 걸릴 수 있어. 이는 팀 전체의 생산성을 저하시킬 수 있어.
코드 스타일이 일관되지 않으면, 코드 리뷰 과정에서 스타일 문제에 집중하게 되어 실제 로직이나 버그를 놓칠 수 있어.
서로 다른 스타일로 코드를 작성하면, 코드를 병합할 때 충돌이 더 자주 발생할 수 있어. 이는 병합 과정을 복잡하게 만들고, 실수를 유발할 수 있어.
이런 문제를 방지하기 위해, 팀은 일관된 코드 스타일 가이드를 정하고 이를 따르는 것이 좋아. 이를 위해 코드 포맷터 도구( Prettier, ESLint 등)를 사용하면, 코드 스타일을 자동으로 일관되게 만들 수 있어. 이런 도구를 사용하면, 개발자는 코드 스타일에 신경 쓰지 않고 로직에 집중할 수 있게 돼.
소통에 오류가 발생할 수 있습니다.
사람마다 코딩 스타일이 다 다르다.
코드를 가독성 좋게 작성하는 사람, 효율적으로 작성하는 사람도 있지만,
효율을 중시하면서도 짧은 코드를 작성하는사람, 변수와 함수명, 코드간격 등을 간략하게 쓰는사람도 있다.
이러한 각기다른 스타일의 개발자들이 모여서 표준을 정하지 않고 개발을 하면 코드리뷰 및 추후 유지보수가 어려워진다.
그래서, LLVM/Clang 패키지를 설치하면, "clang-format" 이 함께 따라온다.
이 Clang-format 을 Visual Studio Code와 연동하거나, Vim 등의 텍스트 편집기에 연동한 이후, 원하는 코드 스타일로 포매팅을 할 수 있다.
대표적으로 Microsoft(Visua Studio), LLVM, Google, WebKit, Chromium, Mozilla, GNU 방식 등, 다양한 방식을 지원한다.
만약, 당신이 입문을 하는 입장이라면(예컨대 나와 같이), 적절한(?) 코드 스타일을 익히는 편이 좋을 수 있다.
LLVM 방식은 K&R 방식 처럼 포매팅이 되는 편이여서, Google 방식 또는 Microsoft 방식이 많은 편이다.
물론, 코드 포맷을 스스로가 수정하여 입맛에 맞게 변경할 수도 있다.
어떤 기업체에 들어간다면, 그 회사에 방식을 맞춰야겠지만, 코드 포맷을 지키는 습관을 가진다면, 코드를 읽는데에도 수월함을 갖게 될 것이기 때문에, 스스로가 무슨 방식에 익숙하지 않다면, 지금 보기 편한 방식으로 선택하는 것이 좋을 것이다.
가독성이 떨어지며,
형태의 차이로 오해가 발생하기 쉽다.
서로의 코드를 이해하는데 시간이 들며 생산성이 떨어집니다.
각자의 코드를 이해하기 어렵고 프로젝트에 더 많은 시간을 소요하게 된다.
코드를 통합할 때 서로의 코드를 읽고 이해하는데 어려움을 초래할 수 있고 유지 보수에 어려움이 생긴다. 이는 코드 품질 및 생산성을 저하시킬 수 있다.
만약 여러 사람들이 함께 참여하는 프로젝트에서, 각자가 작성하는 코드 스타일 서로 다르다면 어떤 비효율적인 일이 발생할까요?
모든 사람의 코드 스타일이 다르기에 가독성이 떨어지고, 버그 발생 가능성이 높아지며 커뮤니케이션 및 유지 보수가 어려워진다.