Yagur의 Juggling

작성자 : yagur rev : 1

  작고 단단한 객체를 작성하기 위해 프로그래머들은 고민을 많이 합니다. 이에 조금은 도움이 될만한 연습방법이 눈에 띄더군요. Thought Works Anthology란 수필 모음집에 객체 건강유지법(Object Calisthenics)이란 흥미로운 수필이 바로 그것이었습니다.

 아래 목록은 잘알려진 7가지 코드 품질에 관련된 항목들입니다.

 그리고 Jeff Bay는 위의 7가지 코드 품질의 향상을 위한 9가지 실천 항목을 소개하고 있습니다.

 1. 메소드당 한 단계 깊이 이상의 들여쓰기를 하지 않는다.
 2. else 키워드를 사용하지 않는다.
 3. 모든 원형primitive과 문자열을 래핑Wrapping한다.
 4. 한 라인당 하나의 점(.)을 사용한다.
 5. 약어를 쓰지 않는다.
 6. 엔티티를 작게 유지 한다.
 7. 두개 이상의 인스턴스 변수를 가진 객체는 사용하지 않는다.
 8. 일급 객체 모음을 사용한다.
 9. Getters/Setters/properties를 사용하지 않는다.

 제 해석이 틀릴수도 있으니, 원문을 참조 하시고 싶은분은 아래 more를 누르세요.

more..

  일단 이 9가지 실천항목은 Jeff가 제안하는 객체 건강유지법입니다. 규칙과 달리 꼭 지켜야할 강제성이 없는 원칙과 비슷하지만, 그 강제성이 좀더 약한 수준이라고 보고있습니다. 그는 간단한 1000 라인 크기의 프로젝트를 만들어 연습을 시작하되, 위의 실천항목 9가지를 매우 엄격하게 적용하는것을 조건으로 내걸고 있습니다. 그리고 이 건강유지법을 가이드라인 정도로 활용하라고 그는 말하고있습니다. 다시 한번 본다면 몇가지 실천항목은 그다지 새롭지 않은것들도 있습니다.

1. 메소드당 한 단계 깊이 이상의 들여쓰기를 하지 않는다.

 메소드 크기가 클경우 보통 응집도가 떨어지는 경우가 많습니다. 분리해야할 시점에서 분리하지 않고, 관련없는것이 계속 더해져 비대해지는 경우입니다. 이를 피하는 좋은 방법은 작게 작성하는 것입니다. 작게 작성하려다 보면 해당 문제 영역안에서 해결하려는 경향이 생겨납니다. Jeff는 작게 작성하는 버릇을 들이기 위해 한 메소드를 5줄 이내로 작성하라고 권합니다. 물론 이는 그의 건강유지법에 해당하며, 실무에서 모든 메소드를 5줄 이내로 작성하는것은 불가능에 가깝다고 생각합니다. 하지만 좋은 연습이 될것입니다.

작성자: yagur  Rev : 1

빌드 자동화와 배치 빌드

  프로젝트의 모듈이 늘어감에 따라 의존성의 복잡도가 단순하지만은 않음을 느끼는 프로그래머가 많을 것이다. 모듈의 직교성(Orthogonality)을 살렸다 해도 모듈이기 때문에 그것을 링크하는것에 의존성이 생기는 것은 당연하다. 십여개 혹은 수십여개의 모듈간의 의존성때문에 빌드는 수작업으로 하기엔 프로그래머의 시간을 빼앗는 작업이 되어버렸다.

 팀작업시 협업 문제

  팀작업시에 작업자의 컴에서는 되는데 다른 동료의 컴퓨터에서 프로그램이 뻗어버리는 일이 발생하는 경우가 종종 볼수 있었다. 심지어 소스코드 저장소를 사용하지않을때는 컴파일 자체가 되지 않는 경우도 많이 보았다. 일일 빌드(Daily Build)혹은 주기적인 빌드를 시행하지 않는 곳에서는 모듈간의 문제점 해결에 수일에서 수주가 걸리기도 하며 업데이트 된내용이 반영이 안되거나, 반영되었다가 다시 옛것과 머지하다 업데이트 반영 내용이 사라져 버리는 경우도 흔한일이다. 동일한 저장소와 빌드 시스템이 있었다면 문제 해결에 가까워 질수 있을 것이다.

 주기적인 빌드
 
  모듈 자체를 써드파티의 것과 같이 바이너리로 개발자에게 동적라이브러리로 배포해버리는것도 좋은 방법이다. 하지만 프로그래머는 수많은 소스코드를 주고 받을수 밖에 없는데, 그것에 개발 협업 시스템(CDE)은 큰 도움이 되기도 한다. CDE에서 해당 모듈의 배포를 RSS를 통해 알수도 있어 편리하다. 무엇이 안정적이고 무엇이 실험적인 모듈인지 개발자가 알수 있다면 더 안정적인 개발을 진행할수 있다.
 소스코드 저장소와 자동화된 배치 빌드가 있다면 자주 여러사람의 작업물을 합치고 빌드해볼수 있을 것이다. 이는 잦은 테스트로 이어지기 때문에 많은 문제를 줄여줄수 있다. 빌드가 안되서 해당 개발자의 자리로 불려 다니던 최악의 경우의 횟수가 확연히 줄어들것이다.
 일일 빌드에 관한 조엘의 블로그에 유용한 포스트가 있으며, 스티브 맥코넬의 코드 컴플리트와 실용주의 프로그래머에도 좋은 관련 내용을 담고 있다.

"생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다." - 알프레드 노스 화이트헤드

 빌드의 방법

  주기적인 빌드를 하는 것으로 문제점을 줄이고 시간효율을 높히려 했으나 수많은 의존성을 가진 모듈들을 순서대로 손으로 컴파일을 진행해주어야 하는것은 귀찮은 일이고 실수할수도 있는 일이다. 그렇다면 배치 빌드(Batch Build)의 필요성을 느끼기 시작하거나 이미 하고 있는 개발자들도 많을 것이다.
 makefile이나 특정 스크립트를 이용한 자동화된 빌드 시스템이 아니라, 특정 IDE(주로 Visual Studio)에 익숙해져 있다면 배치 빌드는 매우 유용한 도구가 될것이다.
  또한 배치 빌드를 작성할때 유러가지 유형을 두면 좋다. 3가지 모듈이 A 모듈에 의존하고 있다고 가정했을때, A모듈을 변경하면 나머지 3가지 모듈역시 재컴파일 되야 하는가? A 모듈의 인터페이스가 변하지 않았다면 의존하고 있는 모듈들의 재링크는 필요하지 않다. 인터페이스가 변한상태와 변하지 않은 상태의 배치 빌드는 따로 작성해야한다.
 이렇게 작성된 배치 빌드들은 작업시에 수시로 사용될수도 있으며, 빌드 자동화를 위해 스퀘줄링 프로그램에 의해 호출될수도 있다. 프로그래머에게 매우 유용한 하고 편리하며, 시간을 절약해주는 보배인것이다.

 배치 빌드의 도구

  이 배치 빌드를 Window에선 batch파일을 작성해서 사용할수도 있지만 스크립트의 선택 역시 고민되는 부분이다. 외부 프로그램을 실행해야 하고 손쉬운 조건비교와 문자열 조합기능, 또한 플랫폼을 옮길 경우 사용할수 있는지 여부등을 고려해보면 좋은 배치 스크립트 언어를 선택할수 있다. 할 발자국 나아가서 생각한다면, 빌드후 빌드 결과를 웹에 올리는것까지 고려할수 있다. python, perl, tcl 여러가지 고차원 스크립트 언어를 활용할수있다.

기타:

  Visual Studio IDE 상의 프로젝트 종속성 설정은? - 동적 라이브러리의 경우

  프로젝트 종속성, 말그대로 족속성이기 때문에 모듈의 인터페이스가 변하던 변하지 않던 해당 모듈에 종속성을 가지고 있는 것들을 모두 일괄 빌드해 버린다. 이런 경우가 쓰이긴하겠지만, 모듈의 외부 인터페이스가 변하지 않는 경우 그것에 의존성을 가지고 있는 다른 모듈들을 다시 빌드할 필요는 없다. 모듈의 갯수가 많고 불필요한 빌드를 줄이기 위해서는 사용하지 말아야할 기능중 하나이다. 물론 꼭 전부 다시 빌드해야할경우엔 사용해야 하겠지만 말이다. 아마 이기능은 정적 라이브러리를 위한 기능인듯 하다.

작성자: yagur  Rev : 1

 주석의 쓰임세 그리고 "중복의 해악"

"중복의 해악"은 어떤 언어를 사용하던 자주 보이고, 고민해야만 하는 문제이다. 오래 진행되온 프로젝트 일수록 주석에서 중복의 해악을 잘 찾아볼수 있다. 물론 코드에서 보이는 경우는 당연히 있다.

 중복의 해악

 실용주의 프로그래머의 "중복의 해악"의 교훈은 말그대로 같은 정보를 여러번 표현하지 말라는 것이다. 그것이 잊지 말아야할 DRY(Don't Repeat yourself) 원칙이다.
 
 주석

  주석이 대표적인 예가 될수 있다. 코드가 일련의 프로세스를 설명하고 있는데 그것을 설명하는 주석을 위에 단다는 것은 코드 자체에 가독성이 떨어지는 것일수도 있으니 다시 한번 코드를 되돌아 보는것이 좋다. 또한 마틴 파울러의 리팩토링에선 이런팁을 남기고있다. "주석을 써야 할 것 같은 생각이 들면, 먼저 코드를 리팩토링 하여 주석이 불필요하도록 하라."
 나 역시 분량이 꾀 많은 라이브러리에 주석을 거의 달지 않았다. 함수, 변수명 그리고 흐름을 보면 그것이 주석을 대신할수 있기 때문이다. 그만큼 명명은 중요하다.
 하지만 가독성이 높으니 주석을 달지 말아야 하는것은 아니다. 주석이 프로세스를 설명하는 것은 DRY 원칙을 위반 하는것이다, 하지만 그 외에도 주석을 활용할수 있는 방법은 많다.

 주석과 코드에 무슨 중복이 있는가?

  프로그램 코드가 변하면 프로그램의 행위가 바뀌기 때문에 주석도 똑같이 다시 그것을 설명하는 것으로 바꿔줘야 한다. 여기서 중복 의 해악을 볼수 있다. 거기다 문서가 있다면 어떠한가? 문서 역시 바꿔줘야 한다. 문서의 경우는 강요된 중복이다.

  DRY 원칙을 위반하지 않는 주석의 활용법

 공학적인 트레이드오프, 어떤 결정의 이유, 어떤 대안을 버렸는가? 등의 이유가 주석으로 남는것은 공식문서에 남지 않는 중요사항을 문서화할수 있는 주석의 좋은 활용법이다.

 주석 작성시 고려할점과 주의점

 주석과 문서는 작성자 이외의 사람이 코드를 볼때 유용하다. 하지만 낡은 정보일 가능성도 있다.

 * 우리가 이들을 작성하고 코드를 변경하는가?
 * 아니면 코드를 변경하고 이들을 갱신하는가?
 * 급박한 상황에서 코드를 변경하고 문서 갱신을 그냥 넘기지는 않는가?

 이것을 고려하지 않고 넘어가면 어쩔수 없었던 중복이 낡은 정보로 남아버리게 된다.
 하지만 강요된 중복인 문서와 같은것들이 없다면 사용자(최종 상품 사용자가 아닌, 모듈이나 코드의 사용자)에게 불편함을 주거나, 외면 당할수도 있다.

작성자: yagur  Rev : 1

 실용주의 프로그래머의 "품질을 요구사항으로 만들어라"의 팁과 게임의 피드백 시스템에 관한 것입니다.

- 실용주의 프로그래머
 "우리는 종종 뭔가 나이지게 하려다가 괜찮은 것마저 망친다. -리어왕 1.4" 의 구절은 "품질을 요구사항으로 만들어라."의 팁을 아주 잘 설명해주고 있다. 사용자와의 적극적인 피드백을 통해 낳아진 소프트웨어는 애초에 완벽(?)을 구현한 소프트웨어보다 사용자의 요구사항을 더 충족시킬 확률이 크다.

 게임의 서비스 단계와 사용자의 요구사항

 많은 게임들이 테스트를 거치고 정식오픈을 한다. 적당히 괜찮은 소프트웨어를 충족시키기 위해서인지 혹은 빠른 상용화가 목적인지는 몰라도 일단 테스트를 거치면서 사용자와 피드백을 활용해 정식 서비스까지 다다르는것이 요즘 대부분의 온라인 게임 상용화 단계이다. 하지만 대부분 정해진 틀에 문제점에 관한 피드백 시스템만을 갖추고 있고 사용자의 요구사항이 게임에 적극 반영이 되는 경우는 드문것 같다. 물론 게임의 목적이나 장르의 기획에 따라 변동 될수 잇는 범위가 좁은 것들도 있지만 사용자의 요구사항을 적극 활용하는 게임이 몇개나 될까?

 스크립트는 일종에 사용자의 요구사항이 될수 있는 피드백시스템.

 사용자에게 아예 맞겨 놓은 부분도 있다. 예를 들자면 사용자에게 게임 인터페이스를 LUA 스크립트를 활용해 오픈한 WOW를 들수 있다. 사용자들은 Blizzard가 제공하지 않아도 그들의 요구사항을 충족시킬수 있는 강력한 툴을 손에 쥐고 제작할수 있게 된것이다. 하지만 제약이 있고 제작자와 사용자간의 적극적인 피드백이 이루어졌다고 보기는 힘들다. 사용자는 자신들의 커뮤니티에서 기능을 직접 제작해 써야한다. 또 알지 못하면 못쓰는 기능이 된다. 어떤 배포방식을 지닐것인가? 여러가지 문제점들이 있다. 하지만 이것에서 스크립트의 기능(?)이 게임에 가져다 주는 사용자와 제작자간의 미래형(?) 피드백 시스템이라고도 할수 있다.

 이 피드백 시스템의 장단점.

 하지만 이 미래형 피드백 시스템은 사용자에게 많은 노력을 요구한다. 피드백이라기 보다는 기능을 오픈하여 사용자의 입맛에 맞게 기능을 고치고 공유할수 있게 한것이 된다. 또 사용자의 또 다른 요구사항(예를 들자면 사용자 정의 기능 추가를 위한 스크립트의 기능 추가)이 발생하게 되고, 피드백 시스템은 여러가지로 복잡하게 나뉘어 지게 될것이다. 사용자의 노력이 많이 들어간다는 점에서 좋은 방식은 아니지만 소프트웨어의 확장성에는 긍정적 영향을 미치는것은 확실하다. 견고함을 위해선 사용자의 요구사항을 받아 제작사에서 제작해주는것이 좋을테고, 사용자의 결과물(스크립트)을 일종의 사용자 요구사항으로 보고 기능추가를 위해 그것들을 적극 활용하면 될것이다. 이 어렵고, 제한적인 피드백시스템은 "사용자의 품질 요구사항"을 가장 적극적으로 표현하게 될것이다. 왜냐하면 일부 사용자 그룹은 자신들의 필요기능이 존재 하지 않을때 일단 스크립트로 제작해 자신들의 갈증을 해소하기 때문이다.

 가장 쉬운 피드백 시스템

 가장 좋은것은 어려운 피드백 시스템인 스크립트 제공보다, 몇 마디의 글을 반영하는 피드백 시스템이다. 이것이 '적당히 괜찮은 소프트웨어'를 빨리 '사용자의 만족도가 높은 소프트웨어'로 만드는 실용성이 될것이다. 하지만 요구사항을 표현하기가 쉽고 사용자가 굉장히 많아 요구사항이 굉장히 많아진다. 구현되지 않고 볼수 없는 요구사항들이기 때문에 이 요구사항들의 옥석을 가리기란 매우 힘이 들것이다. 이런면에서는 어려운 피드백 시스템의 단점이 장점이 되기도 한다.
  또 여전히 여러종류의 사용자가 존재하기 떄문에 어려운 피드백 시스템인 스크립트를 열어두는것은 "품질을 요구사항으로" 만드는것에 큰 도움이 되는것만은 분명한것 같다.