Megfelelő tervezés api, amit „egy”, „sok”, „nulla” és a „semmi”
- 31.07.15 07:07 •
- ph_piter •
- • # 263895
- • Habrahabr
- 6 •
- 14109
- mint a Forbes, csak jobb.
Szia, rendszeres és alkalmi olvasók.
Ma szeretnénk nyújtani Önnek egy érdekes cikket API tervezés és a kapcsolódó buktatókat. Ne kérdezd, hogy hogyan jöttünk át rajta, egy kreatív keresés - ez nagyon nem lineáris.
Tervezésekor az API, meg kell vizsgálni számos tényező. Biztonság, következetesség, az állami vezetési stílus; úgy tűnik, a lista végtelen. Azonban az egyik tényező gyakran figyelmen kívül hagyott - ez a lépték kérdése. Ha az API tervezés kezdettől fogva úgy a skálán a rendszert, majd később (amikor a rendszer fog nőni) mentheti meg több száz órányi munkaidőt.
Néha nehéz megfogalmazni, mi az alkalmazás programozási felület (API). C technikai szempontból, hogy az API tartalmaz olyan funkciót hívják a kódot egy másik programozó. Beszélgetések, hogy milyen kódot „húz” az API, kívül esik e cikk, így feltételezzük, hogy az API - ez a legegyszerűbb funkciója.
Ebben a cikkben, speciálisan kiválasztott egyszerű példák csak illusztrálják a fő téma. Használt funkciókat a nyelv a C #, de az alapelvek itt megadott alkalmazható szinte minden nyelven, keretek és rendszerek. adatszerkezet egy cikket modellezett elosztott relációs stílusban használják számos kereskedelmi adatbázisok. Ismét a példák vannak írva ábra csak illusztráció, nem kezelik őket ajánlásokat.
Tegyük fel, hogy írsz egy egyszerű sorrendben feldolgozó rendszer az ügyfél számára, és már azonosított három fő csoportja (vagy ha úgy tetszik, „adatstruktúra”). Az Ügyfél osztály egy „idegen kulcs” (adatbázisban terminológia) az osztály címe, és a Rend osztályban van idegen kulcsok az osztályok címét és ügyfél. Az Ön feladata, hogy hozzon létre egy könyvtárat, hogy lehet használni a megrendelések feldolgozása (megbízások). Az első üzleti szabály ebben az esetben: az állam az ügyfél HomeAddress (Ügyfél) meg kell egyeznie, mint az állam BillingAddress Order (sorrendben). Ne kérdezd, miért, az üzleti szabályok általában nem értik az elme :)
Ellenőrizze, hogy a két terület azonos - nyilván könnyű feladat. Azt reméljük, hogy lenyűgözni a főnök, így kiagyalt határozatot kevesebb, mint 10 perc alatt. VerifyStatesMatch függvény egy logikai érték, amely a hívó meg tudja határozni fut egy üzleti szabályt, vagy sem. Te vezetsz le könyvtár néhány egyszerű teszt, és biztos, hogy kódfuttatást töltött átlagosan 50 ms, nem a készletek nem látszik. Fej nagyon elégedett, hogy a könyvtár más fejlesztők úgy, hogy használja a saját alkalmazásokat.
A következő napon, jött dolgozni, és van, hogy nyomon flaunts matrica: „Jöjjetek énhozzám sürgősen - Chef”. Azt is hiszem, hogy tegnap annyira sikeres volt, annak könyvtár, amely ma a legfőbb döntött, hogy díjat akkor még súlyosabb probléma. Hamarosan azonban úgy tűnik, hogy a kód komoly problémákat.
Nem a legjobb indul a nap, igaz? Úgy gondolom, hogy a legtöbb fejlesztő valaha hasonló helyzettel. Azt gondolta, hogy amit írt „ideális” könyvtár, és hozott egy halom problémát. De ha megfelelően megérteni, mi az „egy”, „sok”, „nulla” és a „semmi”, akkor megtanulják megkülönböztetni, ahol az API-ja nem felel meg az elvárásoknak a kollégák.
Az első útmutatás -, hogy megértsék, mi a „One”, és hogyan kell használni. Úgy értem, az API-nak mindenesetre kezelni egy részletben várható beviteli hiba nélkül. Az ilyen hibák elméletileg lehetséges, de azok közlése a hívó, akkor nem kell. „Nem nyilvánvaló?” - gondolná. Nos, vessünk egy példa, és fontolja meg, milyen hibák fordulhatnak elő, amikor megrendelések feldolgozása.
Ezek csak példák, úgyhogy kijavítani a kódot, és kész.
Menj vissza a fentebb ismertetett helyzet. Beszélnünk kell Bobnak. Bob panaszkodott, hogy a kód futása lassú, de az értéke 50 ms összhangban van az időtartam a várt rendszer architektúra. De kiderül, hogy Bob kezeli 100 megrendelések a legnagyobb felhasználó egy csomagban, így Bob ciklus végrehajtása céljából az eljárás kárba 5 másodpercig.
You. Bob, nem kapsz kódomat túl lassú? Úgy fordított a rendelés feldolgozását csak 50 ms.
Bob. Ügyfelünk Acme Inc. Ez megköveteli, hogy a megrendelések dolgoztuk csomag maximális sebesség. Azt kell, hogy szolgálja a 100 megrendelések úgy, hogy 5 másodperc - ez túl hosszú.
You. Ó, én nem tudom, hogy van, hogy a megrendelést csomagot.
Bob. Nos, ez csak Acme, ők is a legnagyobb ügyfél.
You. Nem mond semmit Acme, sem batch megrendelések
Bob. Az Ön kód nem hatékony feldolgozása több megrendelést ugyanabban az időben?
You. Ah ... igen, persze.
Világos, hogy mi történt és miért a kódot úgy tűnik, Bob „túl lassú”. Nem mond semmit sem arról Acme, sem kötegelt feldolgozás. Bob ciklus betölti a rendszeres osztály Ügyfél és valószínűleg betölteni 100-szor ugyanazt a rekordot cím. Ez a probléma könnyen megoldható, ha Ön egy sor megrendelések, hanem egy, plusz hozzá néhány egyszerű cache-t. Params kulcsszót C # van az ilyen helyzetekre.
Ha módosítja a függvény ezen a módon, kötegelt feldolgozás, Bob hirtelen felgyorsult. A legtöbb ilyen kihívásokat fog tűnni, mert akkor csak talál egy rekord egy ideiglenes cache azonosító (Dictionary).
Ha megnyitja az API a „sok” - és azonnal kell csatlakoztatni a határellenőrzés. Mi, például, ha valaki küld egy millió rendelést a módszer? Kiderült, van egy nagy számú lehetőségeket kívül ez az architektúra? Ez ebben az esetben hasznos, mint a képviselete a rendszer felépítése és az üzleti folyamatokat. Ha tudja, hogy a gyakorlatban szükség lehet kezelni több, mint 10 000 megrendelés, akkor magabiztosan átveszi az irányítást 50 000 Ily módon biztosítható, hogy senki sem lesz képes, hogy a rendszer egy hatalmas kihívás elfogadhatatlan.
Természetesen a lista a lehetséges optimalizáció nincs korlátozva, de a példa azt mutatja, hogyan lehet megszabadulni a felesleges munkát, ha az elejétől számíthatnak a „set” terméket.
Természetesen ellenőrizni minden utalást null - egy trükkös üzlet, és időnként túlzott intézkedés. Azonban semmilyen esetben nem hivatkozhat érkező információkat a forrás, hogy nem ellenőrzik. Ezért van, hogy ellenőrizze a null paraméterrel «megrendelésre», valamint másolatot a Rend belül nullára.
Rendszeresen ellenőrizze az null, akkor elkerülhető a bosszantó hívások kereső ügyfelek technikai támogatást és kérdezi, hogy mi a „objektum példányt.” Mindig inkább perebdet; jobb lesz az én függvény alapértelmezett és bejelentkezett az üzenetet (vagy figyelmeztetést küld), amelyet ártalmatlanítani eléggé hasznavehetetlen hiba „nem pont egy példányát egy tárgy.” Természetesen ez a döntés attól függ, hogy milyen típusú rendszer a kód fut a kliens vagy a szerver, stb A lényeg az, hogy a nulla lehet figyelmen kívül hagyni, de csak addig, amíg ez nem sül el.
MAGYARÁZAT: Hogy őszinte legyek, nem azt mondom, hogy az a feladata, hogy „idle”, ha esik érvénytelen állapotban van. Ha a nulla lehetőség a rendszer elfogadhatatlan, dob kivételt (például ArgumentNull .NET). Ugyanakkor bizonyos esetekben teljesen megakadályozza a visszatérést értelmes csend, és nincs szükség a kivételt. Így például a jelenlegi módszerek általában visszatér az érték, amely küldték őket, ha semmit sem tudnak tenni ezzel az értékkel. Túl sok tényező, amely nem teszi lehetővé, hogy az általános ajánlásokat, amikor szembe nulla.
You. John, amit át a kódom? Úgy néz ki, mint a rész-rendelés.
John. Ó, sajnálom. Nekem valamit a módszer nem szükséges, de más könyvtári követeli, hogy át paramétereket rendelés. Azt hiszem, ez a kód könyvtár. Nem működnek a megrendeléseket, de használjon más könyvtárak igényeit.
You. A könyvtár kell javítani: görbe, mint tervezték!
John. Tudja, hogy a könyvtár kifejlesztett szervesen üzleti célok - változtatni valamit. Matt írta, és ez ezen a héten nem lesz; Általában nem tudom, hogyan kell változtatni. Az Ön kódot nem ellenőrzi, hogy a bejegyzés érvényes?
You. Igen ... tényleg.
Remélem sikerült közvetíteni, hogy az olvasó a fő gondolata ennek a cikknek nem ez a helyzet, hogy a kódot vehet minden bemenő adatok minden gond nélkül. Végrehajtása során minden olyan funkciót, vagy API kell vizsgálni, hogyan kell használni ezt az API. A példánkban az eredeti funkciója nőtt 12-50 vonalak, bár mi nem azt, hogy ez a drasztikus változások. Minden kód, amit adunk, biztosítanunk kell a skálázhatóság, az irányítást határok, valamint a funkció kezeli bármelyik bemenet helyesen és hatékonyan.
A tárolt adatok mennyisége az utóbbi években jelentősen megnőtt, ezért a skála a bemeneti adatok növekedni fog, míg a minőségi adatok csak esik. Ha az elejétől jogot, hogy írjon az API, akkor fontos szerepet játszanak az üzleti növekedés, az alkalmazkodás a növekvő ügyfélszám, és a jövőben -, hogy mentse a tech support (és a fejfájás akkor kevesebb) költségeket.