애자일 방법론과 XP, Test-first, TDD 테스트 주도 개발 (1)

bbio3o·2021년 2월 7일
0
post-thumbnail

부전공 수업으로 들었던
'소프트웨어 엔지니어링' 수업에서 공부한 내용을 정리해보았다.
중요한 과목이라 하여, 필수 이수 과목으로 생각하고 들었던 수업인데
지금 생각해보니, 정말 잘했던 결정이였다. 수업 자료 정리해 두었던 과거의 나를 칭찬하며..🥺


📌 Agile Developement? 애자일 방법론이란?

애자일 방법론은 90년대 말쯤 plan-driven 방식과 다르게, 빠르게 변하는 트렌드와 비즈니스 환경에 맞추어 코드 자체에 더 집중하고, 핵심 기능만 구현하고 계속해서 개발해 나가는 방식.
Incremental development의 대표적인 예이다. plan-driven 방식의 대표적인 예로는 폭포수 방법론(Waterfall model)이 있다.
보다 빠른 개발시간과 시장출시를 위해 만들어진 개발 방식이다.(경쟁사가 비슷한 서비스를 먼저 출시해버리면 선점고객 확보에 불리하기 때문)
안전성이 중요한 항공기 관련 시스템이라던지 당뇨병 환자를 위한 인슐린 주사 시스템 등에는 처음부터 철저한 계획을 짜고 위험을 대비하는 plan-driven 방식이 맞을 수 있지만,
애자일 방법론은 일반 대중을 타겟으로 하는 작은 규모의 소프트웨어에서 적합한 방식이라 할 수 있다.

✔️ Agile Development의 특징

  • customer(고객)가 외부의 법이나 규제가 없는 환경이고, 직접 개발 환경에 참여할 수 있다.
  • 핵심기능을 빨리 구현하고 시장의 재빠른 출시가 목표
  • process가 아닌 '사람'에 집중, 개발자의 개발 방식을 존중
  • 고쳐나가야 할 change request 변화를 쉽게 받아들인다.
  • 프로그램 사양, 설계 및 구현이 상호 통합됩니다.
  • 단순함을 유지한다.(코드의 단순화, 문서화의 단순화, development process단순화)
  • 새로운 버전이 자주 출시된다.
  • 바로바로 자동으로 테스트할 수 있는 테스트 툴을 사용한다.
  • 문서화 작업을 최소화 한다.(애자일 방식의 큰 단점, 하지만 이는 회사, 팀에 따라 문서화 작업을 중요하게 생각 할 시에 애자일 방식을 채택했어도 문서화 작업이 많이 이루어지는 경우가 있습니다.)


📌 Extreme Programming (XP)

  • 90년 대 말 애자일 방법론의 범위로 소개되었다.
  • 말그대로 극단적인 프로그래밍 방식이다.
  • 하루에 새로운 버전이 여러번 나올 수 있다.
  • 2주에 한 번씩 핵심기능을 갖춘 서비스 출시 후 개선된 서비스를 계속 출시한다.
  • 새로운 기능을 빌드할 때마다 모든 테스트를 거쳐야한다.

✔️ The extreme programming release cycle

  • 해당 소프트웨어를 가지고 사용자가 어떻게 사용하는지 User Stories를 나열하고, 이 유저 스토리 중 일부를 뽑아 구현하고(모든 시나리오를 고려할 수는 없다.) 그 이후에 남아 있는 몇몇 유저 스토리를 선택해서 다음 increments를 출시한다.

  • User stories에 기반해 Task로 쪼갠다.

  • Small release 작은 단위의 출시

  • 현재의 requiments만을 충족하는 심플한 설계, 디자인 Simple Design

  • Test-first 개발방식 (테스트 코드를 먼저 작성하고 구현, 자동으로 테스트 할 수 있는 코드를 만든다.)

  • Conatant Refactoring 지속적인 리팩토링, 향후 코드가 확장이 되기 쉽도록 코드를 다듬는다.

  • Pair-programming 페어프로그래밍, 두명이 같이 개발을 해 한명을 코드를 짜고 한명은 검사한다.(디버깅 실시간으로 같이 체크함)

  • Collective Ownership 누구나 코드를 수정 가능한 자격, 모든 코드에 대한 책임을 가진다.

  • Continuous Integration 계속 기능을 보완, 확장 통합에 신경써야하며 이는 모든 유닛테스트를 통과해야한다.

  • 너무 많은 야근을 해서는 안되고 적정 페이스를 유지해야한다.

  • customer가 개발과정에 참여한다.(customer는 실제 개발을 하는게 아니라 개발 팀의 팀원으로서 system requirements를 계속 상기 시켜주거나 test과정에 참여하는 책임이 있다.)



✔️ 여기서 말하는 Refactoring이란?

외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법.
코드가 작성된 후에 디자인을 개선하는 작업, 일종의 '코드정리' 라고 볼 수 있다.
코드를 얼마나 '일반화' 시킬 것인가에 대한 고민
리팩토링을 통해 '가독성'을 높여서 agile방식이나 XP방식에서 역할이 적은 Documentation의 필요도를 줄여준다.
적절한 부분에서 적당하게 코드를 일반화시키고 다듬는다면 향후 확장성에 있어서 유리하다.

리팩토링 예시

  • 클래스의 상속을 만들어 적극적으로 활용한다.
  • 변수나 함수의 renaming을 통해가독성이 높도록 작성하며, 두개 이상의 methods를 하나로 통합
  • 인라인 코드를 메소드로 만들어서 코드를 짧게 만들고, 다음에도 쓸 수 있도록 한다.

✨ 이어지는 2편(Scrum, TDD, Test-first-development, Pair-programming) -> 2편 링크

profile
그림도 그리는 개발자 🎨👩‍💻

0개의 댓글