알림 도구는 실제로 NetworkManager의 어떤 상태를 받았나?

네 번째 상태는 한 API에서는 알림을 발생시키고 다른 API에서는 다른 의미를 지니는데, 코드에는 아무 차이도 드러나지 않는다. NetworkManager의 모든 상태 값은 이름 붙은 열거에 속하며, 열거들은 주어진 숫자가 무엇을 뜻하는지에 대해 합의하지 않는다. 따라서 동작하는 조각에서 정수를 다른 콜백으로 복사하는 것은 동작의 이전이 아니라, 깨지기를 기다리는 우연이다. 먼저 유형을 찾으면 숫자가 읽히게 된다.

유형 없는 숫자는 소문일 뿐

여기서 중요한 열거는 둘이다. 하나는 일반적인 활성 연결을 설명한다: 알 수 없음, 활성화 중, 활성, 비활성화 중, 비활성. 다른 하나는 VPN 연결을 구체적으로 설명하며, 준비, 연결 설정, IP 구성, 그리고 무언가 활성화되기 전의 인증 요청 등 도중에 더 많은 단계가 있다. 두 열거의 번호는 모두 영에서 시작한 뒤 갈라지므로, 일반 열거에서 비활성을 뜻하는 값은 VPN 순서의 어딘가 중간에 떨어진다. 어느 헤더도 틀리지 않았고, 서로 다른 질문에 답할 뿐이다.

리터럴 대신 설치된 헤더나 바인딩의 상징 상수를 사용하라. 이름은 다시 번호를 매겨도 살아남지만 정수는 그렇지 않다.

기계가 아니라 연결 하나를 지켜보라

관심 있는 프로필의 UUID와 그 활성화가 만든 활성 연결 객체에서 시작하라. 장치 상태나 다른 터널의 상태는 둘이 같은 순간에 바뀌더라도 대체물이 아니다. 관찰과 함께 객체의 정체성을 유지해, 나중 보고서가 어느 프로필이 그것을 만들었는지 말할 수 있게 하라. 기계에는 많은 상태가 있지만 알림은 그중 하나에 관한 것이다.

그다음 알림이 무엇을 뜻해야 하는지 정하라. 활성화에 이른 적 없는 연결은 설정 실패이고, 활성이었다가 사라진 세션은 손실이다. 이 둘은 다른 말을 받을 자격이 있다.

어떤 전이를 보고하는지 말하라

새 값을 따로 시험하는 대신 이전 상태를 저장하고 새 상태와 비교하라. 실패 상태로의 전이와 활성 상태에서의 이탈은 둘 다 아무것도 연결되지 않은 채 끝나더라도 다른 사건이다. 사용자가 조치할 수 있는 유일한 부분인 경우가 많으므로 이유 문자열도 옆에 기록하라.

의도적인 연결 해제는 결함이 아니다. 알림이 그 차이를 구별하지 못하면 사람들에게 알림을 무시하도록 가르칠 것이다.

관찰자를 살려 두라

변하지 않은 상태에 대해 반복 조회가 또 다른 경고를 올려서는 안 된다. 그 한 가지 규칙이 이런 알림 도구가 만드는 잡음의 대부분을 없앤다.

관리자가 다시 시작되거나 관찰 대상 객체가 교체되는 경우도 다뤄라. 낡은 정체성에 묶인 감시자는 흥미로운 일이 일어나는 바로 그 순간에 조용해지고, 침묵은 건강처럼 보인다. 관리자의 존재가 바뀐 뒤 현재 객체를 다시 찾아내고, 재발견이 언제 일어났는지 기록하라. 그렇지 않으면 로그에는 보고를 그만둔 터널만 남는다.

알림을 사용자가 있는 곳으로 전달하라

특권 시스템 콜백은 데스크톱 세션의 알림 서비스를 상속하지 않는다. root 수준 핸들러에서 보낸 메시지는 오류 없이 사라질 수 있으며, 그러면 손으로 시험할 때는 동작하고 실제로는 결코 동작하지 않는 알림 도구가 만들어진다. 데스크톱을 소유한 세션으로 전달하거나, 데스크톱 자체의 클라이언트가 알림을 올리게 하라.

클라이언트의 기존 알림이 이미 그 경우를 다룬다면, 한 사건에 알림 도구 둘은 중복이 아니라 지원 문제이므로 그것을 우선하라. 지원 기록에는 사건 시각, 프로필, 이유를 남기고 비밀번호와 전체 프로필은 남기지 말라. 알림은 관찰된 상태의 보고이며 강제 수단이 아니라, 터널이 없을 때 트래픽을 막는 것은 자체 구현을 가진 별도의 정책이라는 점을 기억하라.