CLI 기능 구축은 종종 다음과 같이 요약됩니다.

• 새 API 엔드포인트를 출시합니다.
• API 변경이 필요한 새로운 CLI 작업을 구축하세요.
• 방금 출시한 API에 실수가 있었다는 점을 인식하세요.
• 향후에 더 많은 문제를 일으키지 않고 이 기능에 대한 API를 수정해 보세요.
• CLI에서 달성하려고 했던 것이 무엇인지 기억하고 실제로 달성해 보세요.  
• GOTO: 실수가 있었음을 인식합니다.

각 단계에는 이전 단계가 필요하며 폭포수 프로젝트 관리를 재창조했습니다. 당신은 기능적으로 절뚝거릴 때까지 실수를 우아하게 덮어두려고 노력하는 고통에 지쳤지만, 예외가 되기 훨씬 전에 몸을 숙였습니다. 그리고 임시 "수정" 및 사마귀의 결과 클러스터를 유지 관리하는 작업을 시작하지 마십시오.

거기 가봤습니다. 우리는 폭포식 접근 방식에서 벗어나야 한다는 것을 알고 있었습니다.

다음은 우리가 거기에 도달한 방법과 그 과정에서 도움이 된 몇 가지 도구에 대한 이야기입니다.

대략적인 시작을 시작하다

우리는 기능을 이해할 때까지 저렴하고 빠른 반복을 원했고, 그런 다음 값비싼 구현과 장기 지원을 약속했습니다. 소규모 팀으로서 저는 이 프로세스를 처음부터 끝까지 수행하는 경우가 많았고, 차례로 각 부분에 집중하고 싶었습니다. 우리는 그것을 만들 수 있을 만큼 자신감이 생길 때까지 구현 부분을 가짜로 만들고 싶었습니다.

프로세스로 돌아가서 기능 제안부터 시작됩니다. 우리는 추상적인 것에서 벗어나고 싶었지만, 그것이 설익은 구현을 의미한다면 그렇지 않았습니다. Github에서 설명하는 Google Docs CLI 스케치 접근 방식에서 영감을 받아 "스케치"로 위조했습니다.

안타깝게도 정적 스케치는 우리가 원하는 피드백을 제대로 제공하지 못했습니다. 우리의 CLI는 시간이 지남에 따라 출력을 변경합니다. 그림이라기보다는 애니메이션에 가깝습니다. 더 높은 충실도를 달성하기 위해 저는 기본 입력을 받고 적절한 미리 준비된 답변을 인쇄하여 응답하는 작은 Ruby 프로그램을 작성했습니다.

그 이후로 우리는 애니메이션 CLI 출력을 캡처하는 훨씬 더 나은 방법을 찾았지만 이를 설명하려면 약간의 우회가 필요합니다.

테스트도 하시나요?

CLI를 구체화하기 시작하면서 극단적인 사례를 테스트하고 회귀를 감지하고 싶었습니다. 아이디어를 찾기 위해 공개 코브라/버블티 기반 CLI를 조사한 결과 실망스러울 정도로 테스트가 거의 없었습니다. 그러다가 우리에게 출발점이 된 Charm의 티테스트를 우연히 발견했습니다.

Teatest는 골든 테스트에 중점을 두고 알려진 양호한 출력을 캡처한 다음 향후 출력이 계속해서 일치한다고 주장합니다. 애니메이션 CLI 출력의 충실도 높은 캡처로 다시 한 번 돌아왔습니다. Teatest는 플립북과 같은 프레임 기반 솔루션에 대한 훌륭한 아이디어를 제공했으며, 이를 기반으로 다음을 구축했습니다.

─── SigninHeader ───────────────────────────────────────────────────────────────
# Signin To Your CLI Account `cli auth signin`
─── SigninInput --──────────────────────────────────────────────────────────────
# Signin To Your CLI Account `cli auth signin`
    ? What is your username?
    ? user
─── SigninInput ────────────────────────────────────────────────────────────────
# Signin To Your CLI Account `cli auth signin`
    * Signing in to your CLI account… ⠋
─── SigninInput ────────────────────────────────────────────────────────────────
# Signin To Your CLI Account `cli auth signin`
    * Signed in to your CLI account: [email protected]

이 단순화된 예는 기본 인증 명령에 대한 골든 출력의 모양을 보여줍니다. 수평선은 활성 모델을 나타내는 레이블과 함께 프레임을 나타냅니다. 이를 종합하면 라인이 추가, 제거 또는 교체되더라도 출력의 충실도가 높은 캡처를 얻을 수 있습니다.

우리는 테스트 스위트에서 플래그를 사용하여 파일을 골든 출력으로 업데이트합니다. 그렇지 않으면 출력이 파일과 일치하지 않으면 테스트가 실패합니다. 이를 통해 출력 변경 사항을 계속 인식하고 출력의 모양과 변경 여부를 이해할 수 있으므로 PR 검토가 용이해집니다. 우리는 애니메이션과 스타일 아이디어를 모두 포착할 수 있도록 스케치 프로그램을 Github 스타일 Google 문서의 골든 스타일 출력으로 대체할 계획을 갖고 있다는 점이 너무 마음에 듭니다.

한때와 미래의 스케치를 손에 쥐고 새로운 API 엔드포인트 시작으로 돌아가겠습니다.

API와 CLI를 함께 설계

우리는 API와 CLI를 동시에 작업합니다. 왜냐하면 이들에 대한 최고의 디자인은 긴밀한 통합에서 나오기 때문입니다. 우리는 더 저렴한 환경에서 설계를 반복하고 요구 사항이 확고해질 때까지 구현을 기다리면서 폭포의 위험을 피하면서 이를 수행할 수 있습니다. API의 경우 이는 OpenAPI를 사용한 스케치를 의미합니다.

openapi: 3.1.0
info:
  contact:
    email: [email protected]
  description: An example API.
  title: Example API
  version: 0.0.1
servers:
  - url: https://api.example.com
tags:
  - description: account operations
    name: account
paths:
  '/v0/auth/signin':
    post:
      description: Signin to CLI.
      operationId: auth_signin
      responses:
        '200':
          content:
            'application/json':
              schema:
                additionalProperties: false
                properties:
                  email:
                    description: Email address for authenticated user.
                    example: [email protected]
                    type: string
                required:
                  - email
                type: object
          description: Successful signin.
      summary: Signin to CLI.
      tags:
        - account

이 간단한 예는 기본 인증 명령에 대한 스키마의 모양을 보여줍니다. 우리는 이러한 파일 작업을 단순화하기 위해 스펙트럼 린터를 사용합니다.

스케치를 손에 들고 CLI를 구현하는 동안 프리즘을 모의 API 서버로 사용합니다. 필연적으로 실수가 있었다는 것을 깨닫게 되면 사양을 조정하고 CLI 반복으로 돌아갈 수 있습니다. 이 높은 수준에서 작업하면 API와 CLI를 함께 발전시키고 더 나은 지식을 얻을 때까지 비용이 많이 드는 구현을 연기할 수 있습니다.

API 구현

또한 위원회를 사용하여 구현하는 동안 정직성을 유지하기 위해 OpenAPI 사양을 활용합니다. Assert_schema_conform은 정렬을 테스트하고 미들웨어는 실시간 불일치를 알려줍니다. 이는 회귀로부터 우리를 보호하는 동시에 빨간색 녹색 구현을 허용하기 위해 결합됩니다.

모의 및 프록시를 사용한 테스트

일상을 마무리하기 위해 테스트 스위트에서는 플래그를 사용하여 모의 또는 프록시 모드에서 프리즘을 실행합니다. 플래그를 사용하면 한 종류의 테스트 작성에만 집중할 수 있습니다. 하지만 이는 한 모드 또는 다른 모드에서 일부 테스트를 건너뛰는 것을 의미합니다. 우리는 속도와 전체 스택이 CI에서 실행되지 않는 Windows 및 macOS에서 모의 ​​테스트를 사용합니다. 프록시 테스트를 통해 플래그만 추가하면 전체 스택에 대해 테스트를 실행할 수 있으므로 필요할 때마다 엔드투엔드 테스트를 쉽게 실행할 수 있습니다.

모두 함께 끌어당기기

스케치와 사양은 구현 시 어려움을 겪지 않고 초록을 반복하는 데 도움이 됩니다. 그런 다음 모형과 프록시는 구현이 스케치와 일치하는지 확인하는 데 도움이 됩니다. 프로세스를 계속 반복함으로써 각 기능의 고통이 줄어들었으며, 이번 달 말에 제공할 팀 경험을 구축하는 동안 이를 깊이 인식했습니다.

우리는 계속해서 프로세스를 반복할 것입니다. 여러분이 이 과정에서 뭔가를 배웠기를 바라며 저도 여러분에게서 배우고 싶습니다. 무엇을 시도했고, 어디가 자랑스럽고, 무엇이 여전히 답답합니까?