Page tree
Skip to end of metadata
Go to start of metadata

회고에서 나온 내용

  • 한 가지 주제를 한 번에 끝내는 것이 아니라 두, 세번 정도 연속적으로 진행하는 방식으로 하면 좋겠음.
  • 블로그와 같은 작은 규모의 최종 모델을 만들고 여기에 기술적인 이슈들을 하나씩 붙여 가는 방식으로 진행함.

스터디 주제 제안

단위테스트 방안 기법??

"작은 애플리케이션을 개발하면서 OOP, TDD, 리팩토링 습득"  에서 논의 가능 한 부분이 있음

이제주제를 스터디하고 얻고자 하는 효과들

단위 테스트에 대해서 이해하고 맛본다.

단위테스트와 다른 기능/통합테스트의 차이점을 인지한다. 

첫번째 스터디

  • 테스트 종류에 대한 이해
  • 단위테스트
  • 행위테스트
  • 블랙박스테스트
  • 화이트박스테스트
  • 상태테스트
  • 기능테스트
  • 통합테스트
  • Mocking 과 Stub , Spy 에 대해서 

두번째 스터디

  • 코딩.. 코딩 .. 코딩

세번째 스터디 

  • 토론

 

통합테스트 방안

통합테스트에 대해서 이해한다.

통합테스트를 편하게 할 수 있는 도구들을 둘러본다. 

통합테스트 범위에 대해서 고민해본다.

프로젝트 협업 및 관리 방안?

        데브웁스 http://dev.kthcorp.com/2012/06/20/devops-new-trend-in-developement-and-operations/

 

CI 환경구성 

       실제 CI 환경을 구성해본다. 

       http://kangcom.com/sub/view.asp?sku=201311153317&mcd=571

      http://jenkins-ci.org/

      http://cruisecontrol.sourceforge.net/index.html

     http://pragmaticstory.com/299

sonar 같은 툴을 활용한 코드 품질 관리에 대한 논의

       http://www.sonarsource.com/

      http://pmd.sourceforge.net/

     http://findbugs.sourceforge.net/

    http://stan4j.com/papers/stan-whitepaper.pdf

 

로그 어떻게 관리할 것인가?

작은 애플리케이션을 개발하면서 OOP, TDD, 리팩토링 습득

  • 지뢰찾기와 같은 작은 애플리케이션을 직접 개발
    • 웹 기반 지뢰찾기 개발을 해보는 건 어떠세요??
  •  1차 NEXT 코드 리뷰 스터디 : 현재 학생들과 하고 있는 스터디 형식
  • 장점 : 소스 코드를 통해 OOP, TDD, 리팩토링의 맛을 느낄 수 있다.
  • 단점 : OOP, TDD, 리팩토링의 맛을 제대로 느끼려면 많은 시간을 투자해야 한다.

프로젝트 A to Z 까지 각 단계별

  • No labels

6 Comments

  1. '기획-분석-설계-구현'

    하나의 흐름을 익혀볼 수 있으면 참 좋겠네요. ㅎㅎ

    2014년도에 있을 개발대회에 도전할 도전팀을 구성해볼 수 있음 좋겠어요. ㅎㅎ

    1. 스터디에서 이런 시도 몇 번 했다가 모두 실패한 경험이 있어서 난 이런 방식으로는 하고 싶지 않더라. ㅋㅋ

      단, 순수하게 그런 목적으로 팀을 꾸려서 한다면 성공할 가능성도 높아보인다. 최초 목적이 스터디가 아니라 개발대회 도전이라는 목표로 팀원을 구성하는 것이 성공 가능성이 높다고 생각해.

  2. 아, 문득 생각이 났는데! ^^

    2014년도 스터디가 끝나는 시점에

    스터디의 결과를 발표하는 '작은 세미나'를 준비해보면 어떨까요?

    1. 적극 찬성한다.

      굳이 2014년 끝이 아니라 우리 스터디가 6개월 정도 단위로 진행하니 6개월 정도 후에 진행해도 괜찮겠다는 생각이 든다. 50명 내외의 작은 세미나도 큰 의미가 있으리라 생각한다. 이 부분도 같이 고민해 보자.

  3. sonar 같은 툴을 활용한 코드 품질 관리에 대한 논의도 괜찮을거 같아욤

  4. 지헌의 의견에 공감하면서요  ~~

    프로젝트 A to Z 까지 각 단계별로 " 당연히 ???  " 알아야 할 것들에 대해서 고심해보고 ~

    관련한 내용을 정리해서 워크북 ?? 형식의 자체 책을 만들어 보는 건 어떨까요 ??

    기획 분석 설계 구현 .. 각 각 한 권의 책처럼 만들어서 PDF 혹은 기타 전자 파일 형식으로 ^^ ~~~

    그래서 개발자의 길에 들어서는 사람들에게 일종의 가이드 북이 될 수 있도록 ...... 

    그리고 계속 업데이트 되는 .... ^.^

    누구도 가르쳐 주지 않지만 당연히 알아야 하는 개발자 상식백과 사전 ~~~ from SLiPP ~~ 

    너무 방대하면 이클립스 활용법에 관한 ~~~

    ( 삽질 방지를 위해선 ㅎㅎ 사실 이게 가장 절실했었지요 ~~ ) 전자책 같은거라도....

    책이 목적이 아니라 그 과정에서 정리되는 내용들이 도움이 많이 될듯해요 ~~