Kokią NetworkManager būseną jūsų pranešėjas iš tikrųjų gavo?

Ketvirtoji būsena vienoje API iššaukia pranešimą, kitoje reiškia ką kita, o kodas neparodo jokio skirtumo. Kiekviena NetworkManager būsenos reikšmė priklauso vardintam sąrašui, o sąrašai nesutaria, ką reiškia duotas skaičius. Todėl sveikojo skaičiaus kopijavimas iš veikiančio fragmento į kitą atgalinį iškvietimą nėra elgsenos perdavimas; tai atsitiktinumas, laukiantis sulūžimo. Pirmiausia raskite tipą, ir skaičius taps įskaitomas.

Skaičius be tipo tėra gandas

Čia svarbūs du sąrašai. Vienas apibūdina aktyvų ryšį apskritai: nežinoma, aktyvinama, aktyvi, išjungiama, išjungta. Kitas apibūdina konkrečiai VPN ryšį, ir jame daugiau sustojimų kelyje, įskaitant pasirengimą, ryšio nustatymą, IP konfigūraciją ir autentifikavimo užklausą, kol kas nors bus aktyvuota. Jų numeracija abiem atvejais prasideda nuo nulio ir tada išsiskiria, todėl reikšmė, reiškianti išjungta bendrame sąraše, atsiduria kažkur VPN sekos viduryje. Nė viena antraštė nėra klaidinga; jos atsako į skirtingus klausimus.

Naudokite simbolinę konstantą iš įdiegtos antraštės ar susiejimo, o ne literalą. Pavadinimas išgyvena pernumeravimą; sveikasis skaičius ne.

Stebėkite vieną ryšį, o ne mašiną

Pradėkite nuo profilio UUID, kuris jus domina, ir aktyvaus ryšio objekto, kurį sukūrė tas aktyvinimas. Įrenginio būsena ar kito tunelio būsena nėra pakaitalas, net kai abu keičiasi tuo pačiu metu. Išsaugokite objekto tapatybę kartu su stebėjimu, kad vėlesnė ataskaita galėtų pasakyti, kuris profilis jį sukūrė. Mašina turi daug būsenų; pranešimas yra apie vieną iš jų.

Tada nuspręskite, ką pranešimas turėtų reikšti. Ryšys, kuris niekada nepasiekė aktyvinimo, yra nustatymo klaida, o sesija, kuri buvo aktyvi ir paskui dingo, yra praradimas. Šie nusipelno skirtingų žodžių.

Pasakykite, kokį perėjimą pranešate

Išsaugokite ankstesnę būseną ir palyginkite ją su nauja, o ne tikrinkite naują reikšmę atskirai. Perėjimas į nepavykusią būseną ir perėjimas iš aktyvios būsenos yra skirtingi įvykiai, net kai abu baigiasi niekam neprisijungus. Užsirašykite priežasties eilutę šalia, nes dažnai tai vienintelė dalis, kurioje naudotojas gali veikti.

Tyčinis atsijungimas nėra gedimas. Jei pranešimas negali atskirti, jis išmokys žmones jo nepaisyti.

Išlaikykite stebėtoją gyvą

Pakartotinis apklausimas neturi sukelti dar vieno įspėjimo dėl būsenos, kuri nepasikeitė. Ši viena taisyklė pašalina didžiąją dalį triukšmo, kurį šie pranešėjai sukuria.

Taip pat apdorokite atvejį, kai tvarkyklė paleidžiama iš naujo arba stebimas objektas pakeičiamas. Stebėtojas, susietas su pasenusia tapatybe, nutyla būtent tą akimirką, kai įvyksta kas nors įdomaus, o tyla atrodo kaip sveikata. Iš naujo atraskite dabartinį objektą pasikeitus tvarkyklės buvimui, ir užrašykite, kada įvyko iš naujo atradimas. Priešingu atveju žurnalas rodo tunelį, kuris tiesiog nustojo pranešti.

Pristatykite pranešimą ten, kur yra naudotojas

Privilegijuotas sistemos atgalinis iškvietimas nepaveldi darbalaukio sesijos pranešimų tarnybos. Žinutė, išsiųsta iš root lygio apdorojimo priemonės, gali dingti be klaidos, o tai sukuria pranešėją, kuris veikia tikrinant rankomis ir niekada praktiškai. Pristatykite į sesiją, kuri valdo darbalaukį, arba leiskite darbalaukio klientui pačiam iškelti pranešimą.

Pirmenybę teikite esamam kliento pranešimui, jei jis jau apima atvejį, nes du pranešėjai vienam įvykiui yra palaikymo problema, o ne perteklius. Palaikymo įraše išsaugokite įvykio laiką, profilį ir priežastį, o slaptažodžius ir visus profilius palikite už jo ribų. Prisiminkite, kas yra pranešimas: stebimos būsenos ataskaita, o ne vykdymo mechanizmas, nes srauto blokavimas, kai tunelio nėra, yra atskira politika su savo įgyvendinimu.