K-Board: Django기반 한국형 커뮤니티

Editor's Notes

• #2: 반갑습니다. (5초간 바라본다) (정리가 되었다 싶으면) 준비 되셨나요? Django 기반의 한국형 커뮤니티 K-Board 입니다. 저는 이번 발표를 맡은 팀장 최.혜.선 입니다.
• #3: 목차입니다. (바로 슬라이드 넘기기)
• #4: 먼저 어떤 배경에서 팀원들이 모이고 프로젝트를 시작했는지 프로젝트의 방향에 대해 설명 드리겠습니다.
• #5: 저희 멘토님은 테스트의 중요성에 대해 강조하셨습니다.(1초 정적) 그렇습니다, (2초 둘러본다) 저희는 테스트 주도 개발. 즉, TDD를 적용하여 프로젝트를 진행하는 것에 중점을 두었습니다.
• #6: 저희 팀은 총 ‘세 명’의 팀원들로 구성 되어있습니다. 저희 팀원들의 공통점이 하나 있었는데… (1초 정적 후 슬라이드 넘기기)
• #7: 바로 파이썬, 장고, 백엔드 개발 경험이 전무하다는 것입니다. 그럼에도 불구하고 장고 기반의 프로젝트인 배권한 멘토님을 지도 멘토로 신청한 이유는.. (1초 정적 후 슬라이드 넘긴다)
• #8: 1단계 프로젝트의 목적이 “교육”이기 때문입니다. 사업성이 아닌 교육에 목표를 두고 한 번도 해보지 않은 부분에 도전해보기로 했습니다. 또한 멘토님께서도 프로젝트를 통해서 ‘협업의 기본기’를 알려주신다고 했습니다. 그저 혼자서 프로젝트를 진행하는 것은 어렵지 않습니다. 하지만 “함께” 한다는 것은 단순히 각자의 개발실력이 좋다고 해서 잘 되지는 않습니다. 저희 또한 ‘협업의 기본기’가 중요하다고 판단했기 때문에 K-board를 선택했습니다. 원하는 프로젝트를 진행 할 수 있었기 때문에 모든 팀원들이 열정을 가지고 임했습니다. 이제 그 “열정”을 보여드리겠습니다.(두둥!)
• #9: 열정을 쏟았으면 “성과”가 나는 것이 당연합니다. (자만심 ㄴㄴ 자부심) 프로젝트의 결과물에 대해서 이야기 하기 전에 성과부터 보여드리겠습니다. 왼쪽 그래프를 봐주십시오. 프로젝트에 얼마나 기여를 했는지 깃허브에서 제공해주는 그래프입니다. 회색선을 중심으로 1단계 프로젝트를 시작한 ‘전과 후’를 비교해 보았는데요, 프로젝트를 시작하고나서 확연하게 활발해진 것을 볼 수 있습니다. 오른쪽을 봐주십시오. 다른 팀의 평균적인 커밋 수가 약 “300개”입니다. 프로젝트 종료 시점, 저희는 “900개”가 넘는 커밋을 했습니다. 이는 팀원 모두가 3개월 내내 프로젝트에 성실하게 참여했다는 것을 보여줍니다.
• #10: 두번째 성과는 기술 블로그 입니다. 저희는 프로젝트를 시작함과 동시에 각자 기술블로그를 운영했습니다. 블로그를 운영한 이유는 멘토님께서 “기록”으로 남겨야 “진짜로” 자기것이 된다고 하셨기 때문입니다. 프로젝트 진행 과정 및 그와 관련된 기술적인 내용들을 포스팅했습니다. 3개월동안 저희는 109건의 포스트, 5000명이 넘는 방문자 수, 13000건에 가까운 페이지 뷰 수를 자랑합니다. 저희는 새로 배운것을 내것으로 만들려고 시작한 블로그 였지만 프로젝트 외적으로도 많은 개발자들에게 영향을 주었습니다. 소프트웨어 마에스트로 과정을 함께하는 다른 연수생도 저희 팀의 기술 블로그가 많은 도움이 되었다고 했습니다. 이 뿐 만이 아니라 파이썬 관련 커뮤니티 및 발표에서 다수의 포스팅이 공유가 되었고 상당히 좋은 반응을 받았습니다.
• #11: 두번째, 프로젝트 목표입니다. (심사위원들을 슥 둘러본다, 페이지 넘김)
• #12: 저희 프로젝트의 목표는 “2”(손가락으로 2) 가지가 있습니다. 첫번째(손가락으로 1), TDD 두번째(손가락으로 2), 협업입니다.
• #13: 먼저 TDD 입니다.
• #14: TDD는 짧은 개발 프로세스를 반복하는 개발방법론 중 하나입니다. RED단계에서는.. 실패하는 작은 테스트 케이스를 작성합니다. GREEN단계에서는.. 테스트를 통과하는 코드를 작성합니다. REFACTOR단계에서는.. 테스트를 통과하기 위해 만들었던, 중복이 있는 코드들을 제거하고, 불명확한 것을 명확하게 합니다. 이를 통해서 간결하고 안정성 있는 소프트웨어를 만들 수 있습니다.
• #15: 첫번째. 왼쪽 그래프를 봐 주십시오. MS와 IBM사에서 TDD를 적용한 팀과 아닌 팀을 비교한 실험 결과입니다. TDD를 적용한 팀은 적용하지 않은 팀에 비해 개발기간이 15%-35%많았습니다. 하지만 버그의 수는 적용하지 않은 팀에 비해 40%-90%으로 줄었습니다. 두번째. 오른쪽 그래프를 봐 주십시오. 개발 기간이 길어짐에따라 코드를 수정하는데 드는 비용이 기존의 개발방법에 비해 많이 적습니다. 따라서 TDD를 적용하게 되면 코드의 안정성이 확보되는 것을 알 수 있습니다. 테스트 주도 개발을 저희도 처음 시도를 하는 것이기 때문에 TDD 적용에 어려움이 많을것이라고 생각했습니다. 하지만 보다 튼튼하고 유지보수성이 높은 소프트웨어를 생산 할 수 있기 때문에 TDD를 적용하기로 했습니다.
• #16: TDD의 과정에는 리팩토링이 있습니다. 저희는 적절한 리팩토링을 해서 코드의 가독성을 높였습니다. 왼쪽 리팩토링 전의 코드는 2번이상으로 반복되어서 사용되는 코드입니다. FunctionalTest라는 부모 클래스에 helper메소드로 정의하여 리팩토링을 한 결과가 오른쪽입니다. ‘spring’이라는 게시글이 보이지 않는다는 여러줄의 코드입니다. 이를 한줄의 코드로 응집도(손으로 응집하는 모양)를 높여서 이해도와 유지보수성을 높일 수(손을 위로올림) 있었습니다. 이렇게 객체지향이 잘 적용된 코드들은 높은(손을 위로 올림) 재사용성으로 인해 테스트 작성이 용이해지고 안정성(손을 수평선모양으로)을 확보하게 됩니다. 이를 통해서 개발 속도를 점차 늘려(손을 위로 올림)나갈 수 있습니다. 단순히 테스트 코드만 작성하는 것이 아니라 TDD를 통해서, 객체지향적 설계를 적용 하였습니다. 이로써 TDD의 장점인 높은 퀄리티의 소프트웨어를 생산 할 수 있었고 유지보수성과 안정성을 높일 수 있었습니다. 
• #17: 저희는 프로젝트 마무리 시점 90개의 단위테스트와 16개의 기능테스트로 총 106개의 테스트를 작성했습니다. (1초 쉬고 페이지넘기기)
• #18: 이 많은 테스트를 매번 다양한 환경에서 수행하는것은 긴 시간이 소요됩니다. 따라서 Travis-CI를 통해 테스트 하는 것을 자동화 했습니다. K-board 저장소에 push되면 travis-ci가 알아서 테스트를 수행합니다. 테스트를 직접하지 않게 되자 개발효율이 크게 증가했습니다.
• #19: 테스트의 자동화를 한 뒤 저희는 테스트를 얼마나 촘촘하게 짰는지 궁금했습니다. Coveralls는 저희가 짠 테스트가 프로젝트를 얼마나 커버하는지 알려주는 툴입니다. 따라서 Coveralls를 사용하여 테스트가 전체 프로젝트의 몇 퍼센트를 커버하는지 알아보았습니다. 먼저 Python을 사용하는 타 프로젝트들의 커버리지입니다. Facebook tornado, celery, pelican….등등 이 프로젝트들의 평균 커버리지는 78퍼센트 입니다. (1초 정적) 그렇다면…. 저희 프로젝트의 커버리지는 몇 퍼센트일까요?
• #20: 바로 96퍼센트입니다. 저희가 프로젝트기간 테스트에 집중한 결과 96%라는 놀라운 수치를 이끌어 냈습니다. 이렇게 저희는 첫번 째 목표인 TDD를 달성했습니다.
• #21: 이제 2번째 목표인, ‘협업’입니다. (1초 정적, 한번 둘러본다)
• #22: 저희는 주 2회 정기적인 멘토링을 했습니다. 저희 멘토님은 Egoless Programming을 강조하셨습니다. 에고리스 프로그래밍에서는 내가 실수를 할 수 있음을 인정하는 동시에, 내 코드에서 누군가가 문제를 발견해도 개인적인 감정으로 대하지 말라고 합니다. 이렇게 저희는 멘토링의 시작을 즐거운 코드리뷰로 합니다. 코드리뷰 중에 개선할 것이 있으면 즉시 수정을 합니다.
• #23: 또한 저희는 매일 오전 10시에 구글 행아웃을 이용하여 온라인으로 회의를 합니다.
• #24: 진행한 스크럼회의는 이렇게 모두 기록을 해 놓습니다. 회의에서 각자 맡은 부분의 진행상태를 확인하고 어려운 점을 공유합니다. 개발이야기 뿐만 아니라 개발 외적인 이야기도 같이 합니다. 감기몸살 이라든지, 남자 친구랑 헤어지기 직전까지 싸워서 힘든 그런 경우가 있으면 개발을 덜해도 용서를 해줍니다. (하하 호호) 이로써 정기적으로 팀원이 무엇을 개발하고 어떤 어려움이 있는지 알 수 있었습니다.
• #25: 저희는 작은단위의 개발을 반복했습니다. Pull request가 생성이 되면 다른 팀원 두 명이 코드를 리뷰합니다. 코드에서 개선할 점이 있으면 댓글을 통해 토론을 하고 수정해 나갑니다. 또한 저희 팀은 조금 ‘특이한’ merge 방법을 사용합니다. 보통 프로젝트를 진행하면 팀장 혹은 한사람이 merge권한을 전담해서 합니다. 저희는 풀리퀘스트를 보낸 사람이 merge권한을 갖고있습니다. 저희가 이런 협업 프로세스를 추구한 이유는 두가지가 있습니다.
• #26: 첫번째는,(1초 정적) 코드리뷰를 통해서 “더 나은 코드”를 생산 할 수 있습니다. 다른 사람이 작성한 코드 일지라도 “언젠가는” 이해하게될 코드입니다. 작은 단위로 pull request를 보내고 모두가 코드 리뷰를 함으로써 팀원 전체의 프로젝트 이해도가 크게 높아집니다. 두번째는,(1초 정적) 팀원 간의 갈등을 예방 할 수 있습니다. 코드가 제대로 동작하지 않을 때 서로의 코드를 이해하지 못하면 문제 해결이 빨리 되지 않습니다. 팀원 전원이 코드리뷰를 함으로써 프로젝트의 주인의식을 가지도록 하였습니다. 따라서 프로젝트에 문제가 생기면 개인의 문제가 아닌 팀원 모두가 해결해야 할 문제로 받아들이고 함께 해결했습니다.
• #27: 최종본을 내고 나서 보니 또 수정할게 보이고 그래서 수정을 했더니 또 수정을 해야하고… 다들 이런 경험 있으시죠? 이 사진의 출처는 같은 팀원이 작년 겨울, git을 썼을 때의 커밋메시지 입니다. 이렇게 하면 git을 쓰는 의미가 없습니다. 저희는 커밋메시지를 명시적으로 적는방법, 풀리퀘스트나 커밋을 어떻게 나눠서 보내는지, git 커밋 내역을 어떻게 관리하는지에 대해서 배웠습니다.
• #28: 이는 pull request에 올라온 코드를 리뷰하는 모습입니다. 여기 왼쪽 사진은 팀원인 전현준씨가 로그아웃 리다이렉트를 javascript로 구현 한 것을 보고 제가 세팅파일에 로그아웃 리다이렉트를 한 줄로 설정할 수 있다고 알려주는 부분입니다. 토론이 끝나고 팀원모두가 해당 pull request에 동의하자 프로젝트에 merge를 시킵니다. 오른쪽 사진은 팀원인 최지훈씨가 post요청일 경우 게시글 히스토리를 생성하는 코드를 보고 전현준씨가 MultiValueDictKeyError를 피하도록 POST.get을 사용하는 것을 추천 해 주는 부분입니다. 최지훈씨가 현재 상황에서는 필요하지 않다고 판단하여 추후에 수정을 하겠다는 답을 하고 토론이 마무리 되었습니다.
• #29: git을 사용했지만 git처럼 쓰지 못한 예시를 기억하십니까?(4페이지 앞) 저희가 이렇게 달라졌습니다. 누가 봐도 알기 쉽게, 명시적이고 바람직한 커밋 메시지를 작성하도록 노력했습니다. 또한 커밋 내역을 관리 하기위해 적절히 rebase를 하여 커밋들을 합치는 작업을 했습니다. (1초 기다림) 그럼에도 불구하고 저희 프로젝트의 커밋 수가 900개가 넘어가는 “쾌거”를 이루었습니다. (자랑)
• #30: “그래서”, 저희가 무엇을 만들었는지 간단히 설명드린 뒤에 시연하겠습니다.
• #31: 저희가 만든 K-Board 게시판의 글 목록페이지 입니다. 게시글의 추천 수와 조회수가 보이는데요.. 저 사진에서는.. 4번 게시글이 가장 인기가 많네요. (하하 호호)
• #32: 커뮤니티는 많은 사람이 모이기 때문에 관리가 편해야 합니다. 게시판 관리가 용이하도록 별도의 관리자 페이지를 제공합니다. 새로운 카테고리의 게시판을 추가 할 수 있고 별도의 인증없이 유저를 생성하는 것 등이 가능합니다. 유저를 만드는 모델이름이 Account인데 이 account 객체들을 한꺼번에 정리 할 수 있는 필터를 우측에 넣었습니다. 관리자와 관리자가 아닌 계정을 쉽게 구분하여 한꺼번에 적절한 쿼리를 실행 할 수 있습니다.
• #33: 개발에 대해서 잘 모르는 사람도 따라만 하면 쉽게 게시판을 설치할 수 있도록 별도의 문서를 제공하고있습니다. 한국형 게시판인 만큼 한글로 작성하였습니다.
• #34: 마지막으로 시연을 하겠습니다. 저희가 2분30초 가량의 영상을 준비했는데 집중해서 봐주시면 감사하겠습니다.
• #35: 일반 게시판 사용 시연
• #36: 관리자 시연 ~~시연끝~~~~ 실제로 배포를 하고 난 뒤에 직접 사용을 해 보니 테스트가 작성되지않은 배포관련된 부분에서만 버그가 발견되었습니다. 하지만 테스트가 작성된 부분은 예상대로 원활하게 작동했습니다. 이는 테스트의 중요성을 다시 한번 느끼게 되는 계기가 되었습니다.
• #37: 이 프로젝트는 저희 세명 모두에게 개발자로서의 기본기를 다질 수 있는 좋은 시간이었습니다. 대부분의 소프트웨어는 “협업”을 통해 만들어집니다. 학교에서는 이러한 것들을 가르쳐 주지 않지만 이번 프로젝트를 통해서 제대로된 협업을 알게 되었습니다.
• #38: 마지막으로.., 저희는 같이 개발하고싶은 개발자가 되겠습니다.
• #39: 저희가 준비한 발표는 여기까지 입니다. 감사합니다. http://222.237.78.6/