상태 머신을 작성하면서 프로그래머가 된 기분

2012년부터 "웹 개발자"로 일하고 있습니다.

저는 사용자 정의 PHP 프레임워크, Wordpress, Drupal, Node.js 앱 및 Python 마이크로서비스에서 일한 독학 프로그래머입니다.

2019년이 되어서야 첫 번째 상태 머신을 작성할 때 프로그래머로서 뭔가를 작성한 것 같은 기분이 들었습니다.

xstate을 사용하여 작업을 위한 상태 머신을 작성하고 1년이 지난 후에도 해당 코드가 아직 생산 중이라는 사실을 알게 되면서 더 큰 자부심을 갖게 되었습니다.

상태 머신이란 무엇입니까?

나 자신을 앞서 나가기 전에 모르는 사람을 위해 xstate은 유한 상태 기계를 구현하는 Javascript 라이브러리입니다.

Finite state machines 세계를 설명하는 방법의 모델입니다.

기계는 상태에 존재하고 기계가 어떻게 다른 상태로 이동하거나 동일한 상태로 돌아갈 수 있는지 보여주기 위해 전환이 생성됩니다(자판기는 유한 상태 기계입니다).

처음에 이러한 정의는 나에게 별로 도움이 되지 않았으며, 그 정의가 의미하는 바를 "알면서"더 나은 프로그래머처럼 느껴지지 않았습니다. 나는 그것을 얻었다는 느낌을 받기 위해 실제로 이러한 개념을 사용하여 무언가를 만들어야했습니다.

UI는 항상 복잡했습니다.

저는 의료 분야에서 일합니다. 의료 앱은 복잡한 UI와 양식을 작성해야 하는 것으로 유명합니다. 제 직장에서는 React와 Redux를 사용합니다.

2019년에 공급자를 위한 새로운 UI 흐름을 만들어야 하는 중단점이 있었습니다. 내 동료와 나는 nth 시간 동안 다음 Redux 객체를 작성하고 있었습니다.

{
  didInvalidate: boolean;
  isFetching: boolean;
  hasError: boolean;
}

더 나은 방법이 있어야 한다는 것을 깨달았습니다. 이 패턴은 얼마나 많은 다른 게시물이 이를 승인했는지에 관계없이 우리에게 효과가 없었습니다.

Youtube는 UX를 위한 상태 머신 설계에 대해 이 비디오를 추천했습니다.



그리고 그 다음날 동료에게 그것을 던졌습니다. 그는 도서관을 조사했고 어떤 문제도 발견하지 못했습니다. 우리는 이 라이브러리의 사용법을 엔지니어링 관리자에게 제안했고 그도 승인했습니다.

xstate API가 우리에게 새롭기 때문에 기능을 구축하는 데 더 오래 걸렸습니다. 그러나 최종 결과는 버그가 없는 릴리스였습니다.

xstate를 사용하여 기능을 버그 없이 릴리스했을 뿐만 아니라 이것이 UX를 개발하는 방향으로 나아갈 수 있다는 확신을 주는 코드 작성과 관련된 모든 것입니다.

질문하는 법을 배웠다

유한 상태 기계(Finite State Machine) 모델은 프로그래머로서 당신이 만들고 있는 것에 어떤 일이 일어날지 명확하게 진술하도록 강요합니다.

사용자는 A -> Z에서 어떻게 얻습니까?

어떤 이유로 사용자가 X로 끝날 수 있습니까?

우리가 설명하지 않은 상태에 있는 사용자를 잡을 수 있는 방법이 있습니까?

코딩을 하기 전에는 이런 질문을 한 적이 없습니다. 이것들은 내가 React 구성 요소를 작성하고 this.state 또는 Redux를 사용하여 알아낼 때 해결한 문제였습니다. 이것은 거꾸로입니다.

우리(웹 프로그래머로서)는 항상 상태 차트를 사용하여 이러한 질문에 답해야 합니다. 해결되지 않은 특정 오류 상태에 대해 디자이너에게 여러 번 질문해야 했습니다. 초기 기능 요청에서 고려되지 않은 사용자 유형에 대해 제품 관리자에게 직접 메시지를 보내야 했습니다. 우리 모두는 이 기능이 성공하기를 원했기 때문에 우리 모두의 지속적인 대화였습니다.

프로그래머가 된 기분

우리는 무엇을 만들고 있는지 질문했습니다. 우리가 구축하려는 기능의 전문가가 된 후 코드를 작성하기 시작했습니까?

우리가 기계 객체를 완성하고 우리의 기능이 무엇을 할 것인지 정확히 알았을 때, 유한 상태 기계 모델에 대한 이러한 확신이 우리가 "레벨 업"된 것처럼 느끼게 했습니다.

우리는 우리가 만든 것이 어떻게 작동할지 알고 있었기 때문에 프로그래머가 되었습니다.