본문 바로가기
프로그래밍 놀이터/Tips

[실용주의 프로그래머] 중복의 해악

by 돼지왕 왕돼지 2018. 9. 29.
반응형

[실용주의 프로그래머] 중복의 해악


don't repeat yourself, dry 원칙, [실용주의 프로그래머] 중복의 해악, 강요된 중복, 개발자간의 중복, 나쁜 코드, 나쁜 코드와 주석, 높은 차원의 설명 주석, 단일, 단일하고, 믿을만한 표현 양식, 반복하지 마라, 부주의한 중복, 소통, 실용주의 프로그래머, 애매하지 않고, 어떻게 중복이 생기는가?, 언제 잊어버릴 것인가 하는 문제, 유지보수, 유지보수 모드, 재사용, 중복의 해악, 지식 중복, 참을성 없는 중복, 코드 리뷰


-

대부분의 사람들은 유지보수가 버그를 고치고 기능을 개선하는 것을 의미하기 때문에, 앱이 출시되었을 때 비로소 유지보수가 시작된다고 믿는다.

우리는 이들이 틀렸다고 생각한다.

프로그래머들은 늘 유지보수 모드에 있다.


유지보수는 별개의 활동이 아니며, 전체 개발 과정의 일상적인 부분이다.



-

소프트웨어를 신뢰성 높게 개발하고, 개발을 이해하고 유지보수하기 쉽게 만드는 유일한 길은 우리가 DRY 원칙이라 부르는 것을 따르는 것뿐이라 생각한다.

DRY 원칙이란 이것이다.


"모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다."


DRY 는 반복하지 마라, Don’t repeat yourself 의 약자이다.



-

똑같은 것이 두 군데 이상에 표현될 경우, 만약 하나를 바꾼다면 나머지 것들도 바꿔야 함을 기억해야 한다.

이것은 기억하느냐 마느냐의 문제가 아니다.

단지 언제 잊어버릴 것인가 하는 문제다.





어떻게 중복이 생기는가?


-

강요된(impose) 중복 : 환경이 중복을 강요.

부주의한 중복 : 자신들이 정보를 중복하고 있다는 것을 깨닫지 못한다.

참을성 없는 중복 : 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 중복을 하게 된다.

개발자간의 중복 : 한 팀에 있는 ( 혹은 다른 팀에 있는 ) 여러 사람들이 동일한 정보를 중복한다.




강요된 중복   


정보의 다양한 표현양식



코드 내의 문서화

        나쁜 코드야말로 많은 주석을 필요로 한다.

        DRY 원칙은 낮은 차원의 지식은 그것이 속하는 코드에 놔두고, 주석은 다른 높은 차원의 설명을 위해 아껴두라고 말한다.

        그러지 않으면 지식을 중복하게 되며, 변경할 때마다 매번 코드와 주석 모두를 바꾸어야 한다.

        주석은 필연적으로 낡게 될 것이고, 믿을 수 없는 주석은 주석이 전혀 없는 것보다 더 심각한 문제를 만들어 낸다.



문서화와 코드.

        문서 자체에서 테스트가 자동 생성되도록 한다면, 문서화와 코드를 동시에 수정하도록 강요할 수 있다.



언어에 관한 문제




부주의한 중복


-

성능상의 이유로 DRY 원칙을 위배할 수도 있을 것이다.

이것은 비용이 많이 드는 연산을 피하기 위해 데이터를 캐싱해야 하는 경우 종종 발생한다.

요령은 그 영향을 국소화 하는 것이다.

바깥 세상에 DRY 원칙의 위배가 노출되지 않고, 단지 클래스 내의 메서드들만이 좀 고생하면 된다.



-

가능한 곳에서는 언제나 객체의 속성을 읽고 쓸 수 있는 액세스 함수를 사용하라.

그러면 캐싱과 같은 기능을 나중에 추가하기가 더 쉬워질 것이다.




참을성 없는 중복


-

‘돌아가는 길이 지름길이다’ 라는 진부한 격언을 기억하라.

지금 당장 몇 초를 절약할 수 있을지라도, 나중에는 몇 시간을 잃게 될런지 모른다.




개발자간의 중복


-

발견하거나 다루기 가장 어려운 유형의 중복은 한 프로젝트에서 일하는 서로 다른 개발자 사이에서 발생한다.



-

깨끗한 설계와 강력하고 기술적인 프로젝트 리더, 그리고 그 설계 내에서 책임의 분배가 제대로 이해되도록 하는 것, 이런 것들로 개발자 간의 중복 문제를 다루어라.

그렇지만 모듈 차원이라면 그 문제를 알아채기란 더욱 어렵다.

분명한 책임 영역으로 나뉘어지지 않는 공통 필요 기능이나 데이터는 여러 번 거듭 구현될 가능성이 있다.



-

우리가 느끼기에 최선책을 개발자간에 적극적이고 빈번한 소통을 장려하는 것이다.

공통의 문제를 다루기 위한 토론장을 만들어라.



-

소스 트리의 한 가운데에 유틸리티 루틴과 스크립트들이 저장될 수 있는 장소를 마련하라.

그리고 의례히 비공식적으로 혹은 코드 리뷰시 다른 사람의 소스코드와 문서를 읽도록 하라.

다른  사람의 것들을 기웃거리는 게 아니고, 거기서 배우는 것이다.

다른 사람이 여러분의 코드를 들여다 본다고 해서 기분 나빠하지 말 일이다.



-

“"재사용하기 쉽게 만들라.”"



-

여러분이 조성해야 할 환경이란 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고, 또 재사용하기 쉬운 환경이다.

만약 그게 쉽지 않다면 사람들은 하지 않을 것이다.

그리고 만약 재사용에 실패한다면 지식 중복의 위험을 각오해야 한다.





반응형

댓글