ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [프로그래머] DRY원칙
    97가지 시리즈/프로그래머 2018.10.31 19:28

    #프로그래머가_알아야_할_97가지 vol.29

    DRY원칙 by. Steve Smith


    DRY(Don’t Repeat Your Self: 반복을 피할 것) 원칙은 프로그래밍할 때 지켜야 할 원칙 중에서도 가장 중요한 원칙이라 생각합니다. 이 원칙은 Andy Hunt와 Dave Thomas가 저서 'The Pragmatic Programmer'에서 설명한 원칙으로, 잘 알려진 소프트웨어 개발의 모범 사례나 디자인 패턴도 이 원칙과 사상이 비슷한 것이 많습니다. 개발자는 애플리케이션 안에 중복이 있거나, 중복이 일어날 것 같으면 그것을 감지하고 적절한 모범 사례를 이용하거나 추상화를 통해 그 중복을 배제해야 합니다. 중복을 배제하는 방법을 배움으로써 더욱 깨끗한 코드를 쓸 수 있게 될 것입니다.


    중복은 낭비다

    애플리케이션을 구성하는 코드는 모두 유지보수가 필요합니다. 모든 코드는 언젠가 버그를 일으킬 위험성을 내포하고 있기 때문입니다. 중복이 있으면 코드가 불필요하게 많아지고, 그에 따라 버그가 생길 위험성도 높아집니다. 또한, 시스템의 구조가 의도치 않게 복잡해져 버립니다. 중복으로 인하여 코드가 많아지면 개발자가 시스템 전체를 완전하게 이해하기도 어려워집니다. 가장 곤란할 때가 코드를 변경할 때입니다. 변경할 때엔 중복된 로직이 있는지 확인하고 그곳에도 같은 변경이 필요한지 일일이 확인해야 합니다. 만약 DRY 원칙을 지켰다면 이런 문제에 빠지지 않게 됩니다. DRY 원칙을 지킨다는 것의 의미를 바꾸어 말하면 '모든 지식은 시스템 내에서 유일하고 명확한, 그리고 신뢰할 수 표현이어야 한다'라는 조건을 만족한다는 뜻입니다.


    작업의 중복은 자동화로 막는다

    소프트웨어 개발과 관련된 작업 대부분은 같은 일의 반복입니다. 즉 작업이 여러 번 중복됩니다. 이 중복은 자동화로 쉽게 해결할 수 있습니다. DRY 원칙은 애플리케이션의 소스코드뿐만 아니라 개발 작업에도 적용해야 하는 원칙이고 이를 위해서는 자동화가 도움이 된다는 뜻입니다. 테스트 작업과 소프트웨어의 결합(빌드) 작업을 예로 들 수 있습니다. 이 작업들은 수작업으로 일일이 하고 있으면 수고는 수고대로 들고 시간도 오래 걸리고 실수가 일어나기도 합니다. 그러므로 가능한 한 프로세스를 자동화하고, 자주 실행되도록 해야 합니다. 커밋을 할 때마다 실행되게 하는 게 이상적입니다. 수작업으로 하기에 부담이 큰 작업은 모두 자동화의 대상이 됩니다. 자동화하고 표준화하는 것이 바람직합니다. 중요한 것은 작업을 수행하는 방법을 하나로 통일 한다는 것입니다. 그러면 수고를 덜 수 있고 문제 발생도 줄일 수 있습니다.


    로직의 중복은 추상화로 방지한다

    로직의 중복에는 많은 종류가 있습니다. 예를 들어 if-then 문이나 switch 문이 단순하게 복사&붙여넣기 되어 있는 패턴은 발견하기도 해결하기도 쉽습니다. 디자인 패턴의 상당수는 애플리케이션 안의 중복을 줄이거나 배제하는 것을 목적으로 하고 있습니다. 어떤 객체를 사용하기 위해 갖춰야 할 조건이 같다면, Abstract Factory 패턴이나 Factory Method 패턴을 사용하면 좋습니다. 객체의 동작이 여러 종류로 정의되어 있을 때는 긴 if-then 문을 쓰기보다는 Strategy 패턴을 사용합니다. 실제로 디자인 패턴은 같은 문제에 대해서 여러 번 반복해 해결책을 모색하는 일이 일어나지 않도록 만들어졌다고 할 수 있습니다. DRY 원칙은 데이터베이스 스키마 구조에도 적용할 수 있습니다. 흔히 말하는 "정규화"입니다.


    관련된 원칙

    소프트웨어 개발에 관한 원칙에는 이 외에도 DRY 원칙과 관련된 것이 몇 가지 있습니다. OAOO(Once and Only Once: 한 번, 단 한 번) 원칙이 그중 하나입니다. 이 원칙은 코드의 기능, 행동에만 적용되는 원칙으로 DRY 원칙을 적용한 것이라 할 수 있습니다. OCP(Open/Closed Principle:개방/폐쇄 원칙)라는 원칙도 있습니다. 이 원칙은 클래스와 같은 프로그램의 단위는 확장을 위해서 "열려(open)"있어야 하고, 수정에 대해서는 "닫혀(close)" 있어야 한다는 원칙입니다. 그리고 이 원칙은 DRY 원칙이 지켜지고 있는 경우에만 유효합니다. 그 밖에 SRP(Single Responsibility Principle: 단일책임원칙)라는 유명한 원칙도 있습니다. "클래스를 변경할 때 2가지 이상의 이유가 있어선 안된다(한 가지 변경의 이유는 항상 한가지 여야 한다)"라는 원칙으로, 이 원칙 역시 DRY 원칙이 지켜질 때만 유효합니다


    DRY원칙은 구조, 로직, 프로세스, 기능 등 모든 면에서, 개발자가 심플하게 애플리케이션을 만들기 위한 기본적인 지침입니다. 이 원칙을 지킴으로써 단순하고 품질이 높고 유지보수 하기도 쉬운 애플리케이션 구현이 가능해집니다. 때에 따라서는 퍼포먼스를 높이기 위해, 혹은 어떤 요건(데이터베이스를 비정규화해야 하는 등)을 충족시키기 위해 중복이 필요한 일이 있을 수도 있습니다. 하지만 눈앞에 처한 문제를 해결하기 위한 목적으로, DRY 원칙을 어겨서는 안 됩니다. '이런 문제가 생길 것 같으니 이 부분은 원칙을 무시하자'라는 행동을 해서는 안 된다는 것입니다.



    저자: Steve Smith

    소프트웨어 개발자나 멘터로서의 일을 하는 한편, 집필과 강연 활동도 하고 있다.

    프로로서 소프트웨어 개발의 세계에서 일하기 시작한 것은 1997년.

    그 이후, 주로 ASP.NET 분야의 글을 쓰고 있다.

    유저 그룹이나 DevConnections, Microsoft TechEd와 같은 컨퍼런스에서 강연도 많이 했다.

    미국 육군기술대위로 이라크전쟁에 종군하고 불발탄 등 폭발물 제거를 하는 소대를 이끌었다.

    오하이오 주에서 아내와 두 자녀와 함께 살고 있다.

    오하이오주 허드슨의 Hudson Software Craftsmanship의 코디네이터 중 한 명이기도 하다.


    [프로그래머] DRY원칙


    [출처] プログラマが知るべき97のこと (O'Reilly Japan)

    이 글은 [CC-by-3.0-US]에 의해 라이센스 되었습니다.




    댓글 0

Designed by Tistory.