ㅇㅇ 주도 설계 개발이 너무 많다.
머릿말
안녕하세요 기술 글을 적는 것에서 도망치고 있는 무소입니다.
어째서인가 최근 "ㅇㅇ주도개발"이라는 말을 자주 듣습니다.
ㅇㅇ주도 개발이 너무 많은데, 의견 충돌 안 일어나나?생각해 시작한 글입니다.
무엇을 축으로 주도하면 좋은가 애매한 문제입니다.
이 만큼 ㅇㅇ주도 개발이라는 말이 많은 것은 못난 자신을 좋은 DX로 밀어주기를 바라는 욕구의 구현이 아닐까? (구세주 사상적스러운) 이런 혼자만의 생각이 있었지만, 이러한 상황에는 ㅇㅇ 주도 개발하면 좋다 느낌으로 정리하려합니다.
유명한 주도개발 종류
유저 기능 주도 개발(FDD)
의미:
FDD(Feature Driven Development)는 Jeff De Luca가 1997년 싱가폴 은행의 대규모 개발 프로젝트(50인, 15개월)을 위해 제안한 애자일 개발 프로세스입니다. feature는 고객 시점에서 작은 단위 기능 가치를 말합니다. FDD는 실전 경험있는 모범사례를 조합한 것으로 작동하는 소프트웨어를 짧은 간격으로 반복적 제공합니다.
어떨 때 사용하는가:
유저의 요구에 기반하지 않은 개발은 쓸데 없는 비용이 들 가능성이 높으므로, 유저가 바라는 기능을 기조로 개발을 진행할 때는 유저 기능 주도 개발입니다.
사업화전 아이디어가 실제 이익을 내는가 불명이면서, 고객과 대화하며 기능 개발을 진행하고 싶은 경우
엔지니어 팀의 기술숙련도가 그다지 높지 않으므로 쓸모 없이 자잘하게 개발을 하고 싶은 경우
참조링크:
- https://www.sei-info.co.jp/framework/keyword/agile.html
- https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E6%A9%9F%E8%83%BD%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA
- https://www.amazon.co.jp/dp/4274068560/ref=cm_sw_em_r_mt_dp_F136C0SBZ2X2MAB2N0B6
티켓 주도 개발
의미:
티켓 주도 개발(ticket-driven development; TiDD)는 프로그램 개발 방법의 하나로 작업을 나눠 BTS(Bug Tracking System) 티켓을 할당해 관리하는 개발스타일. 세세한 수정이 많은 종래의 개발에서 태어났지만, 애자일 개발과 친화성이 높아, 익스트림 프로그래밍을 시작해 애자일 개발에도 적용되어 있다.
어떨 때 사용하는가:
과거의 기능요구, 버그 수정 같은 것을 추적하는 것은 중요한 일입니다.
모든 개발은 기본 티켓 개발 주도 개발이어야 한다 생각합니다.
- 이슈, 티켓을 기반으로 개발을 철처히 하는 것으로 문제/요구사항 출현 ~ 기능 구현 완료까지 모든 공정을 추적하고 싶은 경우
참조링크:
- https://www.atlassian.com/ja/blog/tidd-part2
마감 시한 주도 개발
의미:
마감 시한이 아슬아슬할 때까지 개발을 하지 않고, 고객과 커뮤니케이션에 전념한다. 어떠한 행운도 이것보다 늦어지면 사단이 날 것 같을 때까지 와서, 개발을 개시한다. 이 단계에서 다음 고객의 일을 시작해서 자원 소비의 평균화한다. 마감 시한이 이미 지났다는 압박을 이용해서 개발을 진행하므로 마감 시한 주도 개발이라 한다.
어떨 때 사용하는가:
밈스러운 의미로 사용하는 것이 아닌가 싶지만 은근히 많은 사람에게 유효한 수단일지도 모릅니다.
어린 시절 여름 방학 숙제, 시험전 날 벼락치기 같은 것이 기억나실지도 모릅니다.
- 시간을 철저하지 않은 엔지니어에게 마감 시한이라는 절대 조건을 줌으로 움직이게 할 수 있다.
- 마감 시한이 없으면 의욕이 없는 경우
- 압박을 받고 싶을 경우 혹은 그러한 성격
참조링크:
마감 시한 주도 개발, "나는 마감이 얼마 남았을 때 움직이는가" 정확히 확인하지 않으면 효율적으로 일하지 못하므로 이를 의식하며 계획을 세워야 한다 - chokudai@AtCoder 사장 August 30, 2014
도메인 주도 개발(설계)
의미:
도메인 주도 개발(domain-driven design, DDD)는 소프트웨어 설계 방법이며, "복잡한 도메인 설계는, 모델 베이스로 해결할 것", "대부분의 소프트웨어 프로젝트에는 시스템을 구현하기 위해 특정 기술이 아니며, 도메인 그 자체와 도메인의 로직에 집중할 것"을 하는 것이다.
어떨 때 사용하는가:
IT 엔지니어로 업계에 전직하고자 할 때, 공통적으로 활용할 수 있는 지식을 갖고 싶다면 제대로 도메인 주도 개발을 배워둬야 합니다.
- IT 아키텍처와 업계 독자의 도메인 지식을 어떻게 세워 올리는가 함께 애플리케이션을 설계/개발할 필요가 있을 때
- 과거 코드가 너무 거시기해서 도메인 주도 설계 기반으로 리팩토링을 하고 싶은 경우
참조링크:
- https://www.amazon.co.jp/dp/479815072X/ref=cm_sw_em_r_mt_dp_QVR1VSSQAVYKMCRZMS6J?_encoding=UTF8&psc=1
- https://www.amazon.co.jp/dp/4798121967/ref=cm_sw_em_r_mt_dp_JCYEEPKX12NBHWSJKA13?_encoding=UTF8&psc=1
- https://qiita.com/little_hand_s/items/721afcbc555444663247
테스트 주도 개발
의미:
테스트 주도 개발(test-driven development; TDD)는 프로그램 개발 방법의 하나로, 프로그램에 필요한 각 기능을 처음부터 테스트로 작성(이를 테스트 퍼스트라 함), 그 테스트가 동작해야 하는 필요최저한 구현을 한 후, 코드를 작성하는 식으로 잦은 공정을 반복하는 스타일이다.
어떨 때 사용하는가:
프로그래밍은 자유롭게 쓸 수 있으므로, 생각하지 쓰려하면 React Props drilling 같이 나쁜 로직으로 작성한다. 클래스, 함수를 프로그램으로 만들 때는 우선 인풋과 아웃품을 어떻게 하는가 의식하며 테스트를 먼저 적는 것은 중요하다 느낍니다.
- 공통 퍼블릭 함수나 util를 만들 떄, 테스트하기 쉬우면서, 이해하기 쉽고, 변경하기 쉬운 함수 군을 구성하고 싶은 경우
- 장래적으로 부채를 만들지 않은 코드를 만들 고 싶은 경우
참조링크:
- https://www.qbook.jp/column/20181009_713.html
- https://shiftasia.com/ja/column/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8Btdd%E3%81%A8bdd/
- https://www.amazon.co.jp/dp/4274217884/ref=cm_sw_em_r_mt_dp_SNR9MZ09JJ0H9D964QF2
- https://codezine.jp/article/detail/12245
행위 주도 개발
의미:
행위 주도 개발(behavior driven development; BDD)는 프로그램 개발 방법의 하나로, 테스트 주도 개발에서 파생한 것이다. 테스트 주도 개발에 작성된 테스트 케이스는 작성된 프로그램 동작이 제대로인가 어떤가 검증하기 위한 "테스트"이다. 테스트라는 점은 동일하지만 여기에 이제부터 작성하기 위한 프로그램이 작동할 "동작"이나 "제약조건" 즉, "요구사양"에 가까운 형태로 자연언어를 병기하며 테스트 코드를 작성한다.
어떨 때 사용하는가:
이 코드는 명백히 이런 것을 한다 간결히 설명할 수 있는 상태의 구현인 면에서, 건전한 코드를 적을 수 있게 되었다 멋대로 생각중입니다. simple is best!
- 비엔지니어, 관계자에게 어떠한 테스트 케이스로 테스트 구현을 하는가를 설명하고 싶을 때(설명과 테스트 구현이 1:1이다)
- 유저가 받아들이는 표준(기능을 구현하면 구현 완료라 보는 표준)을 설정해서 받아 들여지는 표준과 테스트 구현에 대응하고 싶을 때
참조링크:
- https://rihoublog.com/2018/11/06/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AA%E3%83%BC%E3%81%AE%E5%8F%97%E5%85%A5%E5%9F%BA%E6%BA%965%E3%81%A4%E3%81%AE%E3%83%9D/
- https://rihoublog.com/2018/11/06/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AA%E3%83%BC%E3%81%AE%E5%8F%97%E5%85%A5%E5%9F%BA%E6%BA%965%E3%81%A4%E3%81%AE%E3%83%9D/
컴포넌트 주도 개발
의미:
컴포넌트 주도 개발(CDD)는 UI와 조합할 때 먼저 컴포넌트부터 만들어 마지막에 페이지를 작성하는 "bottom up" 개발 프로세스.
어떨 때 사용하는가:
프론트는 잘 모르지만, React에 의해 부품(컴포넌트)을 구성해 유저 인터페이스를 만드는개념이 퍼졌으므로, 도구의 재이용이 가능해서 낭비가 적어지는 것이 좋다 생각입니다.
- UI에서 같은 컴포넌트 아종이 대량 발생해 이건 아차 싶어, 컴포넌트를 통일화하고 싶은 경우
참조링크:
- https://www.componentdriven.org/
- https://ko.reactjs.org/docs/components-and-props.html
정리
세상에는 수 많은 ㅇㅇ 주도 개발이 있네요. 이제부터 더 늘어날지도 모릅니다만, 주도 개발을 조합해서 최강의 ㅇㅇ 주도 개발을 발견하면 좋겠다 생각합니다.
실은 내가 생각한 최강의 ㅇㅇ 주도 개발도 이 글에 넣고 싶지만, 글자가 쓸 데없이 많아지므로, 속편에 등장시킬까 합니다. 기대해주세요~