최근 프로젝트가 빠듯한 편은 아니라 여유가 있습니다. 다만 저 같은 경우는 해당날짜에 끝내야될 일이 있어서 일과중에는 꽤 바쁘게 자바 소스를 돌리고 있습니다. 저번주 말부터 진득하게 일과시간 프로그래밍을 하면서 몇가지 느낀바가 있었습니다. 예전에 제가 환상을 가졌던 Extreme Programming에 비교하여 한번 그 생각을 정리해 봤습니다.
주 48시간 근무? 제가 Extreme Programming(이하 XP)에 환상을 가진 이유는 XP 규칙중에 주 48시간 근무를 지켜라~ 라는 규칙이 있기 때문이었어요. 아름다운 규칙입니다. XP에서는 이 규칙을 통해 ‘진정한 생산성’ 이 무엇인지 알려주고 있습니다. 야근이 일상화 된 곳에서는 크게 바쁘지 않는 이상 어차피 야근할 것 일과시간에는 예를들면 인터넷 뉴스 보면서 이명박 정부 욕하며 천천히 일할것이고, 주어진 일을 빨리 완수할 수 있다 하더라도 일 끝내면 위에서 또 일거리 던져줄까봐 밤늦게까지 일부러 천천히 일하는 분위기는 야근이 일상화된 곳에서 종종 벌어지는 일입니다. (우리 회사는 이런 분위기가 아니라서 좋습니다~!) 주48시간 근무를 우리나라 현장에 적용하면 꼭 주48시간 근무를 지켜라~ 보다는 일과시간에 집중해서 일하고 되도록 업무에 피로와 지장을 주는 야근은 피하자~ 가 될 것 같습니다.
요즘 저는 고객 담당자와 직접 대면하는 파견지에 나왔고, 중요한 일을 해서 그런지 긴장감이 듭니다. 이 일은 이번주내로 끝내야 합니다. 그런데 일과 후에는 개인적인 부상 치료로 꼭 퇴근을 하는 상황에 있습니다. 그래서 일과 시간에는 딴 생각 하지 않고 저절로 일에 집중이 되는 것을 경험하고 있습니다.
지금이 아니라 다른때라도 '일과시간에 긴장감을 가지고 일하면서, 시간 제한을 두고 일과시간까지 꼭 끝내자~' 라고 다짐하면 주48시간 근무의 진정한 뜻을 비스무리~ 하게 실천할 수 있을 것입니다. 꼭 주48시간 보다는 그 속에 담긴 뜻을 실천해야 겠습니다. 그러나 언제나 말은 쉽고 실천은 어렵습니다.
TDD(Test Driven Development = 테스트 주도 개발) 흉내내기? 말 그대로 진짜 TDD가 아니라 흉내내기 입니다. 이번에 제가 맡은 모듈을 만지면서 상당히 중요하면서도 은근히 까다로운 로직처리를 해야 되는 부분이 새로 생겼습니다. 예를 들어 >, >= 이런 사소한 부등호만 실수해도 모듈 전체가 망가지는 민감한 부분이었습니다. 이런 민감한 로직이야말로 TDD로 천천히 정밀하게 로직을 만들어나가면 좋은 상황이었습니다.
그러나 제가 아는 TDD는(내가 정말 TDD를 해본건지 확실히 모르겠습니다. 왜냐면 독학했기 때문이죠.) 안정감있게 개발은 가능해도 개발 속도는 느렸다는 경험이 있었습니다.
지금 상황은 빨리 개발해야 했습니다. 그래서 '빨리 개발하자~'와 '정확하게 개발하자~'의 가운데 균형을 찾아서 일단 로직부터 빨리 만들고, 로직을 검증하는 테스트 코드를 대충 만들어서 검증한 다음에, 나중에 시간날 때 테스트 코드를 정밀하게 다듬는 식으로 개발을 진행했습니다.
어떤 소스는 굳이 테스트 코드를 만들지 못하기도 했는데 그렇더라도 이 로직은 이런저런 테스트 코드들이 필요하겠구나~ 라는 머릿속으로 가상으로 TDD한다는 생각을 가지고 개발을 했습니다.
제가 말하고 싶은 것은 꼭 반듯하게 벽돌 쌓듯이 정확하게 테스트 코드 만들고 프로그램 짜는 식의 TDD를 하지 못하더라도 머릿속에 가상으로 TDD 중심적으로 생각하며 프로그램을 짠다면 그래도 튼튼한 개발을 하는데 그냥 개발하는 것 보다는 도움이 되는 것 같다는 것을 이번에 경험했습니다.
출근을 위해 아침 6시에 꼭 일어나야겠다~ 라고 다짐하면 대부분 그 시간대에 일어날 수 있는 이유는 아침 6시라는 생각의 끈을 놓지 않고 잠을 자기 때문일 것입니다. 프로그래밍도 TDD 중심으로 개발하겠다는 생각의 끈을 놓지 않는다면 꼭 정확하게 TDD를 하지 않더라도 TDD의 효과를 볼 수 있지 않을까라는 생각을 해보았습니다.
> IBM developerWorks
Extreme Programming : 돌아온 "XP distilled", Part 1
Extreme Programming : "XP distilled", Part 2
Extreme Programming : Test-driven 프로그래밍
Extreme Programming : 다르게 생각하기
> 산골 블로그 developerWorks
2008/04/03 - [프로그래머/IBM developerWorks] - 개발자와 프로그래밍의 가치을 높여주는 JUnit
2008/03/09 - [프로그래머/IBM developerWorks] - 사람(개발자)을 위한 자동화 기술에 눈을 뜨다.
2008/04/09 - [프로그래머/칼럼 쓰기] - 에러 잡는 마음가짐
주 48시간 근무? 제가 Extreme Programming(이하 XP)에 환상을 가진 이유는 XP 규칙중에 주 48시간 근무를 지켜라~ 라는 규칙이 있기 때문이었어요. 아름다운 규칙입니다. XP에서는 이 규칙을 통해 ‘진정한 생산성’ 이 무엇인지 알려주고 있습니다. 야근이 일상화 된 곳에서는 크게 바쁘지 않는 이상 어차피 야근할 것 일과시간에는 예를들면 인터넷 뉴스 보면서 이명박 정부 욕하며 천천히 일할것이고, 주어진 일을 빨리 완수할 수 있다 하더라도 일 끝내면 위에서 또 일거리 던져줄까봐 밤늦게까지 일부러 천천히 일하는 분위기는 야근이 일상화된 곳에서 종종 벌어지는 일입니다. (우리 회사는 이런 분위기가 아니라서 좋습니다~!) 주48시간 근무를 우리나라 현장에 적용하면 꼭 주48시간 근무를 지켜라~ 보다는 일과시간에 집중해서 일하고 되도록 업무에 피로와 지장을 주는 야근은 피하자~ 가 될 것 같습니다.
요즘 저는 고객 담당자와 직접 대면하는 파견지에 나왔고, 중요한 일을 해서 그런지 긴장감이 듭니다. 이 일은 이번주내로 끝내야 합니다. 그런데 일과 후에는 개인적인 부상 치료로 꼭 퇴근을 하는 상황에 있습니다. 그래서 일과 시간에는 딴 생각 하지 않고 저절로 일에 집중이 되는 것을 경험하고 있습니다.
지금이 아니라 다른때라도 '일과시간에 긴장감을 가지고 일하면서, 시간 제한을 두고 일과시간까지 꼭 끝내자~' 라고 다짐하면 주48시간 근무의 진정한 뜻을 비스무리~ 하게 실천할 수 있을 것입니다. 꼭 주48시간 보다는 그 속에 담긴 뜻을 실천해야 겠습니다. 그러나 언제나 말은 쉽고 실천은 어렵습니다.
TDD(Test Driven Development = 테스트 주도 개발) 흉내내기? 말 그대로 진짜 TDD가 아니라 흉내내기 입니다. 이번에 제가 맡은 모듈을 만지면서 상당히 중요하면서도 은근히 까다로운 로직처리를 해야 되는 부분이 새로 생겼습니다. 예를 들어 >, >= 이런 사소한 부등호만 실수해도 모듈 전체가 망가지는 민감한 부분이었습니다. 이런 민감한 로직이야말로 TDD로 천천히 정밀하게 로직을 만들어나가면 좋은 상황이었습니다.
그러나 제가 아는 TDD는(내가 정말 TDD를 해본건지 확실히 모르겠습니다. 왜냐면 독학했기 때문이죠.) 안정감있게 개발은 가능해도 개발 속도는 느렸다는 경험이 있었습니다.
지금 상황은 빨리 개발해야 했습니다. 그래서 '빨리 개발하자~'와 '정확하게 개발하자~'의 가운데 균형을 찾아서 일단 로직부터 빨리 만들고, 로직을 검증하는 테스트 코드를 대충 만들어서 검증한 다음에, 나중에 시간날 때 테스트 코드를 정밀하게 다듬는 식으로 개발을 진행했습니다.
어떤 소스는 굳이 테스트 코드를 만들지 못하기도 했는데 그렇더라도 이 로직은 이런저런 테스트 코드들이 필요하겠구나~ 라는 머릿속으로 가상으로 TDD한다는 생각을 가지고 개발을 했습니다.
제가 말하고 싶은 것은 꼭 반듯하게 벽돌 쌓듯이 정확하게 테스트 코드 만들고 프로그램 짜는 식의 TDD를 하지 못하더라도 머릿속에 가상으로 TDD 중심적으로 생각하며 프로그램을 짠다면 그래도 튼튼한 개발을 하는데 그냥 개발하는 것 보다는 도움이 되는 것 같다는 것을 이번에 경험했습니다.
출근을 위해 아침 6시에 꼭 일어나야겠다~ 라고 다짐하면 대부분 그 시간대에 일어날 수 있는 이유는 아침 6시라는 생각의 끈을 놓지 않고 잠을 자기 때문일 것입니다. 프로그래밍도 TDD 중심으로 개발하겠다는 생각의 끈을 놓지 않는다면 꼭 정확하게 TDD를 하지 않더라도 TDD의 효과를 볼 수 있지 않을까라는 생각을 해보았습니다.
> IBM developerWorks
Extreme Programming : 돌아온 "XP distilled", Part 1
Extreme Programming : "XP distilled", Part 2
Extreme Programming : Test-driven 프로그래밍
Extreme Programming : 다르게 생각하기
> 산골 블로그 developerWorks
2008/04/03 - [프로그래머/IBM developerWorks] - 개발자와 프로그래밍의 가치을 높여주는 JUnit
2008/03/09 - [프로그래머/IBM developerWorks] - 사람(개발자)을 위한 자동화 기술에 눈을 뜨다.
2008/04/09 - [프로그래머/칼럼 쓰기] - 에러 잡는 마음가짐