- 창섭:PairProgramming 자체가 인상적이었습니다. 음악을 아마추어로 하는 저로써는 음악외에도 이렇게 멋지게 콤비를 결성할 수 있다는 것에 놀라울 따름입니다. ^^;; 그리고 변수명을 고치는 것 자체가 Refactoring 에 들어가고 매우 중요하다는 사실도 감명이었습니다. ^^;
그래서 PP나 XP의 과정을 Jazz에 비유하곤 합니다. 그리고 한번 유의어사전을 프로그래밍시 일주일간만 사용해 보세요. 그리고 거기서 무엇을 더 배웠는지 이야기해보면 참 좋겠네요. --김창준
- 재동:여러 사람과 처음으로 프로그래밍을 같이 하면서 커뮤니케이션이 얼마나 중요한 지를 확실히 알았습니다. 이제부터는 '말 많은' 프로그래머가 되어야 겠습니다
오늘 세미나 정말 수고하셨습니다
- neocoin : UnitTest에서 추구한 프로그램의 설계에서 Divide해 나가는 과정은 여태 거의 디자인 타임에서 거의 수행을 했습니다. 그래서 여태 Test를 위한 코드들과 디버그용 코드들을 프로그램을 작성할때마다 그런 디자인에도 많은 시간을 소요했는데, 아예 프로그램의 출발을 Test에서 시작한다는 발상의 전환이 인상 깊었습니다. --상민
- 1002 : 어제 Test Code : Product Code 간 중복 (return 0 !) 을 OAOO로 풀어서 Refactoring 을 해야 할 상황으로 규정짓는다는 말이 뒤통수를 한대 때리는 기분이였습니다;;
- TDD를 어설프게나마 시도하면서 느낀점이 'TDD 에서의 Product Code 는 오직 테스트 까지만 만족하는 코드인가' 였었는데. 한편으로는 이렇게 해석할 수 있겠더군요. '해당 스케일에 대해 더욱더 정확하게 작동하는 프로그램을 만들고 싶다면 그만큼 테스트 코드 양을 늘려라.' 테스트코드 자체가 일종의 Quality Assurance 를 위한 도큐먼트 역할도 된다는 점을 다시 생각하게 되었습니다.
- '테스트코드의 보폭을 조절하라. 상황에 따라 성큼성큼 보폭을 늘릴수도 있지만, 상황에 따라서는 보폭을 좁혀야 한다. 처음 TDD를 하는 사람은 보폭을 좁혀서 걸어가기가 오히려 더 힘들다'
DoTheSimplestThingThatCouldPossiblyWork. 이것이 훈련이 아직 덜된, TDD를 하는 사람에게는 얼마나 힘든지는 이번 RDP 짜면서 느꼈었는데. 열심히 훈련하겠습니다.
- 아까 발표때에도 이야기했지만, Code Review 를 위한 reverse-TDD (정도로 해둘까요? 이것도 관련 문서가 있을텐데. ) 를 해보는 것도 좋을 것 같네요. 코드 분석을 위한 test-code 작성이요. 즉, 이미 만들어져있는 코드를 테스트 코드라고 상정하고, 자신이 제대로 이해했는가에 대한 검증과정을 Test-Code 로 만드는 것이죠. 시간 있었으면 오늘 마저 시도해봤을텐데, 시간에 마음 쫓긴게 아쉽네요.
- Refactoring 책에서는 Refactor As You Do Code Review 에 Code Review 를 위한 Refactoring을 이야기 하는데, Refactoring 을 위해서는 기본적으로 Test Code 가 필요하다고 할때 여기에 Test Code를 붙일테니까 상통하는 면이 있긴 하겠군요.
- Refactoring 책에서는 Refactor As You Do Code Review 에 Code Review 를 위한 Refactoring을 이야기 하는데, Refactoring 을 위해서는 기본적으로 Test Code 가 필요하다고 할때 여기에 Test Code를 붙일테니까 상통하는 면이 있긴 하겠군요.
- TDD를 어설프게나마 시도하면서 느낀점이 'TDD 에서의 Product Code 는 오직 테스트 까지만 만족하는 코드인가' 였었는데. 한편으로는 이렇게 해석할 수 있겠더군요. '해당 스케일에 대해 더욱더 정확하게 작동하는 프로그램을 만들고 싶다면 그만큼 테스트 코드 양을 늘려라.' 테스트코드 자체가 일종의 Quality Assurance 를 위한 도큐먼트 역할도 된다는 점을 다시 생각하게 되었습니다.
- nautes : 참관자로서 있었는데 .. 대부분의 시간을 카메라 찍느라고 여념이 없었지만, 이 자리를 빌어서 반강제적으로 촬영에 협조해주신 분들께 감사와 사죄를 ..
- 흥미로운 것은 시끄러운 프로그래밍이였다는 것이였습니다. 혼자서 하는 프로그래밍(PairProgramming을 알고나니 새로운 개념이 생기는군요. 원래 Programming이라는 것은 혼자하는 거였는데, 이제 프로그래밍하면 pair인지 single인지 구분을 해주어야겠군요)을 하는 경우에는 팀원들이 소란스럽게 떠들면 아 지금 설계하고 있구나하고 생각하고, 조용해지면 아 지금 코딩하고 있구나..하는 생각이 들었는데, PP는 끝까지 시끄럽게 하는거라는 느낌이 들더군요. 그렇게 대화가 많아지는 것은 코딩에 대한 이해도의 증가와 서로간의 협력 등 많은 상승효과를 가져올 수 있다는 생각을 했습니다.
- 그리고 관찰하던 중 PairProgramming에서 Leading에 관한 사항을 언급하고 싶습입니다. 사용하는 언어와 도구에 대한 이해는 확실하다는 전제하에서는 서로가 Pair에 대한 배려가 있으면 좀더 효율을 낼 수 있을꺼라 생각합니다. 배려라는 것은 자신의 상대가 좀 적극적이지 못하다면 더 적극적인 활동을 이끌어 내려는 노력을 기울어야 할 것 같습니다. 실습을 하던 두팀에서 제 느낌에 지도형식으로 이끄는 팀과 PP를 하고 있다는 생각이 드는 팀이 있었는데. 지도형식으로 이끄는 팀은 한 명이 너무 주도적으로 이끌다 보니 다른 pair들은 주의가 집중되지 못하는 모습을 보인 반면, PP를 수행하고 있는 듯한 팀은 두 명 모두 집중도가 매우 훌륭한 것 같아서 이런 것이 정말 장점이 아닌가 하는 생각이 들었습니다. 결국 PP라는 것도 혼자가 아닌 둘이다 보니 프로그래밍 실력 못지 않게 개인의 사회성이 얼마나 뛰어냐는 점도 중요한 점으로 작용한다는 생각을 했습니다. (제가 서로 프로그래밍중에 촬영을 한 것은 PP를 전혀 모르는 사람들에게 이런 형식으로 하는 것이 PP라는 것을 보여주고 싶어서였습니다. 촬영이 너무 오래 비추었는지 .. 죄송합니다.)
- 흥미로운 것은 시끄러운 프로그래밍이였다는 것이였습니다. 혼자서 하는 프로그래밍(PairProgramming을 알고나니 새로운 개념이 생기는군요. 원래 Programming이라는 것은 혼자하는 거였는데, 이제 프로그래밍하면 pair인지 single인지 구분을 해주어야겠군요)을 하는 경우에는 팀원들이 소란스럽게 떠들면 아 지금 설계하고 있구나하고 생각하고, 조용해지면 아 지금 코딩하고 있구나..하는 생각이 들었는데, PP는 끝까지 시끄럽게 하는거라는 느낌이 들더군요. 그렇게 대화가 많아지는 것은 코딩에 대한 이해도의 증가와 서로간의 협력 등 많은 상승효과를 가져올 수 있다는 생각을 했습니다.
- 안녕하세요? 참관자였던 사람입니다. Feedback이 좀 늦었네요. 색다른 경험이었던것 확실했는데, 다만 시간이 한시간 정도만 길었더라면, 훨씬더 많은건 느꼈을것 같아서 아쉽습니다. TDD나 CRC카드 둘다 접하기엔 좀 짧은 시간이었던것 같습니다. 앞으로도 이런기회가 많았으면 좋겠네요. 그럼 이만... --김정준
