Koodin laatukuvioita

Lue lisää Hyvin rakennettujen resurssien ja kustannusten optimoinnista → Koodiorganisaatio

Tämä yhdistetty kuvion sivu kattaa resurssien optimoinnin koodin laadun ja ylläpitokäytännöt. Se sisältää ohjeita vakiomuotoisiin vs mukautettujen koodien päätöksiin, tekniseen velkojen hallintaan, suunnittelun standardeihin, dokumentaatiokäytäntöihin ja hallintaan. Nämä kuviot auttavat ylläpitämään kehitysnopeutta, vähentämään virheiden määrää ja mahdollistamaan ratkaisun pitkäaikaisen kestävän kehityksen.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
Suorituskyky skaalassa	✅ Testaus vahvistaa, että deklaratiiviset ratkaisut täyttävät suorituskykyvaatimukset ennustetuissa datamääriin. Testaaminen Full Copy -sandboxissa realistisella datalla vahvistaa skaalattavuuden ennen tuotantoympäristön käyttöönottoa.
Huolto-analyysi	✅ TCO-analyysi vertaa deklaratiivisten vs mukautettujen lähestymistapojen pitkäaikaista huoltoa, mukaan lukien päivitysvaatimukset, testausvaatimukset ja taitovaatimukset tuleville tiimeille.
Sekoitettu lähestymistapa -arkkitehtuuri	✅ Ratkaisut yhdistävät deklaratiivisia ja ohjelmallisia lähestymistapoja tarvittaessa. Kulku orkestroi yleisen logiikan, kun taas Apex käsittelee monimutkaisia laskutoimia. Kaavakentät laskevat yksinkertaisia johdantoja, kun Apex käsittelee joukkotoimintoja.
AppExchange	✅ Ennen kuin laadit mukautettua koodia, arvioi olemassa olevat AppExchange, jotka tarjoavat samankaltaisia ominaisuuksia. Asiakirjojen arviointitulokset, mukaan lukien tarkastetut paketit, kapasiteetin aukot ja TCO-vertailu.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
rästityöt näkyvissä	✅ Tekniset velkojen kohteet, joita seurataan rästitilassa selkeillä otsikoilla, asiayhteydellä, joka selittää, miksi koodia on parannettava, sen poistamisen liiketoimintavaikutuksista ja arvioiduista korjaustoimista. Näkyvää velkaa ei voi priorisoida tai hallita.
Asteittainen parannus	✅ Ominaisuuden kehityksen aikana käytetty Boy Scout -sääntö: jätä koodi paremmin kuin löytyi. Tiimit korvaavat velkoja asteittain asiaan liittyvien ominaisuuksien työn aikana sen sijaan, että ne vaativat suuria erillisiä refaktorointiprojekteja. Koodin tarkastukset vahvistavat asteittaiset parannukset.
Ennaltaehkäisy ennen korjausta	✅ CI/CD:n laatuportaalit noudattavat standardeja ennen kuin koodi saavuttaa tuotantoympäristön. Koodinlukija, ApexGuru ja monimutkaisuustilastot, jotka on integroitu noutopyyntöjen vahvistukseen. Ongelmien estäminen estää yhdistämisen ennen kuin ne ratkaistaan.

Anti-Mallit

Mistä etsiä	Miltä huono näyttää
Rästityöt-ominaisuuden hallinta	⚡️ Tekninen velka, joka hyväksyttiin suullisesti, mutta jota ei koskaan seurattu rästitilassa. Ei näkyvyyttä velkojen kertymiseen. Velkojen korvaaminen lykättiin aina ominaisuuden työn puolesta. Nopeus laskee vähitellen, joten tiimit eivät voi selittää syytä.
Laadun portin ohitus	⚡️ CI/CD-laatua koskevat portit ohitetaan usein aikataulun paineiden alaisena, jotta ne korjataan myöhemmin. “Myöhemmin” ei koskaan tapahdu. Koodinlukijan virheet on merkitty tunnetuiksi ongelmiksi ja ohitettu. Monimutkaisuuksien kynnysarvot korotettu huonojen toteutusten mukaisesti.
Ei korjauskapasiteettia	⚡️ 100 % ominaisuuksiin kohdistetusta sprint-kapasiteetista, jonka kapasiteetti on nolla teknistä velkojen korvaamista varten. Velka kerääntyy määrittämättömästi. Suuret refaktorointiprojektit vaaditaan 18–24 kuukauden välein, jotka kuluttavat kokonaisia vuosineljänneksiä.
Kokoonpanon velka	⚡️ Mukautetut metadatatyypit ja mukautetut asetukset kerääntyvät ilman puhdistusta. Käyttämättömät kokoonpanot säilyvät määrittämättömästi. Tuotantoympäristössä on 50 metadatatietuetta, mutta niitä käytetään vain 12. Ei dokumentaatiota, joka selittäisi kokoonpanoarvojen käyttötarkoitusta.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
Käynnistimen arkkitehtuuri	✅ Käynnistimen käsittelijän kuvio otettu käyttöön yhdenmukaisesti: ohut käynnistimet delegoivat käsittelijäluokkiin, käsittelijäluokat organisoivat logiikkaa käynnistimen kontekstin perusteella (ennen lisäämistä, päivityksen jälkeen), selkeät metodin nimet paljastavat käyttötarkoituksen. Käynnistimien tiedostoissa ei ole liiketoimintalogiikkaa.
Palvelutasojen toteutus	✅ Liiketoimintalogiikka, joka on sisällytetty palveluluokkiin, jotka ovat erillään ohjaimista, käynnistimistä ja erän syöttöpisteistä. Palveluluokkia voidaan käyttää uudelleen useissa syöttöpisteissä ilman identtisiä tietueita. Tyhjennä nimeämiskäytäntö (AccountService, OrderProcessor).
valitsimen kuvio	✅ SOQL-kyselyt, jotka on keskitetty valintaluokkiin per objekti (AccountSelector, OpportunitySelector). Valintatavat palauttavat yhdenmukaisia kenttäjoukkoja. LDV-optimoinnin muutokset, jotka otetaan käyttöön kerran, vaikuttavat kaikkiin kyselyihin.
Säiliön kuvio	✅ Abstrakti datan käyttöoikeus käyttöliittymien takana, joka sallii testauksen esimerkkidatalähteillä. Säiliötoteutukset sisältävät kyselyiden rakennus-, välimuisti- ja optimointistrategioita. Liiketoimintalogiikka riippuu säiliöiden rajapinnoista, ei konkreettisista toteutuksista.
Komponenttien suunnittelun standardit	✅ Lightning noudattavat yhden vastuun periaatetta, paljastavat kokoonpanolle ominaisuuksia, lähettävät tapahtumia ylätason viestintää varten, jotka on suunniteltu koostumusta ja uudelleenkäyttöä varten. Komponenttikirjasto, joka on dokumentoitu käyttöesimerkkeillä.
Koodiorganisaatio	✅ Looginen paketin rakenne ryhmittelee liittyviä luokkia. Erota toimialueen logiikka, datan käyttöoikeudet, API-päätepisteet ja integraatiosovittimet toisistaan. Pakettien sidonnaisuudet kulkevat yhdessä suunnassa.

Anti-Mallit

Mistä etsiä	Miltä huono näyttää
Käynnistimet	⚡️ Kaikki liiketoimintalogiikka upotetaan suoraan käynnistimen tiedostoihin, joissa on syvällisesti sisäkkäisiä ehtoja, ei huolenaiheiden erottamista, ei käsittelijäluokkia. Yli 300 rivikäynnistimen tiedostoa, jotka yhdistävät vahvistus-, liiketoimintalogiikka- ja integraatiopuheluita. Tehokasta testaamista ei ole mahdollista.
Kysely silmukassa	⚡️ Iterointisulkeissa suoritetut SOQL-kyselyt. Toimii pienien datamäärien kanssa, mutta rikkoo 100 SOQL-kyselyn rajoitusta joukkotoimintojen käsittelyssä. Löydetään vain, kun joukkodatan lataukset käynnistyvät tuotantoympäristössä.
DML silmukassa	⚡️ DML-lausekkeet (insert, update, delete) suoritetut iterointisulkeissa. Rikkoo 150 DML-lausekkeen rajoituksen joukkotoiminnoilla. Jokainen tietue käsittelee erillisen tietokantatransaktion tehokkaan joukkokäsittelyn sijaan.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
Arkkitehtuurin päätöstyötietueet	✅ Merkittävät arkkitehtuuripäätökset, jotka on dokumentoitu versioiden hallintaan tallennetuissa ADR-osoitteissa. ADR-raportit sieppaavat asiayhteyden (liiketoiminnan edistäjät, tekniset rajoitukset), päätöksen (mitä valittiin), harkitut vaihtoehdot (miksi ne hylättiin) ja seuraukset (liiketoimet, uudelleenkäynnin ehdot).