코드 비활성화 방법: 개발자의 생산 종료 스위치

다음은 칼로스 슈르트의 객석 게시물입니다.
생산에서 코드를 비활성화할 수 있는 것은 많은 개발자들이 깨닫지 못하는 능력이다.이거 너무 아쉽다.코드 라이브러리의 일부분, 심지어 완전한 기능을 닫는 능력은 피드백 주기를 단축하고 전체적인 품질을 향상시키는 최선의 실천을 허용함으로써 소프트웨어 개발 과정을 현저하게 개선할 수 있다.
이것이 바로 이 글에서 소개할 내용이다. 당신은 이러한 폐쇄된 메커니즘을 실행할 수 있고, 왜 그것들이 유용한지, 그리고 어떻게 시작하는지.시작합시다.

코드를 비활성화하는 이유는 무엇입니까?

우리가 특성 표지를 깊이 연구하고 그것이 무엇인지, 그리고 어떻게 실현되었는지 설명하기 전에, 당신은 왜 사람들이 코드 라이브러리의 일부 부분을 닫기를 원하는지 물어볼 수 있습니다.이렇게 하면 무슨 좋은 점이 있습니까?
이런 문제에 대답하기 위해서 우리는 소프트웨어가 어떻게 몇 십 년 전에 개발되었는지 되돌아볼 필요가 있다.역사 수업을 들어야지!

암흑시대: 지옥 융합

역사적으로 통합은 소프트웨어 공동 개발을 시도하는 단체가 직면한 가장 심각한 도전 중 하나였다. 
한 조직에 몇 개의 단체가 있는데 각각 몇 달 동안 일하고 각 팀은 자신의 기능을 개발하고 있다고 상상해 보세요.팀이 완전히 격리되어 일할 때, 그들의 응용 프로그램 버전은 서로 다른 방향으로 발전한다.이제 그것들은 단일하고 충돌하지 않는 버전으로 다시 수렴해야 한다.이것은 어렵고도 막중한 임무다.
이것은 바로 "integration hell"의 의미입니다. 같은 응용 프로그램의 버전을 통합하는 투쟁입니다. 이 버전들은 이미 너무 오래 벗어날 수 있습니다. 

솔루션 도입: 지속적인 통합

아프면 한 번 더 하세요.이 말은 우리가 해결을 미루는 문제가 있다는 뜻이다. 왜냐하면 이렇게 하는 것은 매우 어렵기 때문이다.이런 문제들이 쌓이기 전에 더 자주 해결하면 덜 고통스럽고 보잘것없게 된다는 것을 자주 알게 될 것이다.
그렇다면 어떻게 하면 통합을 그렇게 고통스럽지 않게 할 수 있을까?더욱 빈번하게 집적하다.
간단히 말해, 이것이 바로 지속적인 통합(CI)입니다. 개발자가 작업과 공공 공유 저장소를 하루에 한 번 이상 통합할 수 있도록 합니다.서버가 구축을 터치하고 누군가가 그들의 작업을 통합할 때마다 자동 테스트 세트를 실행합니다.이렇게 되면 문제가 생기면 그들은 가능한 한 빨리 드러날 것이다.

부분적으로 완성된 기능을 어떻게 처리합니까

많은 팀이 CI에서 직면한 도전 중 하나는 불완전한 기능을 어떻게 처리하는가이다.만약 개발자가 코드를 메인 라인에 통합하고 있다면, 이것은 하루 이상이 걸려야 완성할 수 있는 모든 개발은 반드시 몇 부분으로 나누어야 한다는 것을 의미한다. 
고객의 미완성 기능에 대한 액세스를 어떻게 피할 수 있습니까?일부 간단한 장면은 유사한 간단한 해결 방안을 가지고 있지만 더욱 어려운 장면은 서로 다른 방법을 필요로 한다. 즉, 일부 코드를 완전히 닫을 수 있다.

특색 깃발 구조

요소 플래그 정의

개발자가 일부 코드를 닫고 열 수 있도록 하는 메커니즘에는 많은 이름이 있다.어떤 사람들은'기능 전환'이나'종료 스위치'라고 부른다그러나'기능 표지'는 가장 유행하는 명칭이기 때문에 이것이 바로 우리가 본 게시물의 나머지 부분에서 사용할 명칭이다.그렇다면 기능 표지는 무엇입니까?
요컨대 기능 표지는 팀이 코드를 수정하지 않은 상황에서 응용 프로그램의 행위를 변경할 수 있도록 하는 기술이다.일반적으로 로고는 사용자의 접근을 막고 일부 코드를 사용하는 데 도입된 변경 사항을 막는 데 쓰인다. 왜냐하면 많은 이유로 생산에 충분하지 않기 때문이다.

코드 비활성화: 어떤 용례가 있습니까?

우리는 현재 생산에서 코드를 사용하지 않는 가장 흔한 용례를 소개할 것이다.

미완성 기능 닫기

보시다시피 기능 표지의 주요 용례 중 하나는 사용자가 아직 사용할 준비가 되지 않은 기능에 접근하는 것을 막는 것입니다.
이렇게 하면 더욱 복잡하고 시간이 더 걸려야 완성할 수 있는 기능을 개발하는 프로그래머는 그들의 업무를 자주 집적하여 이익을 얻지 못할 것이다.

A/B 테스트 활성화

기능 표지를 사용하면 소프트웨어 개발 과정에서 가치 있는 실천을 사용할 수 있는데 그 중 하나는 A/B testing이다. 
A/B 테스트는 웹 사이트나 응용 프로그램의 두 버전을 비교하여 어느 버전을 보존할지 결정하는 사용자 체험 연구 기술이다.이것은 사용자를 무작위로 두 그룹, A그룹과 B그룹으로 나누어 각 그룹에 서로 다른 버전의 응용 프로그램을 전달해야 한다.한 그룹은 현재 생산 버전을 받을 수 있습니다. 우리는'통제'라고 하고, 두 번째 그룹은 새로운 버전의 후보를'치료'라고 합니다. 
그리고 테스트 인원은 두 그룹의 행동을 감시하고 어떤 버전이 더 좋은 결과를 얻었는지 확인한다. 
특성 표지판은 응용 프로그램의 제어 버전과 처리 버전 사이를 신속하고 편리하게 변경할 수 있도록 a/B 테스트를 사용하는 실용적인 방법이다.

카나리아 방출 사용

만약 응용 프로그램의 새로운 버전을 사용자 그룹 전체에 한 번에 건네준다면, 버전이 어느 정도 좋지 않으면, 사용자는 100% 영향을 받을 것이다.만약 당신이 점차 새로운 버전을 출시할 수 있다면?먼저 일부 사용자에게 배치하여 이 그룹을 감시하여 문제를 검사할 것입니다.만약 무슨 문제가 생기면, 너는 그것을 굴려도 된다.만약 모든 것이 보기에 매우 좋다면, 당신은 점점 더 큰 단체를 위해 이 판본을 발표할 수 있다.요컨대 이것은 하나이다canary release.이것은 또 다른 기능 표지가 도움이 될 수 있는 강력한 기술이다.

사용자 선호도에 따른 맞춤형 기능

특정 사용자의 요구에 따라 맞춤형 응용 프로그램을 만들어야 하는 것은 드물지 않다. 소프트웨어 팀은 몇 가지 방식으로 이 점을 실현할 수 있다. 어떤 방식은 효율이 높고 다른 방식은 효율이 낮다. (각 고객을 위해 단독 지점이나 전체 저장소를 만드는 회사를 생각한다.)
이것은 또 다른 기능 표지가 도움을 줄 수 있는 분야로 팀이 같은 기능의 서로 다른 버전 사이를 동적 전환할 수 있도록 한다.

프로덕션 101의 코드 비활성화

코드를 어떻게 비활성화합니까?이것이 바로 우리가 지금 보게 될 세 가지 날로 복잡해지는 단계이다.

1단계: 가장 기본적인 방법

우리는 이렇게 원시적인 방법부터 시작해서, 그것은 근본적으로 특징적인 표식으로 간주되어서는 안 될 수도 있다.다음 위조 코드를 고려하십시오.

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

    var result = useNewCalculation
        ? calculateAdditionalWorkHoursImproved(employee, start, end)
        : calculateAdditionalWorkHoursSameOldWay(employee, start, end);

    return result;
}

위의 코드에서, 우리는 단지 어떤 방법의 낡은 버전을 주석하여 새 버전으로 바꾸었을 뿐이다.우리가 구판을 사용하고 싶을 때, 우리는 단지 상반된 일을 할 뿐이다.(응, 원시적이라고 했어.)이런 방법은 특징 표지의 가장 기본적인 속성 중 하나인 코드를 변경하지 않는 상황에서 응용 프로그램의 행위를 변경하는 능력이 부족하다.
그러나 그것은 더 복잡한 방법을 위해 씨앗을 묻었다.

2단계: 코드에서 결정 삭제

이전의 방법은 개발자가 코드를 변경하지 않고 필요한 기능 버전을 선택하는 것을 허락하지 않았다.다행히도 이것은 결코 어렵지 않다.먼저 논리적 변수를 도입하여 어떤 버전을 사용할지 결정합니다.

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

    var result = useNewCalculation
        ? calculateAdditionalWorkHoursImproved(employee, start, end)
        : calculateAdditionalWorkHoursSameOldWay(employee, start, end);

    return result;
}

그리고 우리는 외부 원본에서 온 변수에 값을 분배할 수 있는 메커니즘을 사용한다.구성 파일을 사용할 수 있습니다.

var useNewCalculation = config[newCalculation];

응용 프로그램에 매개 변수를 전달하는 것은 다른 선택일 수 있습니다.중요한 것은 우리가 지금 외부에서 응용 프로그램의 행위를 수정할 수 있다는 것이다. 이것은 진정한 기능 표시를 향한 큰 걸음이다.
당신이 본 코드 예시는 모두 위조 코드라는 것을 기억하십시오.당신이 가장 좋아하는 프로그래밍 언어를 사용하면 이런 방법을 사용하기 시작하고 그것을 한 수준으로 향상시키는 것을 막을 수 없습니다.예를 들어, if 문장을 피하기 위해 클래스를 사용하여 특성과 디자인 모델 (예를 들어 공장) 을 표시할 수 있습니다.

단계 3: 포괄적인 기능 플래그 관리

응용 프로그램이 소량의 표지만 있을 때, 앞의 방법은 아마도 충분할 것이다.그러나 이 숫자가 늘어나면서 일은 엉망이 되기 시작했다.
우선, 당신은 기술 채무에 문제가 있습니다.수동으로 이루어진 특성 표지는 코드 라이브러리에 매우 혼란스러운 조건 흐름을 만들 수 있습니다.매일 새로운 깃발이 나타나면서 상황은 더욱 나빠질 뿐이다.그 밖에 코드를 이해하기 어렵고 내비게이션을 할 수 있으며, 특히 초급 개발자에게는 버그를 일으킬 수 있다.
또 다른 문제는 로고 수가 늘어나면서 잊어버리기delete old, obsolete ones가 흔해지고 있다는 점이다. 
국산 방법의 주요 문제는 모든 표지를 쉽게 보고 관리할 수 없다는 것이다.이것이 바로 우리의 세 번째이자 마지막 단계가 하나의 건의인 이유이다. 자신의 특성 표지 방법을 내놓지 마라adopt a third-party feature flag management system.

기능 플래그는 CI/CD Enabler

우리는 이미 개발자가 생산 과정에서 일부 코드 라이브러리를 비활성화할 수 있는 메커니즘을 소개했고, 코드에 접촉할 필요가 없다.이 기능은 매우 강력하고 A/B 테스트와 참새 발표 같은 기술을 지원하는데 이것은 모두 현대적이고 민첩한 소프트웨어 개발 과정을 바탕으로 하는 특징이다.
이러한 기술의 명칭은 특징 표지, 특징 전환, 특징 회전기 등을 포함하여 다를 수 있다.이러한 기술의 실현 방식도 다를 수 있다. 간단한if문장부터 복잡한 클라우드 기반 해결 방안까지.
그러나 네가 그것을 어떻게 부르든지 간에, 너는 이러한 메커니즘이 제공하는 장점을 과장해서는 안 된다.그들은 지속적인 통합을 추진하는 사람들이다. 이것은 운영을 유지하고 싶은 현대 소프트웨어 조직에 있어서는 없어서는 안 될 것이다.