태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

달력

09

« 2009/09 »

  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
  •  

'2009/09'에 해당되는 글 3

  1. 2009/09/08 VBScript Empty, Null, Nothing
  2. 2009/09/07 버려지지 않은 코드 (2)
  3. 2009/09/06 신입사원들과 함께한 TDD 토론 (5)
2009/09/08 02:14

VBScript Empty, Null, Nothing 분류없음2009/09/08 02:14

지난주에는 ASP 프로젝트를 유지보수 할 일이 있어서 VBScript를 쓰게 됐는데, 하다보니 제일 헷갈리는게 Empty, Null, Nothing 구분이었다. C# ASP.NET도 그렇고 보통 C/C++도 그렇고 널 체크하나면 끝나는데 이놈의 언어는 깡통 값을 나타내는데 키워드를 세 가지나 쓴다. 변변한 자료 구조 하나 기본으로 제공하지도 않는 주제에(Scripting.Dictionary 정도? 나름 유용하게 잘 썼다) 엉뚱한 곳에 지나치게 신경썼다는 생각까지 들기도 한다.

아무튼 Empty는 초기화되지 않은 값이다. 그래서
Dim value : value = Request.Form("value")
했을 때 아예 value 라는 폼 필드가 존재하지 않으면 IsEmpty(value) = True 이다.

Null은 값이긴 한데 '유효하지 않은 값'이라는 의미를 표현하는 값이다. DB에서 NULL 값을 받아왔을 때 외에는 볼 일이 없을 듯. IsNull(value) 함수로 검사할 수 있다.

결국 C# ASP.NET 에서 쿼리 스트링이나 폼 필드가 null 인지 검사하는 것과 동일한 작업이 VBScript에서는 Empty 검사가 되는 셈이다.

Nothing은 개체(Object)를 사용할 때에 관련 있는 키워드라서 Empty나 Null과는 큰 관계가 없다. 개체를 소멸시키고 싶을 때 Nothing을 살포시 대입해주면 된다. 검사 함수는 따로 없고 If 문 안에서 Is Nothing 형태로 검사할 수 있다.

ps. 개인적으로 VBScript와는 친하지 않아서 JavaScript나 Python으로 ASP를 해보면 재미있지 않을까 하는 몽상을 많이 했는데, 다행히 몽상으로만 그칠 수 있었다.
TAG ASP, VBScript
Posted by wafe

TRACKBACK | http://wafe.kr/trackback/98 관련글 쓰기

댓글을 달아 주세요

2009/09/07 03:24

버려지지 않은 코드 분류없음2009/09/07 03:24

몇 년 전(Windows Vista 대응이 끝난 상태였으니 한 3년 전인가?)에 인수인계 받아서 관리하고 있는 Visual C++ 6.0 프로젝트가 있다. 계속 판매되고 있지만 안정화된지 오래되었고 신기능 추가가 없어서 사실 거의 열어 볼 일은 없는 프로젝트이다. 그런데 이번에 급하게 처리할 이슈가 생겨서 오랜만에 뒤져보고 있다.

소스 분석을 하고 있자니 한 가지 어려운 점이 있는데, 안 쓰는데 남아있는 코드가 너무 많다는 점이다. 역사가 길고 소스 코드 버전 관리 도구를 도입하기 전에 작성된 코드가 많아서인지, 원래 개발하시던 분의 습관인지는 모르겠으나 아무튼 무진장 안 쓰는게 많다. 살아있는데 안 쓰이는 것만큼 주석 처리되어 있는 부분도 많아서, 다 포함해서 라인 수를 세니 20만 라인이 넘는데... 이 중에 쓰이는 게 얼마나 되려나.

상관없는데 남아 있는 코드는 후에 읽을 사람에게 방해만 되니 깨끗히 정리하라는 얘기를 어디서 들었더라... 분석하는 데 정말 방해된다. 잘 치우자.

이런 코드 뭉치를 보고 있자니 문득 전에 읽었던 '아무것도 못 버리는 사람'이라는 책이 생각났다. 이 책 보고 나서 수 년간 끌어안고 있던 잡동사니들을 참 많이 정리했다. 무슨 물건이든 '나중에 쓸 일이 있겠지... 모아 놓으면 재미있겠지...'하는 생각이 가장 먼저드는 성격이다보니 물건을 잘 안 버리는 건 여전하다. 실제 세상의 물건들도 소스처럼 리비전 관리가 되어서 버리더라도 나중에 생각날 때 다시 불러올 수 있으면 좋을텐데.

어쨌거나 소스는 지워도 리비전 히스토리가 남으니 필요 없어지면 바로 정리하자.

ps. Coding: Unused code: 사람 사는 세상이 거기서 거기 :)
TAG coding
Posted by wafe

TRACKBACK | http://wafe.kr/trackback/97 관련글 쓰기

댓글을 달아 주세요

  1. 최재훈 2009/09/07 16:39  댓글주소  수정/삭제  댓글쓰기

    동감입니다. 주석으로 지울 바엔 그냥 삭제하는 편이 낫습니다.

  2. wafe 2009/09/17 17:47  댓글주소  수정/삭제  댓글쓰기

    오늘 주석화된 코드 3천 라인을 제거했습니다.

2009/09/06 11:39

신입사원들과 함께한 TDD 토론 분류없음2009/09/06 11:39

김창준 님강규영 님께서 예전에(켄트 벡의 TDD 책이 번역되어 나오기 전) 만드신 TDD 강좌 동영상을 신입 사원들과 같이 보는 스터디가 회사에서 있었는데, 지난 주에 스터디 정리 미팅이 있어서 참석했다. 요즘 너무 정신없는 터라 글을 한 번 써보자고 하고는 벌써 일주일이 지났네. 나는 스터디에는 참가하지 못하고 정리 미팅에만 참석했지만 참 의미있는 미팅이었다고 생각한다.

신입사원들이지만 참여하는 프로젝트 성격상 유닛테스트와 약간의 TDD 경험이 있는 사람도 있고 아예 유닛 테스트에 대한 경험조차 없는 사람도 있었다. 아예 경험이 없는 사람인 경우에는 역시나 유닛 테스트나 TDD에 대해서 제대로 파악하지 못했음을 알 수 있었다.

유닛 테스트에 대해서도 모르는데 TDD와 동시에 접하게 되면 완전히 혼란스러운 상황에 처하게 되는 것 같다. TDD의 장점으로 쉽게 얘기할 수 있는 리팩토링 시의 안전망 역할은 사실 유닛 테스트의 장점인데 구분을 못한다든가 하는 것이다.

당연한 일이라고 생각한다. 나도 유닛 테스트라는 개념보다 TDD라는 개념을 먼저 접했다. TDD 책을 처음 읽고 나서 도대체 이게 뭘 어쩌라는 건가 했던 감정이 기억난다. 테스트를 작성한다는 건 뭐고 녹색 막대는 또 뭐고... 그래서 책을 다시 읽으면서 책에 나온 예제를 모두 따라해보고, TDD에 관한 글을 마구 구글링했었다.

그런 의미에서 정리 미팅의 질문 리스트에 포함되었 있던 "유닛 테스팅을 잘 하고 있는 상황을 가정한다면, 거기에 TDD를 더 하면 어떤 효과가 있는가?"하는 질문이 진짜 TDD의 장점에 대해서 묻고 있는 질문이라고 생각한다.

TDD는 유닛 테스트를 좀 더 의미있게 할 수 있는 동기를 제공한다는 점에 의미가 있다는 것이 내가 생각할 수 있는 대답이었다. 유닛 테스트를 먼저 생각하고 작성하게 되므로, 나중에 작성할 때보다 테스트 코드 작성에 대한 저항감이 적다. 버그 수정 시에는 특히 유닛 테스트 코드를 작성하는 일을 잊기 쉬운데, 버그 수정 시에도 버그 상황을 재현하는 테스트 코드를 먼저 추가하려는 생각을 갖게 되어 유닛 테스트 커버리지 유지에 도움이 된다.

좀 궁색한 답변이긴 하다. 질문에서 이미 "유닛 테스팅을 잘 하고 있는 상황"을 가정하고 있는데 나는 "TDD 없이 그게 잘 될리가 없고, TDD가 잘 할 수 있게 도와준다"라고 대답한 셈이기 때문이다.

TDD의 장점에 대해서 구글링을 해보면 좀 더 경험적인 장점들에 대해서 많이 얘기하고 있는데, 아직 경험이 짧아 내가 직접 느낀 장점이라고 할 만한건 이정도 뿐인 것 같다.
TAG TDD, Unit Test
Posted by wafe

TRACKBACK | http://wafe.kr/trackback/96 관련글 쓰기

댓글을 달아 주세요

  1. ntrolls 2009/09/08 06:04  댓글주소  수정/삭제  댓글쓰기

    별 상관없는 이야기이긴 한데;;;

    http://research.microsoft.com/en-us/projects/Pex/

    .Net 유닛테스팅 자동생성 툴. 우리 랩 친구도 잠깐 참여했던 프로젝트이니 잘 되나 한 번 구경해보시라 :)

    • wafe 2009/09/10 01:39  댓글주소  수정/삭제

      마소 잡지에서 보고 관련이 있으실 거 같다는 생각이 들었는데 역시나 였군요 :) 이런게 가능하다니 마치 다른 세상의 얘기인 거 같다는 생각이 ㅎㅎ

    • ntrolls 2009/09/21 18:59  댓글주소  수정/삭제

      뭘... 속을 들여다보고 나면 다 그냥 그런 거라오 흐흐.

  2. Mini 2009/09/08 14:47  댓글주소  수정/삭제  댓글쓰기

    TDD 가 unittest 의 형태로 드러나긴 하지만, 생각과 design 을 도와주는 도구로서도 작동하는 것 같습니다. 창준님께서는 TDD 를 시작하기전에 essense 가 뭘까를 생각하고 시작을 하면 NOO 적인(살아있는, 세포가 분영하는 듯한) TDD 를 할 수 있다고 하더군요. 저도 요즘 그런 훈련을 많이 하고 있구요.

    • wafe 2009/09/10 01:43  댓글주소  수정/삭제

      에센스라고 하시니 클래스 설계 시의 응집성 결합성 같은 개념이 떠오르네요. 클래스의 책임을 명확히 하지 않으면 클래스도 커지고 덩달아 테스트 코드는 기하 급수적으로 커진다는 측면에서 나쁜 냄새를 빨리 맡을 수 있는 효과도 기대할 수 있다는 생각이 문득 듭니다.

      NOO에 대해서 많이 접하지를 못해서 에센스를 이런 식으로 연결시켜도 될지 모르겠네요 :)