▲

GN⁺: 기술 부채 분류 (2018)

 (technology.riotgames.com)
3P by neo 2달전 | favorite | 댓글 1개

기술 부채의 분류

소개

  • Bill "LtRandolph" Clark는 _LoL_의 Champions 팀의 엔지니어링 매니저로, 기술 부채에 대해 깊은 관심을 가지고 있음.
  • 기술 부채는 미래 개발자에게 비용을 초래하는 코드나 데이터로 정의됨.
  • 이 글에서는 Riot에서 경험한 다양한 기술 부채의 유형과 내부적으로 사용하는 모델을 소개함.

메트릭스

기술 부채를 평가하기 위해 세 가지 주요 축을 사용함: 영향, 수정 비용, 전염성.

영향

  • 기술 부채가 플레이어와 개발자에게 미치는 영향.
  • 버그, 누락된 기능, 예기치 않은 동작 등.

수정 비용

  • 기술 부채를 수정하는 데 필요한 시간과 리스크.
  • 단순한 오류는 몇 분 만에 수정 가능하지만, 깊이 뿌리박힌 문제는 몇 주 또는 몇 달이 걸릴 수 있음.

전염성

  • 기술 부채가 얼마나 퍼질 수 있는지.
  • 다른 시스템과의 상호작용, 데이터 복사, 새로운 기능 구현에 영향을 미침.

부채의 유형

로컬 부채

  • 시스템 내부에서만 문제가 발생하며, 외부에는 영향을 미치지 않음.
  • 예: Jarvan의 Cataclysm.
Cataclysm 메트릭스
  • 영향: 1 / 5
  • 수정 비용: 2 / 5
  • 전염성: 1 / 5

맥가이버 부채

  • 두 개의 상충하는 시스템이 임시방편으로 결합된 경우.
  • 예: C++의 std::string과 Riot의 AString 클래스.
std::string vs AString 메트릭스
  • 영향: 2 / 5
  • 수정 비용: 3 / 5
  • 전염성: -2 / 5

기초 부채

  • 시스템의 깊은 곳에 자리 잡은 가정이 전체 시스템에 영향을 미치는 경우.
  • 예: _LoL_의 lua 스크립팅 언어 사용.
BlockBuilder Lua 메트릭스
  • 영향: 4 / 5
  • 수정 비용: 4 / 5
  • 전염성: 4 / 5

데이터 부채

  • 다른 유형의 기술 부채 위에 많은 콘텐츠가 쌓여 수정이 어렵고 위험한 경우.
  • 예: BlockBuilder 스크립팅 언어의 매개변수 이름 버그.
매개변수 이름 버그 메트릭스
  • 영향: 2 / 5
  • 수정 비용: 2 / 5
  • 전염성: 4 / 5

요약

  • 기술 부채를 평가할 때는 영향, 수정 비용, 전염성을 고려해야 함.
  • 전염성은 기술 부채가 퍼질 가능성을 나타내며, 이를 무시하면 큰 문제가 될 수 있음.
  • 기술 부채는 로컬 부채, 맥가이버 부채, 기초 부채, 데이터 부채의 네 가지 유형으로 분류할 수 있음.

GN⁺의 정리

  • 이 글은 기술 부채의 유형과 이를 평가하는 방법을 설명함으로써 개발자들이 더 나은 결정을 내릴 수 있도록 도움을 줌.
  • 기술 부채의 전염성을 강조하여, 문제를 조기에 해결하는 것이 중요함을 강조함.
  • 유사한 기능을 가진 다른 프로젝트로는 _Dota 2_와 _Overwatch_가 있음.
▲
neo 2달전  [-]
Hacker News 의견

  • 인터페이스는 디자인에서 가장 중요한 요소 중 하나이며, 신중하게 고려해야 함

    • 아름다운 인터페이스는 시간이 주어지면 쉽게 개선할 수 있지만, 반대의 경우는 드묾

  • 창업자의 부채는 빠르고 좋은 기술을 제공하기 위해 창업자들이 만든 부채임

    • 많은 국가의 창립 문서도 이 범주에 속함

  • 이 글이 엔지니어링 매니저에 의해 작성된 것이 놀라움

    • 내부에서 승진한 매니저가 없고, 외부에서 채용하는 경향이 있음

  • 기술 부채에 대한 분류가 논의됨

  • 기술적 관점에서 훌륭한 기사임

    • "명명법"이 더 적절한 표현일 수 있음
    • 각 예시가 매우 생각을 자극함

  • 기술 부채를 설명하는 데 "Contagion"을 사용함

    • 훌륭한 설명임

  • 기술 부채는 미래 개발자가 비용을 지불해야 하는 코드나 데이터로 정의됨

    • 부채를 발생시킬 때 즉각적인 필요와 미래 비용을 균형 있게 고려해야 함
    • 부채에 대한 병적인 혐오감을 가지고 있음

  • "로컬 부채"를 일반적인 상황에서 기술 부채로 부르지 않을 것임

    • 어딘가에 항상 혼란이 있을 것이며, 그것을 캡슐화하는 것이 일반적임

  • 여러 스타트업에서 일한 경험이 있음

    • 창업자들이 아이디어와 실제 구현된 것, 그리고 작동하는 부분을 혼동하는 경우가 많음

  • 단기적인 이익을 위해 기술 부채를 의도적으로 떠안는 경우가 있음

    • 이 이익도 다른 축으로 고려해야 함
답변달기