1장. 개요
"고품질의 코드란 무엇인가" 와 같은 코드 품질과 관련된 문제를 정의한다.
해당 챕터에서 배울 내용
코드 품질에 대한 정의와 그 품질을 어떻게 평가할 것인지 이론적인 부분을 학습한다.
코드 설계를 배우는 이유
복잡한 코드 개발
소프트웨어 개발할 때 만나는 어려움이 두 가지가 있다.
첫 번째는 매우 높은 수준의 기술이 필요한 경우이다.
두 번째는 높은 수준의 기술이나 최신 기술이 필요하지는 않지만 복잡한 비즈니스를 갖춘 대규모 프로젝트로, 물류 시스템, 금융 시스템, 대규모 ERP 시스템 등 많은 사람이 참여하는 프로젝트이다.
복잡한 코드와 설계가 필요하게 되면 어디서부터 무엇을 시작해야 할지 모르는 막막한 상태가 되었고 무력감까지 느끼게된다.
이렇듯 단순히 기능을 구현하고 사용 가능한 코드를 만드는 것은 복잡하지 않을 수 있지만, 사용하기 쉬운 코드를 작성하는 것은 쉽지 않다.
프로그래머의 기본 능력
프레임워크와 미들웨어를 배울 때 시간을 들여 관련 원리를 공부하고 소스 코드를 읽으면서, 단순하게 그것들의 기능을 사용하는 데 그치지 않고 심층적인 이해를 얻으려고 한다.
소스 코드를 읽으면서 종종 그것이 어떤 의미인지 이해하지 못하는 경우의 문제가 있는데, 이 문제는 코드를 완벽하게 이해하기 위해 필요한 기본적인 기술적 소양과 능력이 부족하기 때문이다.
우수한 오픈소스 프로젝트, 프레임워크, 미들웨어는 코드와 클래스의 양이 많으며 클래스 구조와 호출 관계가 복잡하다. 이렇게 복잡한 코드의 유지 보수성을 보장하기 위해 더 많은 디자인 패턴과 설계 원칙이 코드에 사용된다.
그러므로, 프로그래머는 디자인 패턴과 설계 원칙에 대해 확실히 이해 하면 코드가 설계된 이유를 한 눈에 파악할 수 있고, 코드를 쉽게 읽을 수 있다.
코드 품질 평가 방법
우리는 단순히 코드의 가독성이 높다 나쁘다를 칼 같이 구분할 수 없는데, 만약 코드의 가독성을 평가해야 한다면 높다 또는 낮다가 아닌 점수를 매기는 것 처럼 연속적인 값 중 하나여야 할 것이다.
이 처럼 주관적인 평가의 정확성이 바로 코드 품질 평가의 주관적 요소 때문이다.
즉, 소프트웨어 엔지니어의 경험이 많을수록 평가가 더 정확해지는 경향이 있으며, 반대로 경험이 부족한 경우 정량화할 수 있는 평가 기준이 없기 때문에 판단이 어렵다고 느끼는 경우가 많다.
결론적으로 코드를 잘 작성 했는지 여부를 판단할 수 없다면 아무리 많은 코드를 작성 하더라도 코딩 능력은 크게 향상되지 않는다.
이 책에서 다양한 평가 기준에서 일반적으로 사용되는 7가지 중요한 평가 기준을 지표로 삼는것을 목표로 한다.
가독성
유지 보수성
확장성
유연성
간결성
재사용성
테스트 용이성
위 중요한 평가 기준 중 집중적으로 살펴보면 좋을만한 요소들을 위주로 설명한다.
가독성
마틴 파울러는 "컴퓨터가 이해할 수 있는 코드는 바보라도 작성할 수 있다, 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 작성한다." 라고 말한 바 있듯이, 코드를 읽는 횟수는 코드를 작성하고 실행하는 횟수보다 훨씬 더 많다.
> 가독성은 어떻게 판단할까?
변수 이름이 의미가 있는지
주석이 자세히 기술 되어 있는지
함수의 길이는 적절한지
모듈 구분이 명확한지
코드가 높은 응집도와 낮은 결합도를 갖는지
유지보수성
코드 개발에서 버그의 수정, 이전 코드의 수정 또는 새로운 코드의 추가가 굉장히 빈번하게 일어난다.
여기서, "유지 보수성이 높다" 라는 표현은 기존 코드를 수정하지 않고 새로운 요구사항을 처리할 수 있어야한다.
하지만, 유지 보수성은 수치화하기 어렵고 전체 코드를 평가하는 경향이 있기 때문에 많은 요인들을 공통적으로 살펴봐야한다.
> 유지보수가 상대적으로 쉬우려면 어떻게 해야할까?
코드가 명확하게 계층화 되어 있는지
구현보다 인터페이스 기반의 설계 원칙을 고수하고 있는지
코드의 유지 보수성은 프로젝트의 코드 규모, 비즈니스의 복잡성, 기술의 복잡성, 문서의 포괄성, 팀원의 개발 수준 등 다양한 요인이 내포되어 있다.
유연성
"코드는 유연하게 작성 되어있다" 에서 유연하게는 어떤 의미일까?
유연하다는 것은 굉장히 추상적인 의미이기 때문에 한마디로 정의하는 것은 쉽지 않지만 유연성에 대해 생각해 볼 수는 있다.
> 어떤 상황에서 코드가 유연하다고 할까?
기존 코드에 확장을 위한 인터페이스가 준비되어 있어서 기존 코드의 수정 없이 새로은 코드를 추가 가능한 구조인지
재사용 가능한 함수나 클래스 구조를 통해 상속 받거나 모듈 처럼 언제든 사용할 수 있는 추상화된 형태인지
클래스를 사용할 때 클래스가 다양한 사용 시나리오에 대응하고, 다양한 요구를 충족할 수 있는지
간결성
KISS 원칙을 들어 보았는가, 이 원칙은 코드를 가능한 한 단순하게 유지하려는 간결성을 의미한다.
코드를 작성할 때 우리는 "단순하고 명확한" 원칙을 먼저 생각하는 경향이 있다.
프로그래밍에 익숙하지 않은 프로그래머는 단순한 코드에는 기술적이지 않다는 느낌을 받아 복잡한 디자인 패턴을 적용하려고 하지만, 의외로 간단한 방법으로 복잡한 문제를 해결하는 경우가 많다.
과도한 설계를 피하는 방법
코드 설계의 원칙은 앞에 문제가 있고, 뒤에 방안이 있다는 것이다
코드를 하나의 제품으로 생각한다면, 제품의 페인 포인트가 어디인지, 사용자의 니즈가 무엇인지 먼저 생각하고 요구사항에 맞는 기능을 개발 해야지, 화려한 기능을 먼저 개발한 후 요구 사항을 끼워 맞추는 방식은 절대 해선 안된다.
실제로 개발 경험이 많지 않은 초보자들은 문제를 구체적으로 분석할 줄 모르며, 손에 망치를 들고 어떤 것이 못인지 확인한다.
어느것이 올바른 것인지 알지 못한 채 각종 디자인 패턴을 적용해보는 것이다. 코드를 작성하고 나면 자신이 작성한 매우 복잡한 코드를 보고 자기 만족에 빠지게 되는데, 이 방식을 가장 피해야 한다.
지속적인 리팩터링은 과도한 설계를 효과적으로 방지할 수 있다
디자인 패턴을 적용하면 코드 확장성을 향상시킬 수 있지만 동시에 코드 가독성이 나빠질 수 있다는 것을 해당 챕터를 보내면서 이미 알고 있다.
따라서 "잘못된 요구 사항 예측"으로 인한 과도한 설계를 피하기 위해 지속적인 리팩터링 개발 방법을 권장한다.
실현 가능성이 낮은 미래의 요구 사항을 위해 처음부터 디자인 패턴을 적용하기보다, 진짜 문제가 발생 했을 때 이를 해결하기 위한 디자인 패턴을 사용하는 것을 고려하는 것이다.
-> 망치를 들고 어떤 것이 못인지 찾는 것 보다, 못이 발견된 후 망치를 찾는게 지속적인 리팩터링 개발을 위한 방법이다.
특정 시나리오 외의 코드 설계에 대해 이야기 하지 않는다
코드 설계는 소프트웨어 엔지니어의 경험에 맡기는 굉장히 주관적인 내용이다. 마치, "예술" 이라고 표현 해도 과언이 아닐 정도이다.
특정 시나리오 없이 코드 설계가 합리적인지 아닌지를 이야기 한다면 비즈니스에서 아키텍처에 대해 이야기 하는 것 처럼 비현실적인 내용이다.
-> 특정 시나리오란 문제를 해결 하기 위해 발생 된 페인 포인트를 일컫는다.
더 나은 코드 설계를 위한 필요 사항들
코드 설계를 배울 때 우리는 문제 분석 능력과 문제해결 능력의 훈련에 주의를 기울여야한다.
코드의 장단점을 분석하고 그 이유를 설명할 수 있어야 하며, 코드를 개선하는 방법도 알고 있어야한다.
결국 해당 책으로 얻은 디자인 패턴의 원리와 코드 구현은 한낱 이론 지식일 뿐 문제를 자세히 분석하는 능력이 없다면 디자인 패턴을 남용하고 과도한 설계를 하기 쉬운 잘못된 길로 빠질 수 있다.
우리는 앞으로 못을 발견하고 그 못을 어떻게 제거할지 고민하고 그 방법 속에서 망치 같은 도구를 찾는것이다.
Last updated