Project Zephyrus/Client Journey

• 작업상황이 막바지인것을 실감할 거 같다. 엄청나게 길어진 코드를 보면 알 수 있다. 내가 없는 사이에 엄청나게 많은 변화가 있었다. 주석이 없는 코드라서 그런지 해석하는 데 애먹었다. 이궁...CVS 사용을 며칠 안해봤다고 또 잊어먹었다. 바부..도움말 뒤지는 중이다. 아마 이번 프로젝트에서 내가 가장 크게 느끼는 것은 영서와 비슷할 것 같다. 자바 언어에 대한 공부보다는 프로젝트 진행 방법, 팀프로젝트에서 개인과 팀의 역할 등을 가장 크게 배우는 것 같다. 예전에 친구와 함께 뭐 하나 하다가 어설프게 끝난 적이 있는데 아마 내가 그만큼 어설프게 진행했던 것 같다. 아무튼 이번에 가장 크게 느낀 점이다. 또 하나 느낀점이 있다면 형하고 pair 하려면 이정도로 공부하고 노력해서는 부족할 것 같다는 생각이다. 아직 내가 갈 길은 멀었다는 생각이... -_-;; 이번에 확실히 늘어난 실력은 아마도 소켓의 개념이 아닐까...-_-;;
  

프로그램내에서의주석

• 일이 거의 막마지에 다다른다. 12시 이후 본격적 작업. 이틀간의 스케줄에서 둘이 참여를 하지 않았으므로, 작업은 주로 코드 설명이 주가 될 수 밖에 없었다. Pair로 Refactoring 해나가며 설명하기에 내가 너무 많이 코드를 고쳤나. -_-; (나도 할말있는것이, 가장 중요사항중 하나인 패킷 핸들러 처리부분할때 다들빠지냐는것이다. -_-; 제일 얻을 것도 많은 부분일건데 쩝. 개인적으로 만들면서 흐뭇(^^;) 했던 부분이고;)
  
  
• 소프트웨어 개발이 공장스타일이 될 수 없는 이유를 하나 든다고 한다면 개발중 개발자가 계속 학습을 해나간다는 점에 있지 않을까 한다. 처음부터 끝까지 모든 것을 다 예상하고 개발할 수 는 없을것이니. (필요한 라이브러리가 무엇인지, 실제 그 라이브러리의 장단점이 무엇인지, 어떻게 사용하면 바로 알수 없는 버그가 되어버리는지 등등. 뭐 큰 소프트웨어일 경우 이것을 다 예측해야 한다라고 하면 할말없지만. 이것도 비용을 고려해서 처신해야하겠지. Cost Estimate 자체가 Cost 가 드는것일거니.) 암튼 아쉬운건 중간에 디자인이 바뀌었을때 (실제로 처음 디자인의 클래스들을 몇개 뺀것도 있고, 인터페이스만 맞춰본 것들도 있고 그러함) 바쁜 사람들이 참석을 하지 못해서 처음부터 설명해야 하는 경우이다.
  
  • 학교에서의 작업의 단점중 하나는 고정된 장소와 고정된 스케줄을 만들기가 쉽지 않다는 점이다. 학교시간표 보고 빈 시간대를 맞춰야 하고, 그 사람은 또 그 사람 나름대로의 스케줄이 따로 존재한다. 시험이라던지, 동아리 활동이라던지 등등. 이 경우 팀원별 스케줄을 보고 팀내 기여도를 예상한다음 그 기여도를 줄여주도록 해야 서로가 부담이 적을 것이다. 단, 위에서 언급한대로 개발중 지속적인 학습과정이 있는 이상, 중간 참여는 그만큼 어렵게 된다. CVS가 있을 경우 해당 코드의 변화를 지속적으로 관찰해나가야 하며, 외부에 있는 사람은 내부 작업자에게 필요에 따라 해당 문서를 요구해야 한다. (내부 작업자가 어떤 욕을 하건 -_-; 나중에 다시 참여시의 리스크를 줄이려면) 내부 작업자는 그 변화과정을 계속 기록을 남겨야 할 것이다. (Configuration Management 가 되겠지.)
    
    
• 이전에 InformationRadiator 를 붙일 수 있는 벽과 화이트보드가 그립다; 방학중엔 피시실 문짝에라도 붙여보던지 궁리를;
  
  
• 팀내 기여도에 대해서는 여러가지를 생각해야 할것 같긴 한데, 이것은 개인의 목적과 팀의 목적과 결부지어서 생각해봐야 할것도 같다. 개인의 목적과 팀의 목적이 일치할때 그 사람은 자신의 기여도를 높이려고 할 것이다 (이것은 자신의 이익과 일치하는 것일테니).
  
  • 이번 프로젝트의 목적은 Java Study + Team Project 경험이라고 보아야 할 것이다. 아쉽게도 처음에 공부할 것을 목적으로 이 팀을 제안한 사람들은 자신의 목적과 팀의 목적을 일치시키지 못했고, 이는 개인의 스케줄관리의 우선순위 정의 실패 (라고 생각한다. 팀 입장에선. 개인의 경우야 우선순위들이 다를테니 할말없지만, 그로 인한 손실에 대해서 아쉬워할정도라면 개인의 실패와도 연결을 시켜야겠지)로 이어졌다고 본다. (왜 초반 제안자들보다 후반 참여자들이 더 열심히 뛰었을까) 한편, 선배의 입장으로선 팀의 목적인 개개인의 실력향상부분을 간과하고 혼자서 너무 많이 진행했다는 점에선 또 개인의 목적과 팀의 목적의 불일치로서 이 또한 실패이다. 완성된 프로그램만이 중요한건 아닐것이다. (하지만, 나의 경우 Java Study 와 Team Project 경험 향상도 내 목적중 하나가 되므로, 내 기여도를 올리는 것은 나에게 이익이다. Team Project 경험을 위해 PairProgramming를 했고, 대화를 위한 모델링을 했으며, CVS에 commit 을 했고, 중간에 바쁜 사람들의 스케줄을 뺐다.) 암튼, 스스로 한 만큼 얻어간다. Good Pattern 이건 Anti Pattern 이건.
    
    
• 암튼. 이렇게 해봤으니, 앞으로는 더 잘할수 있도록, 더욱더 잘할수 있도록. DoItAgainToLearn 했으면 한다. 앞으로 더 궁리해봐야 할 일들이겠지. -- 석천
  
  

• 움.. 아무래도 난 말빨 글빨 다 딸리는거같다.. 위에글처럼 멋있게 쓰고싶은데, 그냥 내식대로 써야겠다.. 간만에 내가 또 형보다 일찍왔다. 이틀동안 빠진게 타격이 너무 컸나보다.. MainSource에 새로 추가된 파일도 꽤되고 기존파일도 업데이트된 내용이 많아서 이해가 아니라 읽어보는것만해도 엄청난 시간이 들었다.. --;; 정통부 회의겸 기짱턱땜에 일찍갔는데 아무래도 금요일로 완료가 된 모양이다.. 이번이 나로선 거의 처음 해본 프로젝트였는데, 내가 별로 한건없지만, 솔직히 뭔가 만든것보단 배운게 더 많은거같다.. 하긴 프로젝트를 해본다는거 자체가 배운다는거였으니깐.. 꼭 자바에 대해서 배운것보다도 Design이라던지 Architecture(맞나?) 같은것에 대해서도 배웠고.. 프로젝트란 이렇게 진행해야 하는거구나라는것도 느꼈다. 뭔가 많이 쓰고싶은데 머리속이 정리가 안된다.. 이럴때 정말~~ ㅠ.ㅠ 아우~ 나중에 더 써야겠다..
  
  • (나중) 형의 말대로 아쉽다는 생각이 든걸로 봐서는 실패란 생각이 들긴한다.. 그래도 프로젝트를 하면서 여러사람들과 머리를 맞대본것만으로도 오랜 어두운 동굴에서 빛을 찾은것처럼 느껴진다.. 다른사람이 모라 할지라도 그것만으로도 나에겐 이번 프로젝트가 나름대로 큰 성공이라고 생각한다.. 근데 아직 메신저를 못실행시켜봤다.. 어떻게 해야되는지 모르겠다.. --;; 서버쪽을 안읽어봐서 그런가.. 이거 쓰고 한번 돌려봐야겠다.. 별로 한건 없지만, 아니다 나도 엄청난 역할을 했기에 돌려보면 너무 기쁠꺼같다..
    100% 실패와 100% 성공 둘로 나누고 싶지 않다. Output 이 어느정도 나왔다는 점에서는 성공 70-80% 겠고, 그대신 프로젝트의 목적인 Java Study 와 성공적인 Team Play 의 운용을 생각해봤을때는 성공 40-50% 정도 라는 것이지. 성공했다고 생각한 점에 대해서는 (이 또한 개인의 성공과 팀의 성공으로 나누어서 생각해봤으면 한다.) 그 강점을 발견해야 하겠고, 실패했다고 생각한 점에 대해선 보완할 방법을 생각해야 겠지. --석천
    
    

• 1002 혼자서 작업. 집에서 작업해서 그런지 중간에 다른 일을 좀 많이 했다. (애니보고 축구보고. -_-;) 장소가 주는 장단점이 확실히 존재한다. 아무리 집의 컴퓨터가 나에게 셋팅이 맞춰져있다고 하더라도, 집에는 너무 유혹거리가 많다.)
  
• 중간 중간 테스트를 위해 서버쪽 소스를 다운받았다. 상민이가 준비를 철저하게 한 것이 확실히 느껴지는 건 빌드용/실행용 배치화일, 도큐먼트에 있다. 배치화일은 실행한번만 해주면 서버쪽 컴파일을 알아서 해주고 한번에 실행할 수 있다. (실행을 위한 Interface 메소드를 정의해놓은것이나 다름없군.) 어떤 소스에서든지 Javadoc 이 다 달려있다. (Coding Standard로 결정한 사항이긴 하지만, 개인적으로 코드의 Javadoc 이 많이 달려있는걸 싫어하긴 하지만; 코드 읽는데 방해되어서; 하지만 javadoc generator 로 document 만들고 나면 그 이야기가 달라지긴 하다.)
  
• TDD 가 아니였다는 점은 추후 모듈간 Interface 를 결정할때 골치가 아파진다. 중간코드에 적용하기 뭐해서 궁여지책으로 Main 함수를 hard coding 한뒤 Refactoring 을 하는 스타일로 하긴 하지만, TDD 만큼 Interface가 깔끔하게 나오질 않는다고 생각. 차라리 조금씩이라도 UnitTest 코드를 붙이는게 나을것 같긴 하다. 하지만, 마감이 2일인 관계로. 스펙 완료뒤 고려하던지, 아니면 처음부터 TDD를 염두해두고 하던지. 중요한건 모듈자체보다 모듈을 이용하는 Client 의 관점이다.
  
  
  

• 내가 지난번과 같이 5분 Pair를 원해서 이번에도 5분Play를 했다.. 역시 능률적이다.. 형과 나 둘다 스팀팩먹인 마린같았다.. --;; 단번에 1:1 Dialog창 완성!! 근데 한가지 처리(Focus 관련)를 제대로 못한게 아쉽다.. 레퍼런스를 수없이 뒤져봐도 결국 자바스터디까지 가봤어도 못했다.. 왜 남들은 다 된다고 하는데 이것만 안되는지 모르겠다.. 신피 컴터가 구려서그런거같다.. 어서 1.7G로 바꿔야한다. 오늘 들은 충격적인 말은 창섭이가 주점관계로 거의 못할꺼같다는말이었다.. 그얘긴 소켓을 나도 해야된다는 말인데.... 나에게 더 많은 공부를 하게 해준 창섭이가 정말 고맙다.. 정말 고마워서 눈물이 날지경이다.. ㅠ.ㅠ 덕분에 소켓까지 열심히 해야된다.. 밥먹고와서 한 네트워크부분은 그냥 고개만 끄덕였지 이해가 안갔다.. 그놈에 Try Catch는 맨날 쓴다.. 기본기가 안되있어 할때마다 관련된것만 보니 미치겠다.. 역시 기본기가 충실해야된다. 어서 책을 봐야겠다.. 아웅~ 그럼 인제 클라이언트는 내가 완성하는것인가~~ -_-V (1002형을 Adviser라고 생각할때... ㅡ_ㅡ;;) 암튼 빨리 완성해서 시험해보고싶다.. 3일껀 내가 젤먼저썼다.. 다시한번 -_-V - 영서
  어차피 창섭이가 주점이 아니라 하더라도 자네는 소켓을 공부해야 했을걸. -_-v (왜냐. 중간에 창섭이랑 너랑 Pair 할것이였으니까. 창섭이도 Swing 관련 공부를 해둬야 하긴 마찬가지) 참, 그리고 해당 코드대비 완성시간은 반드시 체크하도록. 참고로 1:1 Dialog 는 1시간 10분정도 이용했음. --석천
  
  

• PairProgramming 을 할때 가장 답답해지는 상황은 잘 이해 안가면서 넋놓고 있을때랑, 둘이 같이 있어도 Solo Programming 하느 사람 마냥 혼자서 문제를 끙끙거리며 풀려고 하는 모습이다. 꼭 문제를 스스로 삽질해서 풀어야만 자기실력이 향상되는것일까? 다른 사람에게 올바른 질문을 할 수 없는 사람은 혼자서 문제 푸는데에도 오래걸리게 된다고 생각한다. 상대방에게 질문을 하면서 자신이 모르는 것 자체를 구체화하고 (문제 자체가 모호한상태 자체가 문제다. 무엇이 문제인지, 자신이 모르는 것이 구체적으로 무엇인지 모르면서 어떻게 문제를 해결할까? 자신이 모르는게 버클리소켓 전체 사용과정인지 소켓 API의 인자들을 모르면서 네트웍 프로그래밍을 할 수 있을까. 그런사람들에게 '지금 모르겠는게 뭐지?' 라고 물으면 80-90%는 '다 몰라요' 이다. 모르겠는 부분에 대해서 하나하나 구체화시켜나가라. 구체화시킨 예로서 생각을 해봐도 좋을것이다. 시나리오를 만들어보면서, 그림을 그려보면서, 아니면 자기 자신이 그 시스템의 일부가 되어 보면서.) 다른 사람의 아이디어를 자신의 사고에 붙여나가면서 '더 좋은 방법' 을생각해낼 수는 없을까? 언제나 문제의 답을 내는 방법은 '이사람의 방식' 아니면 '저사람의 방식' 뿐일까.
  
  
• PairProgramming 의 교대시간을 5분으로 해봤다. 한 사람이 5분동안 해당 부분을 플밍하다가 다 못짜면 다음사람이 다시 5분의 시간을 가지고 이어서 짜고 하며 교대로 프로그래밍을 이어나가는 (마치 릴레이경주와도 같다) 방법이다. 사람들에게 제안했을때 그 표정들이 심상치 않다;; 그래 너희들은 실험용 모르모트다;; 흐흐.
  
  
• -_-; 느낀점이나 일정이나... 이미 씌어있는데... --;;
  
  
• 5분간격으로 Pair Programming을 했다.. 진짜 Pair를 한 기분이 든다.. Test가 아닌 Real Client UI를 만들었는데, 하다보니 Test때 한번씩 다 해본거였다.. 그런데 위와 아래에 1002형이 쓴걸 보니 얼굴이 달아오른다.. --;; 아웅.. 3일전 일을 쓰려니 너무 힘들다.. 일기를 밀려서 쓴기분이다.. 상상해서 막 쓰고싶지만 내감정에 솔직해야겠다.. 그냥 생각나는것만 써야지.. ㅡ.ㅡ++ 확실히 5분간격으로 하니 속도가 배가된 기분이다.. 마약을 한상태에서 코딩을 하는 느낌이었다.. 암튼 혼자서 하면 언제끝날지 알수없고 같이 해도 그거보단 더 걸렸을듯한데, 1시간만에 Login관련 UI를 짰다는게 나로선 신기하다.. 근데 혼자서 나중에 한 Tree만들땐 제대로 못했다.. 아직 낯선듯하다. 나에게 지금 프로젝트는 기초공사가 안된상태에서 바로 1층을 올라가는 그런거같다.. 머리속을 짜내고있는데 생각이 안난다 그만 쓰련다.. ㅡㅡ;; - 영서
  5분 플레이를 시도하려고 할때 학습과 능률 사이를 잘 저울질 할 필요가 있을듯. 생각을곱하는모임의 글에서도 그렇듯, 사람과의 의견교환과 홀로 공부하고 생각하는 것 양자간의 균형을 잡아야겠지. 하지만, 우리가 만나서 플밍할때 해당 라이브러리공부와 플밍을 둘 다 하기엔 시간이 모자르니, 학습부분은 개인적으로 어느정도 해야 겠지. (나도 JTree 보려고 Graphic Java 랑 Core Java, Professional Java 에 있는 JTree 다 읽어보고 집에서 개인적인 예제 코드 작성하고 그랬다. 그정도 했으니까 자네랑 플밍할때 레퍼런스 안뒤져보지. 뭐든지 기본 밑바탕이 되는건 학습량이라 생각. 학습량 * 효율적 방법론 = Output --석천
  
  처음에는 영서와 GUI Programming을 했다. Main Frame class 의 메뉴붙이고 리스너 연결하는 것부터 시작, 입력 다이얼로그를 노가다 코딩해서 만드는데 서로 교대해서 1시간이 걸렸다. 코딩 속도도 저번에 비해 더욱 빨랐고, 대화할때도 그 질문이 간단했다. (5분간격이니 아무리 플밍이 익숙한 사람이 진행해도 그 진행양이 많지가 않다. 그리고 자신이 그 사람의 미완성 코드를 완성해야 하기에 모르면 바로 질문을 하게 된다.)
  

(그 이후 창섭이가 와서 영서에게 JTree관련 Solo Programming 을 시켰는데, 말이 안되는 프로그래밍을 했다. -_-; 아직 영서가 Swing 에 익숙하지 않아서 그런데, 앞의 프로그램은 어떻게 만들어졌을까 의문이 들 정도였다; 아마 5분 간격 플밍시에는 서로 앞 사람 소스작성을 한 것을 기준으로 붙여나가는 방식이기에 그 흐름을 잡고 프로그래밍을 해서 Pair 가 성립이 가능했던것 같다는 생각도 해본다. 이는 처음 프로그래밍을 하는 사람과의 PairProgramming 시 궁리해봐야 할 사항인듯)

다음번에 창섭이와 Socket Programming 을 같은 방법으로 했는데, 앞에서와 같은 효과가 나오지 않았다. 중간에 왜그럴까 생각해봤더니, 아까 GUI Programming 을 하기 전에 영서와 UI Diagram 을 그렸었다. 그러므로, 전체적으로 어디까지 해야 하는지 눈으로 확실히 보이는 것이였다. 하지만, Socket Programming 때는 일종의 Library를 만드는 스타일이 되어서 창섭이가 전체적으로 무엇을 작성해야하는지 자체를 모르는 것이였다. 그래서 중반쯤에 Socket관련 구체적인 시나리오 (UserConnection Class 를 이용하는 main 의 입장과 관련하여 서버 접속 & 결과 받아오는 것에 대한 간단한 sequence 를 그렸다) 를 만들고, 진행해 나가니까 진행이 좀 더 원할했다. 시간관계상 1시간정도밖에 작업을 하지 못한게 좀 아쉽긴 하다.

영서에게 JTree 관련 프로그래밍에 대해서 설명을 했다. JTree와 관련하여 미리 공부하라고 하긴 했는데, 아직은 힘든가 보다. 오늘 작업시간이 5시 30분부터 9시 (저녁 30분가량), 약 3시간 가량이 걸렸던것으로 기억된다. 팀으로 모일 수 있는 시간이 흔하지 않으므로, 각 필요한 부분에 대한 학습과 예제 코드등의 JDK에 대한 SpikeSolution 에 대해서는 집에서 해 봐야 할 것이다. 작업 시간에 학습시간을 같이 할애 하기엔 시간이 그리 넉넉치 않다.

중반 어느정도 대부분의 목표 코드가 나와서 나머지를 채워넣는 과정에 대해서는 Solo 로 영서에게 시켰는데, 아직까진 프로그래밍에 익숙하지 않은 듯 싶다. 자꾸 해당 부분을 플밍하려는데에서 같은 부분이 구현된 소스코드가 있음에도 불구하고 자꾸 책을 찾아보려고 한다. 자신감의 차이였을까. 해당 부분에 대해 꼭 코드를 외워서 플밍하려 하지 않았으면 한다. '하려는 일' -> '각 언어별 구현 방법 순서 잡아보기' -> '구현' 의 과정을 거치거나, 해당 부분에 대해서 응용할 수 있는 이전에 만들어진 코드 (책의 코드 말고 현재 '작성된' 코드)를 들춰보고 생각해봤으면 하는 생각이 든다.

그래도 메신저리스트의 사용자 추가/삭제 부분에 대한 JTree 부분 플밍을 비슷한 수준으로 했다는 것과 CVS 에 add & commit 하는 전체 한 과정을 해본점에서 의의를 두어본다.

• PairProgramming를 하면서 SpikeSolution 으로 한번 구성했던 소스를 다시 만들어보고, 여러번 말로 설명해보고, 더 쉬운 방법으로 설명해보려고 하는 동안 알고있는것에 대해 생각이 빨리 정리된다.
  
• 다른 MFC나 wxPython 등의 다른 GUI Framework와 디자인패턴 에 익숙하면 이러한 Swing 에 익숙해지는데에도 도움이 되었다. 대부분의 GUI 에선 CompositePattern 으로 윈도우들을 구성하기에. 그리고 Java API를 공부하는 동안 IteratorPattern 이나 DecoratorPattern, MVC 등에 대해서도 이해하기 용이했다.
  DeleteMe) 참고로 자바에서는 순수한 형태의 MVC 모델을 사용하지 않습니다. 변형된 형태의 MVC 모델을 사용합니다 Introducing Swing Architecture. 이론과 실제의 차이랄까요. --이선우
  
  순수한 형태의 MVC 모델을 구경해본적이 없는 관계로;; 저에겐 추상적인 개념일 뿐인지라. 하긴 JTree 에서 TreeModel 부분과 TreeRender & UIManager 부분, JTree 부분에 연결된 리스너와 관련할때 정확히 Control 부분과 UI 부분이 따로 떨어지지 않고 경계가 좀 모호하긴 하다는. --석천
  
  

영서가 일이 있었던 관계로 창섭이와 Socket 관련 예제 플밍을 저번에 이어서 했다. 창섭이가 공부를 해왔는지 이번에는 코딩을 자기가 잡는다. 오 자신감;

간단한 에코서버 관련 프로그래밍을 하는 것인데, 일부러 할일을 주석으로 쓴 뒤, 한단계씩 넘어가는 방법을 써 보았다. TDD 까지는 아니지만, 작은 단계단계를 만들고 확인해보는 것이 더 효과적인 것 같다.

사람들 작업 시간을 맞추기가 쉽지 않은게 아쉽다. 서버/클라이언트 전체 회의를 통해 큰 그림들을 다같이 공유해야 할텐데, 시간표들이 다르니, 적절하게 머리를 쓰긴 해야겠는데 좀 힘들군; --1002

이힛.. 저번 시간에 졸려서 멍한 상태인데다가 의혈문화제 공연준비한다고 공부를 등한시한 상태였다. 친구들과 6시 영화보기로 했던 것들 취소함으로써 더더욱 나 자신이 '도대체 어떤 것이 우선일까... 지금 내가 무엇을 하는 것이 가장 현명할까..' 에 대해 고민을 하면서 반성하고 있었다. 그런 나에게 화도 안내고 차분히 설명해주는 형에게 너무 미안했다. 그래서 영화보는걸 취소했다. 내가 그 자리에서 할 수 있는 최선의 방안이었고 후회하지 않는다. 근데 남는게 별로 없었다. 멍한 상태여서..-_- 오늘은 공부를 좀 한 상태여서기 보다는 개념을 이해한 상태여서 자신이 있었다. 개념만 이해하면 나머지는 어렵지 않을 것이라는 나의 변하지 않는 생각때문에.. 이제 자바 숙제좀 하고나서 메신저 기본 틀을 짜봐야겠다. --창섭

아웅.. 오늘은 제주도록 대학교를 간 고딩때 젤 친한친구가 설로 올라와서 친구만나느라고 얼굴만 보고 나왔다.. 그나마 실력도 X같은데 공부도 안하니.. 1년반을 놀은게 수습이 안된다.. 마음가짐부터 잡아야 뭐가 될꺼같은데... 아직 솔직한 심정으로 마음가짐도 안잡힌다.. 나두 1002형께 그저 죄송스럴뿐이다. 형의 갈굼을 기쁨으로 받아들여서 마음을 다시 다잡아야겠다.. 결론은 오늘 공부 쌩깠다.. ㅠ.ㅠ 아참 형이 보라고 한거 보고자야겠다.. --영서

Client 팀은 일단 메신저와 관련한 자신들의 디자인을 설명해보는 시간을 가졌다. 사람들은 프로그래밍을 하기 전에 어떤 스타일로 구상을 하게 될까. Agile Modeling 에서 봤던가. 모델 보다는 모델링이 중요하다고 했었던 이야기. 모델링을 해 나가면서 자신의 생각을 정리하고, 프로그램을 이해해 나가는 것이 중요하기에.

1002의 경우 UML을 공부한 관계로, 좀 더 구조적으로 서술 할 수 있었던 것 같다. 설명을 위해 Conceptual Model 수준의 Class Diagram 과 Sequence, 그리고 거기에 Agile Modeling 에서 잠깐 봤었던 UI 에 따른 페이지 전환 관계에 대한 그림을 하나 더 그려서 설명했다. 하나의 프로그램에 대해 여러 각도에서 바라보는 것이 프로그램을 이해하는데 더 편했던 것 같다.

창섭이는 프로그램의 작동 원리에 대한 자세한 시나리오를 써서 설명을 했다. 영서가 '아. 머릿속으로는 대강 구상을 했는데, 잘 정리가 안돼요' 라고 했다. 머리로만 생각해본 것과 글이나 도표로 한번 정리를 해본 것의 차이가 크다는 것을 느꼈겠지.

1002는 CVS 사용방법에 대한 예를 보이고 설명을 했다. wincvs 윈도우 버전에 익숙하지 않았던 관계로 command 입력방법을 가르쳐줬다. 그리고 영서와는 주로 Swing쪽을, 창섭과는 Java Socket Class 에 익숙해지기 위해 Socket 관련 SpikeSolution 을 했다.

후배들과의 PairProgramming 이다. 여태껏의 경험에 의하면 언제나 애매한 것이 Junior : Expert 문제이다. 이번에는 어차피 SpikeSolution 이므로, 내가 아는 한도에서 약간의 예를 보이고, 후배들로 하여금 해보도록 하는 식으로 했는데, 그 덕에 둘이 Pair 를 해보는 기회가 없었던 것 같다. 중간에 내가 화장실 갔다올때 잠시 둘이서 Pair 를 하는 모습을 봤었는데, 이 선은 내가 적절하게 지켜나가야겠다. 너무 멀리도, 너무 가까이도 아니도록. --1002

대학교들어와서 그정도로 열심히(?)공부한적은 별루 없었던거같다.. 그날 이얘기를 들은 1002형은 놀란표정이었지만 사실 그랬다.. 그러니깐 학점이 그렇게 나왔겠지.. -_-;; 암튼 일주일전에 봤던 자바 기본개념을 바탕으로 남들 다 해본 스윙 기본틀이나 메뉴같은걸 작성해봤다.. 아참 그전에 CVS사용법을 배우고, Architecture와 Design에 대해서도 들었다.. 신기하다.. 무슨 도면같았다.. 이제서야 느낀거지만 프로그램에 코딩이 차지하는비중은 1/2도 안되는구나라는걸 느꼈다.. (이제서야? --;;) 여지껏 놀은시간이 너무 아까웠다.. -_-;; --영서

ProjectZephyrus