프로그램 디자인

05 | 프로그램 디자인

유지보수할 수 없는 코드를 작성하는 기본 규칙은 가능한 한 여러 장소에 가능한 다양한 방법으로 사실을 기록하는 것이다.
_로에다 그린

유지보수가 쉬운 코드 작성의 핵심 요소는 응용프로그램의 각 요소를 한 곳에 정의하는 것이다. 바꾸어서 생각해보면 우리가 수정해야 할 코드가 한 곳에 모여있음을 의미한다. 이렇게 하면 수정하더라도 전체 프로그램 수행에 영향을 최소화할 수 있다. 즉, 유지보수가 어려운 코드를 만들려면 요소를 반복적으로 가능한 한 여러 장소에 기술해야 한다. 다행히도 자바와 같은 언어로 이처럼 유지보수가 어려운 코드를 비교적 쉽게 작성할 수 있다. 예를 들어, 폭넓게 사용하는 변수는 여러 가지 항변한 및 변환을 거치고 있으며, 관련 형식의 임시 변수가 사용되고 있을까 능선이 크므로 형식을 변환하기가 쉽지 않다. 더욱이 화면에 뭔가를 출력하는 변수 일 경우라면 출력과 데이터 입력 관련 코드를 수동으로 수정해야 한다. C와 자바를 포함한 Algol 계층 언어는 데이터를 배열, 해시테이블, 파일, 데이터베이스에 저장하는 문법이 완전 다르다. Abundance와 같은 언어나 Smalltalk 확장 언어에서는 데이터 저장 문법은 같고 선언만 다르다. 따라서 자바의 부족한 기능을 공략하자. 현재 RAM으로 감당할 수 없이 크기가 커질 데이터를 배열로 저장하자. 그러면 유지보수 프로그래머는 나중에 배열을 파일로 바꿔야만 하는 악몽 같은 작업을 피할 수 없을 것이다. 마찬가지로 데이터베이스에 작은 파일을 사용하자. 그러면 유지 보수 프로그래머는 성능 최적화 때 해당 파일을 배열 접속 방식으로 바꿔야 하는 즐거운 경험을 맛볼 것이다.

자바 항변한

자바의 항변한 스킴은 하느님의 귀중한 선물이다. 형 변환은 언어에서 필요한 기능이므로 이를 아무 거리낌 없이 남용할 수 있어야 한다. Collection에서 오브젝트를 가져왔으면 원래 형식으로 형 변환해야 한다. 어떤 때는 변수 형식 종류가 수십이 넘기도 한다. 나중에 데이터의 형식을 바꾸려면 모든 형 변환도 바꿔야 한다. 운이 없는 유지보수 프로그래머가 모든 형 변환을 적절하게 처리하지 못한 경우(혹은 너무 많은 변환을 한 경우) 컴파일러가 그 사실을 알려줄 수도 있지만, 그렇지 못한 경우도 있다. 마찬가지로 변수 형식이 short에서 int로 변경하면 관련 형 변환도 모두 (short)에서 (int)로 바꿔야 한다. 일반 캐스트 연산자인 (cast)와 일반 변환 연 산자 (convert)라는 새로운 연산자에 대한 필요성이 논의되고 있다. 이들 연산자는 변수 형식이 변경되어도 유지보수할 필요성이 없게 해주는 새로운 연산자가 될 전망이다. 이런 이단적인 연산자가 언어 스펙에 포함되게 보고만 있어야 하는가? RFE 114691에서 형 변환의 필요성을 제거하기 위한 genericity 부분에 적극적으로 투표하길 바란다.

자바의 중복성 남용하기

자바에서는 모든 형식을 두 번 지정해야 한다. 자바 프로그래머는 이러한 관습에 익숙하기 때문에 두 형식을 아래처럼 살짝 바꾸어 놓아도 눈치챌 수 있는 사람은 많지 않다.

Bubblegum b = new Bubblegom();

불행히도 ++ 연산자의 대중성 때문에 다음과 같은 의사 중복 코드를 성공시키기가 쉽지 않다.

swimmer = swimner + 1;

검증을 멀리하라

입력 데이터에 대한 어떤 종류의 불일치 검사나 정확성 검사를 수행하지 않는다. 즉, 우리는 회사 장비를 온전히 신뢰하고 있으며 모든 프로젝트 파트너와 시스템 운영자를 신뢰하는 완벽한 팀원임을 보여줄 수 있다. 입력 데이터가 이상하거나 문제가 있는 듯 보이더라도 항상 합리적인 값을 반환하기 위해 노력해야 한다.



예의를 지키고 무턱대고 주장(Assert)하는 일을 피하라

assert( ) 메커니즘은 3일짜리 버그 축제를 10분짜리로 만들어 버릴 수 있으므로 피해야 한다.

캡슐화를 멀리하라

효율성 측면을 고려할 때 캡슐화를 멀리해야 한다. 메소드 호출자는 메소드가 어떻게 동작하는지를 알 권리가 있다.

복사하고 수정하라

효율성이라는 명목으로 잘라내기/붙이기/복사하기/수정하기를 남발하자. 이 방식은 작은 재사용 가능한 모듈 여럿을 사용하는 것보다 실행 속도가 빠르다는 장점이 있다. 특히 이 방식은 우리가 작성하는 코드 라인 수를 업무 진행 척도로 여기는 곳에서 일할 때 유용하다.

정적 배열을 사용하라

라이브러리의 모듈에 이미지를 저장할 배열이 필요한 경우에는 정적 배열을 선언해야 한다. 아무도 512 x 512 크기 이상의 이미지를 사용하지 않을 것이므로 크기가 고정된 배열도 좋다. 정확성을 높일 수 있도록 double 배열을 사용하는 것도 봐 남짓하다. 이렇게 하면, 2메가 크기의 정적 배열을 효과적으로 숨길 수 있다. 클라이언트는 우리가 만든 루틴을 한 번도 수행하지 않았음에도 미친 것처럼 허우적대고 프로그램은 결국 클라이언트의 메모리를 초과할 것이다.

더미 인터페이스

“WrittenByMe”와 같은 빈 인터페이스를 만들고 모든 클래스에서 “WrittenByMe” 인터페이스를 구현하도록 하자. 그리고 우리가 사용하는 자바의 내장 클래스 래퍼 클래스를 만들자. 핵심은 우리 프로그램의 모든 오브젝트가 위 인터페이스를 구현하게 하는 것이다. 마지막으로 모든 메소드를 직접 구현하므로 매개변수와 반환 형식을 WrittenByMe가 구현하는 것이 목적이다. 이 기법을 사용하면 특정 메소드가 어떤 작업을 수행하는지 알아내기 어렵게 할 수 있고 아주 다양한 종류의 형편 환이라는 즐거움을 만끽할 수 있다. 이를 좀 더 활용해서 각 팀 멤버에게 자신만의 개인 인터페이스(예를 들어, Writ-tenByJoe)를 만들어줄 수 있다. 그리고 각자가 작업한 클래스는 자신만의 인터페이스를 구현하게 한다. 자 이제, 의미 없는 수많은 인터페이스 중에 아무 인터페이스를 골라잡아 오브젝트 참조에 사용할 수 있다.

거대 리스너

각 컴포넌트에 리스너를 개별적으로 만들지 않는다. 우리 프로젝트의 모든 버튼의 이벤트를 처리할 리스너를 단 한 개로 통일하고 수많은 if... else 문으로 각 버튼 동작을 처리하는 것이 바람직하다.

좋은 것은 남용하라

캡슐화와 oo를 남용하라

우호적인 친구

C++에서는 가능한 한 자주 friend-선언을 사용한다. 생성된 클래스의 클래스 생성 포인터 처리와 결합하는 것도 좋은 방법이다. 그럼 인터페이스를 생각하는 데 시간을 낭비할 필요성이 없어진다. 또한 private와 protected 키워드를 사용해 클래? 그를 캡슐화할 수 있다.