Tee säännöllisistä lausekkeista testattavia ja ymmärrettäviä

TL;DR: Voit jakaa monimutkaisen validoinnin regexin pienempiin osiin testataksesi jokaista osaa erikseen ja raportoidaksesi tarkat virheet.

Ongelmat ratkaistu 😔

• Vaikeasti testattavat säännölliset lausekkeet
• Epäselvä virheilmoitus
• Painajaisten virheenkorjaus
• Huollon haasteita
• Liian pitkät jonot ja menetelmät
• Yllättämättömiä ilmaisuja
• Primitiivinen pakkomielle
• Virheeristys
• Tietosiilot
• Vanhentuneet kommentit
• Virheet ilman empatiaa loppukäyttäjiä kohtaan

Aiheeseen liittyvä koodi haisee 💨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxvii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xx-we-have-reached-100

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-ix-7rr33ol

Vaiheet 👣

1. Analysoi regex tunnistaaksesi sen loogiset komponentit.
2. Jaa säännöllinen lauseke pienempiin, nimettyihin alikavioihin kullekin komponentille.
3. Kirjoita kullekin alakuviolle yksikkötestit varmistaaksesi, että se toimii oikein.
4. Yhdistä testatut alamallit täydelliseksi validointilogiikaksi.
5. Muokkaa koodi uudelleen, jotta saat selkeät virheilmoitukset jokaisesta viallisesta osasta.

Esimerkkikoodi 💻

Ennen 🚨

 function validateURL(url) { const urlRegex = /^(https?:\/\/)([a-zA-Z0-9.-]+\.[a-zA-Z]{2,})(\/.*)?$/; // Criptic and untesteable return urlRegex.test(url); }

👉 jälkeen

 // Step 1: Define individual regex components const protocolPattern = /^(https?:\/\/)/; const domainPattern = /^[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; const pathPattern = /^\/.*$/; // Step 2: Write unit tests for each component describe("Protocol Validation", () => { test("should pass for http://", () => { expect(protocolPattern.test("http://")).toBe(true); }); test("should pass for https://", () => { expect(protocolPattern.test("https://")).toBe(true); }); test("should fail for invalid protocols", () => { expect(protocolPattern.test("ftp://")).toBe(false); }); }); describe("Domain Validation", () => { test("should pass for valid domains", () => { expect(domainPattern.test("example.com")).toBe(true); expect(domainPattern.test("sub.domain.org")).toBe(true); }); test("should fail for invalid domains", () => { expect(domainPattern.test("example")).toBe(false); expect(domainPattern.test("domain..com")).toBe(false); }); }); describe("Path Validation", () => { test("should pass for valid paths", () => { expect(pathPattern.test("/path/to/resource")).toBe(true); expect(pathPattern.test("/")).toBe(true); }); test("should fail for invalid paths", () => { expect(pathPattern.test("path/to/resource")).toBe(false); expect(pathPattern.test("")).toBe(false); }); }); // Step 3: Validate each part and report errors function validateURL(url) { if (!protocolPattern.test(url)) { throw new Error("Invalid protocol. Use http:// or https://."); } const domainStartIndex = url.indexOf("://") + 3; const domainEndIndex = url.indexOf("/", domainStartIndex); const domain = domainEndIndex === -1 ? url.slice(domainStartIndex) : url.slice(domainStartIndex, domainEndIndex); if (!domainPattern.test(domain)) { throw new Error("Invalid domain name."); } const path = url.slice(domainEndIndex); if (path && !pathPattern.test(path)) { throw new Error("Invalid path."); } return true; } // Step 4: Add integration tests for the full URL validation describe("Full URL Validation", () => { test("should pass for valid URLs", () => { expect(validateURL("https://lesluthiers.com/tour/")).toBe(true); expect(validateURL("https://bio.lesluthiers.org/")).toBe(true); }); test("should fail for invalid URLs", () => { expect(() => validateURL("ftp://mastropiero.com")). toThrow("Invalid protocol"); expect(() => validateURL("http://estherpsicore..com")). toThrow("Invalid domain name"); expect(() => validateURL("http://book.warren-sanchez")). toThrow("Invalid path"); }); });

Kirjoita 📝

• [x] Puoliautomaattinen

Turvallisuus 🛡️

Tämä uudelleenjärjestely on turvallista, jos noudatat ohjeita huolellisesti.

Kunkin komponentin testaaminen varmistaa, että huomaat virheet ajoissa.

Miksi koodi on parempi? ✨

Refaktoroitu koodi on parempi, koska se parantaa luettavuutta, ylläpidettävyyttä ja testattavuutta.

Regexin jakaminen pienempiin osiin helpottaa kunkin osan toiminnan ymmärtämistä.

Voit myös ilmoittaa tietyistä virheistä, kun vahvistus epäonnistuu, mikä auttaa käyttäjiä korjaamaan syötteensä.

Tämä on myös loistava tilaisuus soveltaa Test-Driven Development -tekniikkaa, joka lisää asteittain monimutkaisuutta ottamalla käyttöön uusia alaosia.

Kuinka se parantaa suuntaa? 🗺️

Jakamalla säännöllisen lausekkeen pienempiin, merkityksellisiin osiin luot läheisemmän yhdistämisen tosielämän vaatimuksiin (esim. "URL-osoitteella on oltava kelvollinen protokolla") ja koodin välille.

Tämä vähentää epäselvyyttä ja varmistaa, että koodi heijastaa ongelma-aluetta tarkasti.

Rajoitukset ⚠️

Tämä lähestymistapa saattaa lisätä kustannuksia hyvin yksinkertaisille regex-malleille, joissa niiden hajottaminen olisi tarpeetonta.

Refaktoroi tekoälyllä 🤖

Voit käyttää tekoälytyökaluja säännöllisen lausekkeen komponenttien tunnistamiseen.

Pyydä tekoälyä selittämään, mitä kukin regexin osa tekee, ja opastaa sitten jakamaan se pienempiin, testattaviin osiin. Voit esimerkiksi kysyä: "Mitä tämä regex tekee?" ja seuraa "Kuinka voin jakaa sen pienempiin osiin?".

On vuosi 2025, yhdenkään ohjelmoijan ei pitäisi enää kirjoittaa uusia säännöllisiä lausekkeita .

Sinun tulisi jättää tämä mekaaninen tehtävä tekoälylle.

Suositeltu kehote: 1. Analysoi regex tunnistaaksesi sen loogiset komponentit.2. Jaa säännöllinen lauseke pienempiin, nimettyihin alikavioihin jokaiselle komponentille.3. Kirjoita kullekin alakuviolle yksikkötestit varmistaaksesi, että se toimii oikein.4. Yhdistä testatut osamallit täydelliseen validointilogiikkaan.5. Muokkaa koodi uudelleen, jotta saat selkeät virheilmoitukset jokaisesta viallisesta osasta.

Tunnisteet 🏷️

• Testattavuus

Taso 🔋

• [x] Keskitaso

Aiheeseen liittyvät uudelleenjärjestelyt 🔄

Katso myös 📚

Kiitos 🙏

Kuva Gerd Altmann Pixabaysta

Tämä artikkeli on osa Refactoring-sarjaa.