Whiteship's Note

'모하니?/Koreanization'에 해당되는 글 32건

  1. 2010.06.17 [하이버네이트 완벽 가이드] 드뎌.. 하이버 번역서가 나왔습니다. (16)
  2. 2009.12.08 [봄싹] 하이버네이트와 자바 퍼시스턴스 베타리딩 합니다. (8)
  3. 2009.09.18 [봄싹] 스프링 레퍼런스 3.0 번역 시작 (4)
  4. 2009.05.05 프로 스프링 2.5 번역서가 나왔습니다. (20)
  5. 2009.03.19 프로 스프링 2.5 6장 저자와 번역 합의 메일 (9)
  6. 2009.01.08 재벌의 묘미(?) (4)
  7. 2008.12.23 번역 품질을 높이는 방법? (4)
  8. 2008.11.06 one A for every B 번역하기
  9. 2008.09.03 번역 할것들이 넘쳤다. 열심히 하자!
  10. 2008.07.01 Ivy로 메이븐 저장소를 사용하기
  11. 2008.06.11 6, 7, 8월에 번역할 기사 (2)
  12. 2007.12.21 롤러스케이트 구현
  13. 2007.12.07 테스트 암 Test Cancer
  14. 2007.10.10 JAX-WS 2.0 웹 서비스 설계와 개발 (2)
  15. 2007.10.04 선언된 순서를 변경하는 것은 리팩터링인가?
  16. 2007.10.04 리팩터링 정의
  17. 2007.10.03 발견하지 못한 버그를 수정하는 것은 리팩터링인가?
  18. 2007.10.02 성능 최적화가 리팩터링인가?
  19. 2007.08.20 아마존 웹 서비스로 애플리케이션 개발을 가속시키자.
  20. 2007.07.31 'RFC 2119'가 뭐지??
  21. 2007.07.12 Building Google gadgets, Part 2
  22. 2007.06.29 Building Google gadgets, Part 1
  23. 2007.06.14 Agile Database Refactoring with Hibernate 번역 (2)
  24. 2007.06.13 Four Days on Rails 번역 완료 (8)
  25. 2007.05.28 Eclipse 용 GUI 빌더 Jigloo 사용하기 (7)
  26. 2007.05.09 Introduction to Apache Maven 2
  27. 2007.05.04 Eclipse 3.2를 활용한 리팩토링
  28. 2007.04.22 Fail-fast vs. complete validation
  29. 2006.11.16 Self Testing Code design
  30. 2006.11.14 TestDrivenDevelopment design

[하이버네이트 완벽 가이드] 드뎌.. 하이버 번역서가 나왔습니다.



Java Persistence With HIbernate 번역서가 나왔습니다.
어흑.. 몇년째 번역한건지.. 원래 이 책을 프로 스프링 2.5보다 먼저 번역 하고 있었거든요.
사실 그보다 훨씬 더 전에는 물개선생님께서 번역하고 계셨었는데... ㅋ
하이버에 관심있으신 분들을 한권쯤...ㅋ



top


[봄싹] 하이버네이트와 자바 퍼시스턴스 베타리딩 합니다.



Java Persistence With Hibernate 번역서 입니다. 이 책이 드디어 한국어로 나올 날이 가까워 오는군요. 물개선생님한테서 이 작업을 인수 받고 상당히 버거웠었는데, 다행히도 번역계의 마이다스이신 대엽님께서 번역 팀장을 맡고 계십니다.

베타리딩 방법은 이전의 프로 스프링 2.5 베타리딩 방식과 동일합니다. 프리스타일 이지만 어느 정도 중심적인 관점(Aspect or Concern)을 가지고 봐주셨으면 합니다.

"문법 위주로 보고 싶으신 분은 문법 위주로.." 예) 맞춤법, 올바른 한글 표현인지 아닌지..
"코드 위주로 보고 싶으신 분들은 코드 위주로.." 예) 코드를 다운 받을 수 있는지, 실행하는 방법은 어떤지, 코드가 틀리진 않았는지..
"내용 위주로 보고 싶으신 분들은 내용 위주를.." 예) n+1 select 문제에 대한 설명이 올바른지..

1. 때가 되면 제가 워드 문서를 그룹스로 보내드릴겁니다. 예) [하이버네이트 베타리딩] n장
2. 그럼 워드의 메모 기능을 이용하여 검토해주세요.
3. 파일 이름은 "1장_베타리딩_누가_언제.doc" 규약을 따라주세요.
4. 해당 파일을 gmail에서 그룹스에 답멜로 첨부해 주시거나, 저에게(이 블로그 맨 밑에 주소가 있어요) 이메일로 보내주세요.

참 쉽죠?

아참. 베타리딩은 봄싹 스터디가 전담하기 때문에, 봄싹 그룹스에 가입하셔야 합니다. 설마... 베타리딩을 하고 싶으셔서 가입하시는 분들은...;; 있으시려나;; 환영합니다. ;-)
top


[봄싹] 스프링 레퍼런스 3.0 번역 시작



http://springsprout.org/wiki/464.do

3.0 레퍼런스 번역을 꾸준히 하겠습니다. 그동안 블로그에 조금씩 번역해서 올려두기도 했었는데 아무래도 레퍼런스 글은 블로그에서 찾아보는게 불편해서 봄싹 위키에 정리하기로 했습니다.

일단은 저 혼자 시작합니다. 하지만 봄싹 회원이라면 누구나 위키 페이지를 추가/수정/이동 시킬 수 있기 때문에 자유롭게 참여하실 수 있습니다.

정해진 틀도 없고 파트를 나누지도 않았지만, 봄싹 사이트도 처음에는 이런 방법으로 개발을 시작했습니다. 지금은 제법 틀도 갖춰져 있고, 특정 모듈 또는 기능 담당자(? 라기 보단 스스로 책임을 느끼시는 분들)도 있습니다. 수직 구조로 누가 누구에게 지시하거나 일을 나눠주지 않고 수평구조로 서로 토론하며 자신이 만들고 싶은 기능을 마음대로 구현해 넣고 있습니다. 레퍼런스도 이런 방법으로 번역을 완성할 겁니다.

기여(?).. 흠. 참여하고 싶으신 분들은 언제나 대환영입니다.

파이팅!

ps: 위키 수정/추가시 포인트를 계산해서 위키 기여도를 측정해야겠군요. 가장 많이 기여한 분에게 봄싹 티셔츠라도...

ps: 위키 미리 보기 화면과 실제 화면이 좀 다른데;; 아마도 조만간 소내기형이 수정해주지 않을까 싶네요... 형 수정해주세요.. ㅠ.ㅠ


top


프로 스프링 2.5 번역서가 나왔습니다.





작년 11월 부터 번역을 시작해서 지난 달(4월) 말까지 작업을 했으니 거의 반년이 걸린 셈입니다. 짧은 글들을 번역하는 작업은 꾸준히 해왔지만, 책 번역은 처음이고 게다가 공동 번역이라 용어나 번역 투를 일관성있게 맞춰야 하는 어려움은 처음 겪어봤습니다.

프로 스프링 2.5는 그 분량이 말해주듯이 스프링 프레임워크의 상당히 많은 영역을 다루고 있습니다. 거의 대부분을 다루고 있다고 할 수 있겠습니다. 얼마전에 저도 Tiles 연동을 하면서 뒤적거린적이 있을 정도 입니다. 목차를 보고 원하는 부분만 그때 그때 찾아서 참조하실 수도 있고 앞에서부터 쭉~ 읽어나가셔도 무리가 없는 책입니다. 읽다가 지치기 쉽상이기 때문에 저라면 전자를 권해드리겠습니다.

이 책의 단점 중 하나였던 소스 코드는 정말 너무하다 싶었습니다. 국내 개발자들이 많이 사용하는 이클립스가 아니라 상용툴인 인텔리J를 사용하였고, 소스 코드에 필요한 라이브러리조차 없이 그냥 코드만 제공하고 있었습니다. 그걸 봄싹 스터디김성윤군김재진군이 맡아서 이클립스 기반 메이븐 프로젝트로 변환해주었고, 중간 중간 소스 코드와 본문이 맞지 않는 부분을 찾아내어 수정하는 작업을 해줬습니다.

책의 처음부터 끝까지 제가 한 번 점검을 했고, 봄싹 스터디에서 다시 책 전반에 걸쳐 베타리딩을 해 주었고, 마지막으로 이대엽님께서 정말 정말 꼼꼼하고 상세하게 최종 베타리딩을 해주셨습니다. 아마 대엽님의 마지막 베타리딩이 없었다면 부끄러운 책이 될뻔했습니다. 덕분에 많이 부끄럽진 않은 번역서를 낼 수 있었습니다. 이 포스트를 빌어 진심으로 감사 인사 드립니다.

힘들어 질때마다 맛있는 밥한끼로 번역에 매진할 수 있게 도와주신 위키북스에도 감사드립니다. 끝으로, 같이 번역하신 역자분들과 베타리딩에 참여해주신 모든 분들께 다시 한 번 감사 드립니다.

다음 번역서 하이버네이트에 또 다시 매진하겠습니다!! 파이팅!!
top


프로 스프링 2.5 6장 저자와 번역 합의 메일



봄싹스터디에서 베타리딩 중인 프로 스프링 2.5 6장 AOP 관련 내용 중에 이상한 부분이 있다는 글이 올라온적이 있습니다. 성윤님이 올린 글 @Aspect는 누구의 것?이라는 글인데 저 부분을 번역한 것이 바로 접니다. 번역하면서도 저 부분이 뭔가 맘에 걸렸지만 일단은 번역 자체가 급해서 걍 넘어갔었는데 다행히도 베타리딩에서 잘 걸렸네요.

몇 일 미루다가 오늘 아침 저자에게 메일을 보냈습니다.

사용자 삽입 이미지

대충 @AspectJ 애스팩트가 AspectJ에 의존하는데 왜 의존하지 않는다고 썼느냐.. 라고 보냈습니다. 그랬더니 답장이 왔는데..

사용자 삽입 이미지

음.. 이건 걍 읽어보시면 좋은 내용입니다. 본래는 어쩌구 저쩌구 하면서 좀 장황하게 얘기를 해주네요. 중요한건 ApsectJ 라이브러리를 참조하기는 하지만 애노테이션을 떄문에 참조하는 것이지 스프링 AOP를 사용할 때는 AspectJ의 compile-time weaving 같은 컴포넌트를 사용하진 않는다는 겁니다. 그런 뜻으로 AspectJ에 의존하지 않는다고 한거라는거죠.

하지만 너무 애매하자나요. 그래서 다시 메일을 보냈습니다.

사용자 삽입 이미지

애매하니까 AspectJ 라이브러리에서 애노테이션만 사용하고 다른 것들은 사용하지 않는다는 식으로 번역하겠다고 보냈습니다.

사용자 삽입 이미지

귿~ 잘 해결됐네요. 그렇게 하랍니다. 번역서에서는 좀 더 분명하게 적어드리겠습니다.


top


재벌의 묘미(?)



출판사 부탁으로 다른 분이 번역한 걸 손보는 작업을 하고 있습니다. 물론 자봉은 아닙니다. 그리 내키는 작업은 아닙니다. 누군가의 자존심을 상하게 하는 일일 수도 있으니까요.

그런데 참 재밌습니다. 번역을 꾸준히 하다보면 자신 만의 패턴이 생기는데 같은 상황에서 다른 분들은 해당 표현을 어떻게 한글화 하는지 볼 수 있습니다. 그런 재미가 쏠쏠합니다.

가끔은 다른분이 표현한 것보다 더 좋은 표현이 떠올라서 그걸로 수정할 때가 있는데 그럴 때는 뭔가 '잘난채'하는 기분도 느껴집니다. 그래봤자 도토리 키재기지만 말이죠.ㅋㅋㅋ

이런 글을 쓰면 마치 제가 번역을 쫌 하는 것처럼 느끼실 수 있겠지만 전혀 그렇치 않으니까 그런 생각은 하지 말아주세요. 저는 관심있는 글을 번역하는게 재밌어서 하는거지 잘해서 한다거나 이름 한 줄 때문에 한다거나 돈을 보고 하는게 아니랍니다.(솔직히 말하면 이런 이유들도 어느 정도는 작용을 합니다.) 제가 책을 1년에 30권만 읽었어도(부끄럽게도 1년에 그 정도도 안 본다는 거죠..ㅋ) 번역 품질이 더 좋아졌을 수 있을텐데하며 아쉬워 하는 중입니다. 말이 나온김에 올해에는 한 달에 3권을 목표로 도전해야겠습니다.

예를 들어..

Listing 8-4. Mixed-Concern Interface

초벌: 목록 8-4. 잡다한 관심 사항이 있는 인터페이스

재벌: 코드 8-4. 혼잡한(Mixed-Concern) 인터페이스

요런 재미가 있다고나 할까요...
top

TAG 재벌

번역 품질을 높이는 방법?



전 잘 모릅니다. 번역을 꾸준히 하고는 있지만 잘 한다고 생각하지도 않으며 잘 하려고 연구를 해보지도 않았습니다. 그럴 시간에 하나라도 더 번역을 해야하기 때문에... 그래도 한 번 생각난 김에 정리해보면 다음과 같습니다.

먼저 번역하는 사람의 문장력이 좋아야 합니다. 번역자가 문장력이 좋고 한글 표현을 잘 사용할 줄 안다면 그만큼 품질 좋은 번역 기사나 번역서가 나올 겁니다.

다음으로 번역자가 영어를 감당할 수 있어야 합니다. 영어를 잘 몰라도 주변에 영어를 잘 알고 있는 친구나 사전을 이용해 가면서 문맥에 비슷한 표현이 나오도록 할 수 있어야 합니다. 기술 서적 중에 쉬운 책들은 중학교 수준 영어 실력만 있어도 번역이 가능하죠.

세번째로는 번역하려는 내용을 알고 있어야 합니다. 저 같은 경우 짧은 글을 번역할 때는 이 규칙은 보통 무시합니다. 새로운 기술이 알고 싶어서 번역할 때도 있거든요. 대신 책이나 레퍼런스 같이 분량이 많아서 일관성이 있어야 하고 어떤 기준이 필요할 때는 해당 기술을 얼마나 잘 이해하고 있는가가 번역 품지을 좌우하기도 합니다. 실제로 제가 메이븐을 하나도 모를 때 메이븐 튜토리얼을 번역한 적이 있는데.. 요즘 들어 가끔보게 되면 민망해 죽을 지경입니다.

네번째로는 재벌이 중요합니다. 다시 한 번 전체 내용을 읽어보면서 날림 번역으로 어색한 문장이나 문맥에 맞지 않는 내용이 눈에 띄면 다시 원문과 비교해서 손보는 작업입니다. 이 작업을 하면서 자신이 읽어도 이해가 된다. 싶을 정도면 일단 OK 입니다. 저는 보통 짧은 글은 재벌도 잘 하지 않는 편입니다. 짧은 글은 애초에 처음 번역할 때 날림 번역을 하지 않고 문맥에 맞추면서 하기 때문에 자잘한 오타와 한 두 문장을 고쳐야 하는데 시간을 소비하고 싶지 않아서 입니다.

마지막으로는 번역을 꾸준히 해서 감을 잃지 말아야 하는건데 이건 잘 지키고 있습니다. 꾸준히 하다보면 비슷한 문장이 등장했을 때 번역 패턴이 생기기도 하고 더 좋은 한글 표현이 떠오르기도 합니다. 예를 들어 오늘 GMP를 듣다가 알게 된건데 All I want for cristmas is you 같은 경우. "내가 크리스마때 원하는 전부는 너야." 라고 All 을 곧이 곧대로 번역하는 거 보다 "내가 크리스마스때 원하는 건 오직 너 뿐이야." 라고 All의 의미를 반전시키면 훨씬 깔끔한 문장이 되는거죠. 이런 건 꾸준히 하다보면 하나 둘 씩 생기는 스킬 같은 거라고 생각합니다.

어쩃거나.. 결론은 번역 품질을 높이려면 번역자가 번역을 잘 해야 한다는 거... 그렇지 않고 베타리딩에 모든 걸 건다?? 글쎄요. 저 같은 경우 베타리딩 할 때 품질이 영 아니면 대충 해버리거나 중간에 포기해버립니다. 베타리더가 돈을 받는 것도 아니고 명예가 생기는 것도 아닌데 감수자나 번역자 역할을 대신 해줄 순 없으니까요.
top

TAG 번역

one A for every B 번역하기



얼핏보면 모든 B에 대한 하나의 A. 즉 모든 B가 하나의 A를 공유하는 것 같이 보이지만, 전혀~~ 전~~~혀 아닙니다. 완전히 틀린 번역이 되버립니다.

"각각의 B에 A 하나씩"

이게 정답입니다.

"the application now maintains one instance of the aspect for every target"

자 그럼 위의 문장은 어떻게 번역 or 이해해야 할까요?

"이제 애플리케이션은 각각의 타겟 객체 마다 애스팩트 객체를 하나씩 사용하게 된다."

이렇게 됩니다. 간혹 원서로 공부를 하시거나 번역을 하실 때 주의 하시기 바랍니다.
top

TAG Every, 번역

번역 할것들이 넘쳤다. 열심히 하자!



9월

- Ajax and Java development made simpler, Part 3: Build UI features based on DOM, JavaScript, and JSP tag files
- JSF for nonbelievers: JSF conversion and validation

10월

- Getting started with JavaServer Faces 1.2, Part 1: Building basic applications (스크린캐스팅)
- JSF for nonbelievers: JSF component development
- Automation for the people: Continual refactoring

11월

- Meet the JavaScript Development Toolkit
- Automation for the people: Hands-free database migration



- Java Persistence With Hibernate
- Pro Spring 2.5

기타

- Spring Dynamic Modules Reference
- The Ted Neward Challenge (AOP without the buzzwords)

top


Ivy로 메이븐 저장소를 사용하기



Maven이 의존성 관리나, 다양한 플러그인들, 기본 와꾸 만들어주기(아키타입) 등의 기능 면에서 좋긴 한데, 학습 곡선 높고(Ant에 비해), 적응 시간이 오래 걸린다는(역시 Ant에 비해) 단점이 있습니다.

의존성 관리는 사실 사람이 개입하지 않고서 자동으로 처리하기는 참으로 난감한데, 그래도 초기에 한 번 고생하고, 주기적으로 한 시간간 정도만 고생하면 모든 라이브러리들을 CVS나 SVN에 들고다니지 않아도 되서 정말 편합니다. 구글코드 같은 경우 jar 파일을 다운로드/업로드 하다가 인터넷 연결 끊어져서 다시 커밋하거나 업데이트 받아야 하는 불상사가 생기기도 하죠. 따라서, 어찌됐든 의존성들은 버전 관리 저장소에서 빼주는게 훨씬 편합니다. 그러면서도 버전관리까지 해주는 Maven이 고맙기도 하지만, 사실 개발자가 고생한거지 Maven은 그냥 시킨대로 해줬을 뿐입니다. 그래도 하나 고마운게 있다면, 저장소. 로컬 저장소에 없으면 원격 저장소에서 다운로드 받을 수 있는 그 저장소가 좋습니다.

그런데 Ant에서도 이 메이븐 저장소(본문에서는 Common Repository라는 단어를 사용하고 있는데, 메이븐만 이용할 수 있는 저장소가 아니니까 이게 더 맞는 표현 같네요. 번역은 "공공 저장소" 라고 하고 있습니다.)를 이용할 수 있습니다. 따라서 굳이 Maven을 학습하지 않고 Ant 서브프로젝트인 Ivy의 task 몇 개만 살펴보시면 됩니다.

http://www.ibm.com/developerworks/java/library/j-ap05068/index.html

현재 번역 중이며 7월 중에 IBM DeveloperWorks에 올라갈 것 같네요.

top


6, 7, 8월에 번역할 기사



6월에 번역할 기사

Plug-in development 101, Part 1: The fundamentals(완료, 한글판)

Automation for the people: Hands-off load testing
(완료, 처리중)

Plug-in development 101, Part 2: Introducing rich-client applications(진행중)

7월에 번역할 기사

Automation for the people: Manage dependencies with Ivy

Ajax and Java development made simpler, Part 1

Automation for the people: Pushbutton documentation

8월에 번역할 기사

Ajax and Java development made simpler, Part 2

Develop Ajax applications like the pros, Part 1


Meet the JavaScript Development Toolkit

매일 저녁 퇴근 후에 번역을하고, 스프링 DM 레퍼런스좀 보다 보면 금방 12시가 넘고 그럼 졸려서 뻗어버립니다. 기사 번역은 정말 재밌는 것 같습니다. 짧은 글들이라 하루 이틀 정도면 번역이 되는데(물론 가끔 말이 많은 기사들은 4일~5일이 걸리기도 합니다.) 다양한 주제로 읽고, 공부도 하고, 번역해서 용돈도 벌 수 있다는게 참 매력적입니다.

위 기사들이 번역되면 한국 IBM developerWorks에 올라옵니다. 요즘은 재벌을 안하고 한방에 번역하고 있어서 오탈자가 많을 듯 한데 편집해주시는 분께서 잘 봐주고 계신것 같아 다행입니다. 어쨋든, 오역이나 오탈자 지적 달게 받겠습니다.
top


롤러스케이트 구현



원문 : http://martinfowler.com/bliki/RollerSkateImplementation.html

롤러스케스 구현 agile 2007년 9월 9일 반응

애자일 개발의 핵심 요소는 어떻게 하면 조그마한 기능 집합으로 시스템을 가동할 수 있을지를 도모하는 것이다. 우리는 비즈니스 가치를 목적으로 소프트웨어를 만든다. 따라서 빠르게 시스템을 가동할수록 그로 인한 비즈니스 가치를 조금이라도 더 빨리 얻을 수 있다.

나의 동료 Dave Leigh는 이런 류에 해당하는 이야기를 해줬다.(이 이야기를 예로 들기 좋아한다.) 중개 회사에서 일을 하고 있을 때였다. 그들은 시장에 들여놓고 싶어하는 새로운 종류의 상품을 가져왔다. 소프트웨어가 할 일은 웹 페이지를 제공해서 고객들이 입력을 하면 뒷단의 시스템에 필요한 거래를 생성하는 것이었다. 그러나 Dave는 그보다 더 빨리 제품을 시장에 들여놓는 방법을 생각해냈다.

•    버전 1은 정적인 웹 페이지로 제품을 설명하고 연락을 할 수 있는 전화번호를 제공한다. 몇몇 임시직을 고용하여 고객의 전화를 받고 주문 정보를 뒷단의 시스템에 입력하도록 한다.
•    버전 2는 고객이 정보를 입력할 수 있는 웹 양식이다. 하지만 이 버전에서는 데이터를 뒷단의 시스템으로 이동시키지 않는다. 그 대신 웹 양식은 팩스를 생성한다. 그들은 임시적으로 팩스기기로부터 주문을 받을 사람을 더 고용하여 팩스의 정보를 가지고 뒷단의 시스템으로 정보를 입력하도록 한다. 팩스 기기가 좀 멀리 떨어져있기 때문에 롤러스케이트라는 용어를 붙였다.
•    버전 3은 웹 양식을 읽어서 뒷단의 시스템으로 직접 연결한다.

처음 두 개의 버전은 최고로 멋진 해결책이 아닐 수도 있다. 그러나 그들은 제품을 시장에 훨씬 더 빨리 내놓을 수 있었다. 롤러스케이트를 사용한 점진적인 개발의 또 다른 예는 생각이 나질 않는다. 그러나 그 이유는 필요가 없어서라기 보다는 상상력의 부족 때문일 것이다.
top


테스트 암 Test Cancer



TestCancer design 2007년 12월 6일 Reactions

전업을 저자로 전환함에 따라, 시간이 갈수록 소프트웨어 개발 현장과 멀어져 가는 내 자신이 걱정된다. 다른 유명한 거장들이 현실과 동떨어진 모습을 본 적이 있는데, 내가 그와 동일한 불안감을 느끼고 있다. 이런 불안감과 싸우는데 가장 큰 도움이 되는 것은 바로 ThougtWorks다. 그곳에서 평상시처럼 현실감을 느낄 수 있다.

ThoughtWorks는 또한 현장의 아이디어를 얻을 수 있는 원천이며, 나는 동료들이 알아내거나 개발한 유용한 것들에 대해 글을 쓰는 것을 좋아한다. 보통 그것들은 나의 몇몇 독자들이 사용할 수 있길 바라던 유용한 아이디어들이었다. 나의 이번 주제는 그러한 선물과도 같은 주제는 아니다. 이번 것은 답변을 할 수 없는 문제에 관한 것이다.

그 시나리오는 다음과 같다. 우린 프로젝트를 고객으로부터 요청 받은 뒤 멋진 새로운 소프트웨어를 만들어 준다. 근래의 유행처럼, 이 소프트웨어에 대한 다양한 자동화된 테스트를 제공한다(보통 기능 코드의 라인 수 만큼의 테스트 코드가 존재한다.). 이런 테스트들은 보통 단위 테스트와 경계 기능 그리고 인수 테스트를 포함하고 있다. 두 방법의 테스트 모두 소프트웨어가 무엇을 하는지 그리고 소프트웨어를 개선시킬 때 어떤 버그가 발생하는지 빠르게 알아낼 수 있는 유용한 설명서다. 우린 이런 테스트들을 소프트웨어 시스템 개발을 성공시킬 수 있는 요소로써, 중요시하고 있다.

몇 개월 후에 우리는 행복한 고객으로부터 소프트웨어에 새로운 특징이나 기능을 추가하기 위한 작업 요청을 받게 된다. 그럼 작업에 돌입하고 문제가 있을 만한 부분을 중심으로 열심히 일하기 시작한다. 최소한 우리가 실수했을 만한 부분부터 말이다. 바로 그 순간 불쾌한 상황을 맞이하게 된다.

테스트가 더 이상 동작하지 않는다.

가끔 테스트가 빌드 스크립트에 포함되어있지 않아서, 몇 달 동안이나 실행된 적이 없을 수도 있다. 가끔 “테스트들”이 실행은 되지만, 그들 중 상당부분이 손실됐을 수 있다. 두 경우 모두, 우리의 중요한 테스트들을 엄청난 시간 소비를 야기하고 박멸하기조차 힘든 지독한 암에 걸리게 한다.

그럼 우린 대체 무슨 일이 발생했는지 물어보게 되고 “코드에 약간 손을 댔더니 테스트가 깨져서, 그 테스트들을 제거했습니다.”와 비슷한 답변을 듣게 된다. 여러분들은 이것을 우리의 실수라고 생각할 수 있다. 테스트에 대한 가치를 고객팀에게 충분히 설명하도록 관리하지 못했기 때문이다. 그냥 무시할 수 있는 것이 아니라 조사해야 할 필요가 있는 테스트가 무사히 통과하도록 하려면 더 많은 무언가를 해야 한다. 그러나 뭐라고 하든, 누군가는 이렇게 이야기할 것이다. 그런 테스트의 암은 흔히 발생하는 질병이라고.

테스트 암의 발생 원인이 테스트를 작성했기 때문이라고 생각하지 않는다. 비록 우리가 떠나자마자 맹독 기질이 있는 변경으로 인해 모든 테스트를 지워버렸다 하더라도, 그들의 가치는 이미 시스템을 개발할 때 얻을 수 있었기 때문이다. 그리고 테스트들이 항상 암에 걸리는 것은 아니다. 우리가 이미 수 년 전에 끝낸 시스템을 관리하고 있는 개발자로부터 자신이 TDD로 전향하게 되었다는 이야기를 들었다. 테스트는 우리의 코드가 다른 회사가 나중에 추가한 코드보다 더 쉽게 동작하도록 해준다.

top


JAX-WS 2.0 웹 서비스 설계와 개발



원문 : Design and develop JAX-WS 2.0 Web services
번역 : 언젠가 한국 IBM developerWorks에 올라올 듯.
후기 : 학교 수업 중에 Axis를 사용해서 웹 서비스를 개발하고 배포, 테스트를 해본 적이 있습니다. 그 당시 XML, XSD를 익히는 것도 낯설었는데, 웹 서비스에 WSDL이니 스텁이니 하는 개념들까지 더하니까 정말 어지러웠습니다. 아마도 이 글로 처음 웹 서비스를 접하시는 분들은 저와 비슷한 현기증을 느낄 수 있을 것입니다. 그러나 만약 한 번이라도 웹 서비스를 개발해보신 적이 있으신 분들은 JAX-WS를 사용하면 자바 클래스에 간단한 애노테이션을 붙여서 WSDL을 생성해 낼 수 있다는 장점이 눈의 띄실 것입니다. 그만큼 편하게 웹 서비스를 개발할 수 있게 도와 줍니다.

번역할 때마다 비슷한 단어에서 어떻게 옮기는 것이 좋을까 고민하게 됩니다. mapped, map to 도 그런 것 중에 하나 인데, '맵핑 되어 있다." "맵핑한다."로 번역을 했습니다. 그리고 artifact는 그냥 '파일'로 번역을 했습니다. JAX-WS 결과물 만들기... 라고 하면 좀 어색해서요.ㅎ;;
top


선언된 순서를 변경하는 것은 리팩터링인가?



원문 : IsDeclarationOrderingRefactoring     refactoring     1 September 2004

RefactoringBoundary.

자바 프로그램 내부에 있는 메소드와 필드가 선언된 순서를 변경하는 것은 리팩터링인가요?

근래의 프로그래밍 언어들은 내부에 선언되어 있는 요소들의 순서가 프로그램에 전혀 영향을 주지 않는다. 만약 텍스트 파일 내부에 있는 두 개의 메소드 위치를 서로 바꾸더라도, 프로그램은 아무런 영향을 받지 않는다. 이것을 리팩터링이라고 할 수 있는 이유는 변경으로 인해서 프로그램이 동작하는 방법에 영향을 주지 않기 때문이다. 이것은 설계를 변경하지 않으며, 만약 설계가 바뀐다면 리팩터링이라고 할 수 없다.

리팩터링 정의에서, “이해하기 쉽고 수정하는 비용을 최소화 하도록” 이라는 구문을 사용했다. 선언된 위치를 변경하는 것이 이에 해당하는가? 몇몇 경우에 그럴 수 있다고 생각한다. 클래스 내부에서 서로 관련되어 있는 속성들을 묶어두는 것이 좋다. 그러한 방법으로 속성들을 정렬하면 클래스가 어떻게 동작하는지 이해하는데 도움이 된다. 특히 테스트 케이스를 작성할 때 유용하다. (비록 특정 xunit 구현체에서는, 순서가 실행 결과에 영향을 줄 수 있지만 말이다.) 결국 코드의 이해도를 높여주기 때문에, 선언된 순서 변경을 리팩터링이라고 볼 수 있다.

이것이 내부 구현을 변경하지 않는다는 사실은 중요하지 않다. 메소드의 이름 변경은 실행하는 내용을 변경하지는 않는다. 하지만 이름 변경은 프로그램의 이해도를 높이는 매우 중요한 리팩터링이다.

top


리팩터링 정의



원문 : DefinitionOfRefactoring     refactoring     

나(Martin Fowler)의 리팩터링 책에서, 리팩터링에 대한 몇몇 정의를 내렸다.

리팩터링 (명사): 소프트웨어의 내부 구조를 보다 이해하기 쉽고 수정하는 비용을 최소화 하도록 하는 변경. 이 때 “주목할 만한” 행동의 변경이 있으면 안 된다.

리팩터링 (동사): “주목할 만한” 행동의 변경 없이, 몇몇 리팩터링들을 적용하여 소프트웨어의 내부 구조를 변경하다.

top


발견하지 못한 버그를 수정하는 것은 리팩터링인가?



원문 : IsFixingAnUnknownBugRefactoring     refactoring     3 September 2004

RefactoringBoundary.

Przemyslaw Pokrywka가 매우 난해한 질문을 했다. 에서 소개한 리팩터링 중에 하나로 Introduce Null Object라는 것이 있는데, (이것은 매우 유용한 리팩터링으로 Josh의 새 책에서도 다루고 있다) Przemyslaw의 요지는 이 리팩터링이 행동을 바꿀 수 있다는 것이었다. 만약 여러분이 null을 반환하는 메소드를 가지고 있고, 그 반환 값인 null에게 메소드 호출을 하면 null pointer exception을 받게 될 것이다. 이럴 때 Null Object를 사용해서 (예외를 발생시키는 것이 아니라) 기본 행동을 수행하도록 정의할 수 있다.

요즘 다수의 리팩터링들이 행동을 바꾸고 있는데, 이들은 근본적으로 그렇게 하도록 의도된 것 들이다. 예를 들어 Form Template Method를 적용하면, 프로그램이 다르게 동작한다. 핵심적으로 질문해야 할 것은 리팩터링 정의에서 언급한 “주목할 만한” 행동에 해당하는가 이다. “주목할 만한” 행동이란 프로그램이 원래 의도했던 것을 변경했는지 여부를 뜻한다. Introduce Null Object를 사용하면 프로그램에서 반환된 레퍼런스 변수를 조작하는 부분 (특히 null인지 확인하는 부분)을 살펴보아야 한다. 그렇기 때문에 이 리팩터링이 다소 복잡한 것이다.

질문 중에서 가장 흥미로운 부분은 만약에 버그가 있는 부분을 놓치면 어떤 일이 발생하는가 이다. 프로그램 내부의 어디에선가 null 레퍼런스에게 메소드를 호출하는 부분이 있다고 하자. 이 부분을 간과하여 놓쳤고 최종 사용자에게까지 전달되었다면, 리팩터링 전에는 예외를 발생시켰을 것이다. 리팩터링 후에는 기본 행동을 가지게 되고 이것은 사실상 버그를 고친 것에 해당한다. 미처 발견하지 못했던 버그를 고치는 것은 리팩터링일까?

그렇다. 왜냐면 스스로가 지각하지 못했거나 충분히 살펴보지 못한 (버그를 발생시키는) 행동은 “눈에 띄는” 행동이라고 할 수 없기 때문이다. 비록 버그를 알고 있었다 하더라도, 행동을 변함없이 유지하려고 인식했던 버그가 아니라면, 여전히 그것을 리팩터링이라고 불러도 좋다.

이것은 흥미로운 경우이기 때문에, 내 생각을 쉽게 바꿀 수도 있고 이와 비슷한 경계 사례들을 더 조사해 봐야겠다.

여기서 생각해 볼 것 한 가지는 수작업으로 하는 리팩터링과 툴 기반의 리택퍼링의 차이점이다. 손수 하는 리팩터링은 이런 식의 스스로 판단을 할 수 있는 반면에, 툴을 사용할 때는 좀 더 주의해야 한다. 아직은 툴들이 행동을 유지하는 것을 항상 보장하지는 못한다. 심지어, 파일로부터 읽어 들인 이름으로 리플렉션을 사용하여 메소드를 호출하는 경우 rename method는 리팩터링 도중 깨질 수 도 있다.

top


성능 최적화가 리팩터링인가?



RefactoringBoundary.

프로그램의 성능을 향상 시키기 위해서 변경을 가했을 때, 이것을 리팩터링으로 볼 수 있나요?

성능 최적화와 리팩터링은 둘 모두 프로그램에 같은 변경을 가하기도 하며, 특정한 변경은 둘 모두에 해당하기도 하지만, 이 둘을 별개의 것으로 구분한다.

이 둘을 구분하는 이유는 서로 다른 목적을 가지고 있기 때문이다. 리팩터링을 하는 목적은 코드를 좀 더 쉽게 이해하기 위한 것이며, 성능 최적화의 목적은 좀 더 빠르게 동작하도록 하는 것이다. (예를 들어) 변수 하나를 추가하는 것이 둘 모두를 위한 것이 될 수도 있겠지만, 그 작업을 어떻게 수행하느냐에 따라 본질적으로 둘 중 하나에 해당하게 된다. 리팩터링을 할 때는 코드를 깔끔하게 정리하는 것에 집중해야 한다. 이때, 변경을 성공적으로 수행했는지에 대한 판단은 프로그램을 더 쉽게 이해하도록 변경했는가에 대한 자신의 (주관적인) 평가에 기반하게 된다. 성능 최적화를 할 때는 성능에 집중해야 한다. 프로파일러를 이용하여, 변경을 가하기 전과 후의 성능을 비교함으로써 변경 작업이 진짜로 성능 향상에 도움이 되었는지 확인해야 한다. 만약 성능이 매우 중요한 상황이라면, 차후에 (컴파일러, VM 같은)환경이 변경 됐을 때 그것의 효율성을 다시 테스트 할 수 있도록 변경 사항을 로그로 남겨두어야 한다.

결론적으로 리팩터링과 성능 최적화는 서로 비슷하기도 하고, 다수의 변경을 공유하기도 하지만, 그들의 목적이 다르기 때문에 별개의 것으로 구분한다.

원문 : IsOptimizationRefactoring

top


아마존 웹 서비스로 애플리케이션 개발을 가속시키자.



원문
Boost application development with Amazon Web Services, Part 1: How to use the Amazon E-Commerce Service

Boost application development with Amazon Web Services, Part 2: Introduction to the Amazon Simple Queue Service

Boost application development with Amazon Web Services, Part 3: Amazon Simple Queue Service
Using Web services from Java ME


번역
언젠가.. 한국 IBM 디벨롭웍스에 올라올 예정..

후기
Part 1과 Part 2는 2005년에 작성된 문서인데 Part 3은 2007년 7월 11일에 올라온 글입니다. 원랜 2007년의 글만 번역을 하려고 했지만 아마존 E-Commerce를 다루고 있는 Part 1이 더 재밌어 보이고 SQS를 다룬 Part 2와 Part 3은 곁다리로 알아두면 괜찮아 보이고 짧기 때문에 셋 다 번역을 했습니다. AWS 이용해서 애플리케이션을 개발할 때 보통은 Part 1이 가장 도움이 될 것 같고, 큐 서비스를 구현해야 한다면 Part 2, 큐 서비스를 J2ME에서 사용해야 한다면 Part 3을 참조하시면 됩니다.

top


'RFC 2119'가 뭐지??



JSR-250 스펙을 읽던 중 처음 부터 막히기 시작합니다.

"본 문서의 "SHOULD, SHOULD NOT, MUST 등등등'의 표현은 RFC 2119를 따르고 있다."

이런 문구가 처음 부터 저를 귀찮게 합니다. 안그래도 JSR-250 이라는 이름도 무슨 암호 같아서 기분이 언짢았는데 시작부터 또 다른 암호가 나를 괴롭히는구나.. 아무리 나를 괴롭혀도 나한텐 구글신이 있거든? 하면서 검색을 하니까 역시나 구글신.. 바로 알려줍니다.
"Key words for use in RFCs to Indicate Requirement Levels"
"RFC에서 사용하는 필수 정도를 나타내는 단어"

1. MUST 이 단어와 "REQUIRED" 그리고 "SHALL" 은 꼭 필요한 요구사항을 정의할 때 사용.

2. MUST NOT 이 구문과 "SHALL NOT"은 절대 금지 사항을 나타낼 때 사용.

3. SHOULD 이 단어와 "RECOMMENDED"는 없어도 되지만 그래도 권장할 때 사용.

4. SHOULD NOT 이 구문과 "NOT RECOMMENDED"는 3번과 반대의 의미.

5. MAY 이 단어와 "OPTIONAL" 완전 선택적이라는 뜻을 나타낼 때 사용.

자 그럼 다시 JSR-250으로 돌아갑니다. :)

top

TAG RFC 2119

Building Google gadgets, Part 2



원문 : http://www.ibm.com/developerworks/edu/wa-dw-wa-google2.html
번역 : '구글 가젯 만들기, Part 2 UI 작업하기' 라는 이름으로 언젠가 IBM developerWorks에 올라올듯..
번역 후기
 Part 1과 마찬가지로 난이초가 초급인 문서이기 때문에 역시 따라하기 쉽고 이번 Part가 마지막 파트 입니다. 이번에는 탭, 드래그 앤 드람, 메시지 그리고 디버깅을 다루고 있습니다. 각각의 라이브러리를 사용할 때 필요한 선언을 해주고, 라이브러리를 사용해서 객체를 만들고 자바스크립트 함수를 사용하여 콜백을 구현해주는 방식으로 간단하게 사용할 수 있었습니다. 시리즈 번역은 처음으로 해봤는데 단편에 비해 장점이 있어군요. 바로 'About Author"라는 부분이 공통으로 나오는데 이 부분을 한번만 번역해도 된다는 거죠. ㅎㅎ 한번만 번역하고 두 번 써먹는.. 비록 몇 줄 안되지만 매우 좋았습니다. 다음에도 시리즈로 번역할 것이 있나 찾아봐야겠습니다.


top


Building Google gadgets, Part 1



원문 : http://www.ibm.com/developerworks/edu/wa-dw-wa-google1.html
번역 : 언젠가..'구글 가젯 만들기 Part 1. 가젯의 기본 구성 요소'라는 이름으로 IBM developerworks에 올라올 예정..
번역후기
간단한 구글 가젯을 만들고 웹에 올려두고 자신의 웹 페이지에 추가할 수 있는 내용을 다루고 있습니다. 가젯의 기본 요소들인 Pref, UserPref, Content를 설명하고 있습니다. 쉽게 따라할 수 있도록 만들어둔 튜토리얼입니다. 아마 1시간 정도면 금방 가젯 하나를 만들 수 있을 것 입니다. 그러나 보다 더 고급 기능을 읽히기 위한 전초전일 뿐 part 2에서 보다 고급 기능을 다룰 것 같습니다. 아직은 마땅히 만들고 싶은 가젯이 떠오르지 않는데 뭔가 떠오르면 한번 만들어 봐야겠습니다. XML 파일 하나로 애플리케이션을 만들 수 있다니... 구글 대단해열...
top


Agile Database Refactoring with Hibernate 번역



원문 : http://www.onjava.com/lpt/a/7048
번역 :
하이버네이트를 사용한 애자일 데이터베이스 리팩토링(1)
하이버네이트를 사용한 애자일 데이터베이스 리팩토링(2)
번역 후기

물리적으로 테이블을 변경하지 않고도 뷰 만들어서 테이블을 나눈 것 처럼 사용할 수 있도록 데이터베이스를 리팩토링 하는 과정을 보여줍니다. 이 때 스토어드 프로시져나 Instead of 트리거 라는 것을 사용하여 그렇게 할 수 있다고 하는데... DB 공부를 해야겠네요;;ㅋ;

하이버네이트의 맵핑 파일을 사용하여 위에서 만든 뷰 기반의 데이터 모델을 사용하도록 설정하면 테이블을 변경한 것은 아니기 때문에 기존의 다른 애플리케이션은 아무런 문제 없이 동작하게 되고 자신의 애플리케이션은 변경된 테이블을 사용하는 효과를 볼 수 있다는 매우 흥미로운 글이였습니다.

구현을 할 때 테스트 해야할 항목들을 제시해준것도 좋았지만 지면을 좀 더 늘려서 예제 코드를 더 많이 보여줬으면 하는 바램이 생기네요.

top


Four Days on Rails 번역 완료



원문 : http://rails.homelinux.org/
한글판 :
후기 :
대엽님의 댓글로 시작하여 "Four Days on Rails" 번역을 완료했습니다. 1,2장은 대엽님. 3,4장은 제가 번역을 했고 편집은 전부 대엽님이 해주셨습니다. 완전 깔끔한 편집에 놀랐습니다. 대단해요.

이 글을 보기전에 정말 간단한 따라하기 글이 있어서 그걸 보고나서 놀랍다는 생각은 했지만 scaffold로 코드 생성한 다음에는 뭘 어떻게 고쳐야 할지 몰랐었는데 저 글을 보면 대략 어떤 작업들을 해서 커스터마이징 해나가는지 파악할 수 있습니다.

Scffold로 코드를 생성하는 것은 간단하지만 원하는 웹 애플리케이션으로 만들려면 역시 상당한 노력이 필요하리라는 것을 짐작하기에 충분했으며 공부할 것도 적지 않다는 것을 느낄 수 있었습니다.

관심있으신 분들은 보시다가 개선사항에 대한 피드백을 주시면 감사하겠습니다.

사용자 삽입 이미지
조만간 저위에 다음과 같이 한줄이 추가 되면 또 포스팅 하겠습니다. 헤헷
  • Four Days on Rails(Korean) .pdf format(967k) (Dae-yeop Lee, Kee-sun Baek)
top


Eclipse 용 GUI 빌더 Jigloo 사용하기



-원문 : Get started with Jigloo, a GUI builder for Eclipse
-번역 : http://www.ibm.com/developerworks/kr/library/tutorial/os-dw-os-eclipse-jigloo.html
-번역후기
재밌었습니다. 일단 그림이 많고 간단한 사용법인데다가 SWT와 Swing 용어들이 익숙하다 보니 이전에 Maven 관련 글을 번역할 때 만큼 힘들지는 않았습니다. 하지만.. 역시나 영문표현에 익숙하지 못해서 글을 이해는 하겠는데 한글로 옮기는 건 쉽지 않았습니다. 주로 존댓말로 옮기다가 이번에는 반말로 옮기라는 지시를 받고 반말로 번역을 하는데 상당한 어색함을 겪게 됐습니다. 따라서 검토하는데 애를 먹을 것 같습니다.

다음에 SWT로 코딩할 일이 생기면 꼭 Jigloo를 사용해볼 것입니다. 이건 거의 비주얼 베이직으로 코딩하는 거나 비슷하더군요. 마우스 클릭으로 화면 만들고 속성 창에서 텍스트 넣어주고 이벤트 달고 이벤트 핸들링하는 코드를 작성해주면 끝~ 너무 좋아효~

top

TAG Jigloo

Introduction to Apache Maven 2



원문 : http://www-128.ibm.com/developerworks/edu/j-dw-java-mavenv2.html
번역 : http://www.ibm.com/developerworks/kr/library/tutorial/j-dw-java-mavenv2.html
후기 :
잘 모르던 것(Maven 2)에 대한 글을 번역하는 일이 얼마나 난해한가를 경험할 수 있었습니다.
먼저 Maven에서 사용하는 용어들을 한글로 어떻게 옮겨야 할지 정말 난감했습니다. 그 중 가장 난감했던 것은 'Maven Coordinate' 입니다. 처음에는 "Maven 위치" 그 다음 원문을 조금 읽다가 "Maven 좌표"로 수정하고 다시 또 읽다가 "Maven 이름"으로 바꿨지만 여전히 맘에 안들어서 그냥 "Maven 코디네이트"로 수정할까 생각중입니다.
또 난감했던 것으로는 주로 Artifact(이것도 사실 옮기기 난감했지만 그냥 '이건 옮기지 말자'라고 마음 먹고 고유명사처럼 사용하니까 맘이 편하더군요.)를 나타낼 때 원문에서 자주 depedency라고 하는데 이걸 그냥 '종속성'으로 하면 전혀 문맥이 이어지지가 않습니다. 그래서 '종속성을 가지는 것' 이라고 풀어서 썼는데 참 난해하기 '서울역에 그지 없습니다.'(애욕전선 이상없다. 에서 나오는 대사 중 일부...)
번역 도중 그림과 소스코드가 자주 나오면 그보다 더 반가운 일은 없습니다. 완전 집중 했을 때 평균 1시간에 pdf로 3페이지 정도를 번역할 수 있었습니다. 하지만 글자가 많은 경우 1시간에 1페이지를 간신히 하기도 하고 그림과 코드가 많을 땐 1시간에 다섯 페이지를 번역할 수도 있었습니다.
빨리 하려다 보니 좋은 어구가 떠오르지 않으면 그냥 대강 글로 옮기고 넘어가는 부분이 많아져서 다 하긴 했지만 찝찝한 기분을 떨칠수가 없습니다. 이대로 보내드리는 건 '사실 번역 하기 싫다.' 라고 말하는 거나 다름없기 때문에 좀 더 다듬어서 보내드려야겠습니다.
top


Eclipse 3.2를 활용한 리팩토링



원문 : Refactoring in Eclipse 3.2

번역 : Eclipse 3.2를 활용한 리팩토링 - (1), Eclipse 3.2를 활용한 리팩토링 - (2)

후기 : Eclipse 3.2에 추가된 Clean Up 메뉴와 프로퍼티 파일을 만들어 주는 메뉴 그리고 리팩토링 히스토리, Jar 마이그레이션 할 때 유용한 메뉴 외에도 다양한 리팩토링 관련 기능에 대해 설명하고 있습니다. 흠 어서 다른 글도 번역해야 할텐데...
top


Fail-fast vs. complete validation



원문 : http://hanuska.blogspot.com/2007/04/fail-fast-vs-complete-validation.html
번역[각주:1]

대부분 모든 어플리케이션은 사람 또는 다른 어플리케이션과의 상호 작용을 통한 데이터를 가지고 작업해야 합니다. 하지만 종종 이런 데이터들은 어플리케이션이 수용할 만한 요구 사항을 충족하지 못할 수 있습니다. 따라서 데이터는 반드시 검증해야 합니다.

Validation이란 무엇인가?



입력되는 데이터는 그 다음 처리 과정에 적합하여 유효한 것임을 판별하기 위해 반드시 일련의 검증 과정을 거쳐야 합니다.

예를 들어 세개의 멤버를 가지고 있는 클래스르 생각해 봅시다. name:String, created:Date total:int. name은 반드시 설정되어야 하며 길이가 최소한 세 글자 이상이여야 한다는 요구사항을 가지고 있습니다. created 역시 필수 요소이며 현재 시각 이전이어야 합니다. total은 음의 정수면 안됩니다.

데이터 유효성 검증에는 보통 두 가지 접근 방법이 있습니다. fail-fast validation 과 complete validation 입니다.

Fail-fast validation



How it works
만약 어떤 검증 규칙(validation rules)가 실패하면 검증은 그 즉시 멈추고 데이터가 유효하지 않다는 것을 알려주고 처리 과정을 중단합니다.

Output
검증의 결과에 대한 Boolean 값을 알려줍니다. true for valid, false for invalid.

Pros
검증 실패가 발생하면 그 후에 수행할 검증 작업을 멈추기 때문에 complete validation 보다 빠릅니다. 리포팅에 대한 오버헤드가 없습니다.

Cons
검증 실패에 관한 충분한 정보를 제공하지 못합니다.

When to use it
왜 검증이 실패 했는가 하는 자세한 정보가 필요하지 않고 단순히 true 나 false같은 결과를 원할 때 적당합니다. 보통 수정할 수 없는 데이터를 받아 들일 때(사람이 입력하는 것이 없는 시스템에서) 적당합니다.

Example
boolean isValid(String name, Date created, int total)
데이터가 들어가면 Boolean 값을 리턴합니다.

Complete validation



How it works
검증 규칙이 실패 하더라도 검증 절차를 중단하지 않습니다. 데이터가 유효하지 음을 체크 하고 전체 검증 절차를 마친 후에 다음에 처리할 작업을 중단합니다.

Output
Boolean 값으로 입력한 데이터가 유효한지 알려줍니다. true for valid, false for invalid. 에러 컬렉션 같은 폼에 유효성 실패에 대한 정보를 보관합니다.

예들 들어 Struts 프레임워크의 ActionMessages 클래스나 Atlassian JIRA의 ErrorCollection를 참고 하세요.[각주:2]

Pros
유효성 실패의 원인에 대한 정보를 제공합니다. 입력하는 데이터를 수정하는데 필요한 피드백을 제공할 수 있습니다.

Cons
모든 검증 절차를 수행하며 검증에 대한 결과에 대한 추가적인 정보를 리포팅 하기 때문에 file-fast validation보다 느립니다.

When to use it
검증 실패에 대한 원인이 필요할 때 적당합니다. 이 정보는 사용자가 데이터를 입력하고 어떻게 수정해야 하는지에 대한 힌트를 제공합니다.

Example
데이터는 에러 컬렉션과 함께 전달합니다. 유효하지 않은 데이터에 대한 정보는 에러 컬렉션으로부터 알 수 있기 때문에 메소드는 아무것도 반환하지 않습니다.

Conclusion
만약 복잡한 검증 규칙을 입력 필드 단위로 쪼갤 수 있다면 (JavaScript나 AJAX를 사용하여)사용자가 시스템에 적응 하도록 할 수 있습니다. 실시간으로 입력한 데이터에 대한 피드백을 받을 수 있기 때문이죠.

또한 여러 입력 값들을 가지고 데이터의 유효성을 판단해야 하는 경우를 생각해 봅시다. 세 개의 입력 필드로 구성된 하나의 날짜를 나타내는 값이 그런 예에 해당합니다(실제로 이렇게 하진 마세요. 데이터를 입력 받는 좋지 않은 방법입니다.).

사용자 삽입 이미지

또는 아래처럼 Other를 선택했을 때 text area가 보여야 하는 것처럼 조건적으로 필요한 필드의 경우를 생각할 수 있습니다.
 
사용자 삽입 이미지

두 유형의 검증 방법 모두 각각의 목적이 있습니다. 검증이 실패 했을 때 수정하거나 판단하기 위해 여러분에게 얼만큼의 정보가 필요한지에 따라 적당한 방법을 사용하면 됩니다.


  1. 해도 되냐고 물어보긴 했는데 아직 댓글이 안뜨네요. 일단 올리고 안 된다고 하면 지우죠 뭐; [본문으로]
  2. Spring의 Errors 클래스도 예가 될 수 있을 것 같네요. [본문으로]
top


Self Testing Code design



원문 : http://www.martinfowler.com/bliki/SelfTestingCode.html

‘자체 테스트 코드’는 리팩토링에서 기능적인 소프트웨어와 결합되어 전체적으로 자동화된 테스트를 언급하기 위해 사용했던 단어다. 이 단어를 이야기 할 때는 제일 먼저 XUnit 군의 테스트 프레임워크들이 생각난다.

테스트 주도 개발(TDD)
은 자체 테스트 코드를 작성할 때 선호하는 방법이지만 이 방법밖에 없는 것은 아니다. 기능 코드를 개발하기 전에 테스트를 작성하는 것은 그렇지 않은 경우에 비해 많은 장점을 얻을 수 있다. 자체 테스트 코드에서 가장 중요한 것은 테스트 코드를 가지고 있다는 것이지 그것들을 어떻게 만들어 냈는가가 아니다.
top


TestDrivenDevelopment design



TestDrivenDevelopment design

원문 : http://www.martinfowler.com/bliki/TestDrivenDevelopment.html

테스트 주고 개발(TDD)는 테스트를 통해서 개발을 이끌어 내는 설계 기술이다. 본질적으로 다음 세 개의 단순한 단계를 반복하는 것이다.

•    다음으로 추가하고 싶은 기능을 위한 테스트를 작성한다.
•    테스트가 통과 하도록 기능 코드를 작성하라.
•    전체적으로 구조화 되도록 새로운 코드와 기존의 코드를 재구성한다.

시스템의 기능을 구현할 때 한번에 하나씩 테스트 하면서 지속적으로 이 세 단계를 반복한다. XPE2가 선 테스트 프로그래밍(Test First Programming)이라고 부르는 대로 Test를 먼저 작성하는 것은 두 가지 주요 장점이 있다. 그 중 가장 명백한 것으로 테스트를 통과하는 기능 코드만을 작성할 수 있기 때문에 자체 테스트 코드를 얻을 수 있다. 두 번째로 테스트를 먼저 생각하게 되면 코드의 인터페이스를 먼저 생각하게 된다. 인터페이스 그리고 클래스를 어떻게 사용할 것인지에 초점을 맞추는 것은 구현으로부터 인터페이스를 분리해 내는데 도움이 된다.

TDD의 효율성을 올리는 가장 흔한 방법으로 세 번째 단계를 생략하는 것이라고 들었다. 깔끔하게 유지하기 위해 코드를 재구성 하는 것은 TDD 프로세스의 핵심이다. 그렇게 하지 않으면 난잡한 코드 조각 덩어리들의 모임을 보게 될 것이다. (그래도 최소한 테스트는 가지고 있을 것이기 때문에 대부분의 설계 실패에 대한 고통보다는 덜 할 것이다.)

top