Aanbevolen werkwijzen voor algemene ontwikkeling in Adobe Commerce
Dit onderwerp beschrijft de basislijn voor een gezond ontwikkelingsproces van Adobe Commerce. Hierin worden fundamentele processen, codeerbeginselen en ontwerpprincipes voor toepassingen beschreven om ontwikkelaars te begeleiden.
NOTE
Technische architecten van de Adobe gebruiken deze beste praktijken als referentie tijdens overeenkomsten met betrekking tot ontwikkeling.
Deze beste praktijken zijn ontwikkeld op basis van jarenlange ervaring met het ontwikkelen en uitvoeren van Commerce-projecten. De Adobe beveelt aan dat technische initiatieven deze beste praktijken volgen en dat u bestaande processen en code verbetert om met hen in overeenstemming te brengen.
Tekstconventies
De sleutelwoorden "MOET", "MOET NIET", "VEREIST", "DIENT", "DIENT NIET", "DIENT NIET", "AANBEVOLEN", "MAY", en "OPTIONEEL"in dit onderwerp moeten worden geïnterpreteerd zoals die in RFC 2119worden beschreven.
Proces
- Voordat met de projectactiviteiten wordt begonnen, moet overeenstemming worden bereikt over een welomschreven projectmethode. Het kan gaan om een methode voor de bestrijding van trommel, waterval of een andere methodologie of combinatie van methoden, mits deze gedefinieerd is.
- De ontwikkeling MOET NIET beginnen totdat het ontwikkelingsteam een vertakkingsstrategie voor het versiecontrolesysteem heeft.
- De ontwikkeling MOET NIET beginnen na de aftekening van technische specificaties, de aftekening van gebruikersartikelen en gebruiksgevallen en de aftekening van testgevallen is beschikbaar voor het ontwikkelingsteam.
- De ontwikkeling MAG NIET beginnen totdat ten minste een ontwikkelings- en kwaliteitscontroleomgeving beschikbaar is.
- De project-specifieke vereisten die voor ontwikkeling verplicht zijn te beginnen KUNNEN in a Definitie van Klaar worden gedocumenteerd.
- Afmelding DIENT te worden gedaan door een vertegenwoordiger van de klant die gemachtigd is om af te tekenen bij te leveren projecten.
- In de methoden van het Agile-project kunnen aanvullende vereisten volgen. Deze eisen dienen als nieuwe eisen te worden beschouwd en dienen dienovereenkomstig te worden vastgelegd, opgesteld en gepland.
- Alle ontwikkelingen MOETEN vóór de indiening door de ontwikkelaar functioneel worden getest.
- Alle ontwikkelingen MOETEN geautomatiseerde tests doorstaan voordat ze worden ingediend voor herziening van de code. Dit kan als geautomatiseerd proces na het creëren van trekkingsverzoek worden gevormd.
- Elke ontwikkeling MOET een technische architect of een ontwikkelaar met handmatige codecontrole doorstaan voordat deze voor kwaliteitsborging wordt ingediend.
- Alle ontwikkelingen MOETEN een kwaliteitsborging doorstaan voordat zij aan de klant worden geleverd.
- Projectspecifieke vereisten die verplicht zijn voor levering, kunnen worden gedocumenteerd in een "Definitie van Gereed".
Omgeving
- Alle ontwikkelaars MOETEN zelfde winde gebruiken. PhpStorm is de aanbevolen IDE voor Adobe Commerce-ontwikkeling.
- Alle ontwikkelaars MOETEN zich ontwikkelen en testen gebruikend de zelfde technologiestapel zoals die op de (toekomstige) productieservers wordt gebruikt. De versies van de software in deze technologiestapel MOETEN de belangrijkste en minder belangrijke versie van de software aanpassen die op de productieservers wordt geïnstalleerd. Zie systeemvereistenvoor details over de typische technologiestapel voor Adobe Commerce.
- De systeembeheerder of technische architect kan het team voorzien van een centraal onderhouden lokale ontwikkelomgeving om gelijke en actuele lokale omgevingen te verzekeren en te bevorderen.
- De ontwikkelaars en de ingenieurs QA MOETEN toegang tot de bevellijn, het gegevensbestand, en de logboekdossiers van het milieu hebben QA. Dit kan een verbinding van VPN vereisen.
Codeerstandaarden
- Alle code DIENT conventies in architectuur, methodologie en coderingsnormen te volgen. Creativiteit is gewenst in functie, niet in vorm.
- Alle code ZOU met de Gids van de Architectuur van Adobe Commerce{target="_blank} moeten in lijn zijn.
- Alle code ZOU aan de Adobe Commerce Coding Normenmoeten houden.
- Alle code ZOU aan de Technische Richtlijnen van Adobe Commercemoeten houden.
- Alle code ZOU de Beste praktijken van Adobe Commerce, indien van toepassing moeten uitvoeren.
- Alle code ZOU aan de normen van de Groep van de Interoperabiliteit van het PHP-Kader (FIG)moeten houden.
- Waar mogelijk, wordt het AANBEVOLEN om de Technische Toelichtingen van Adobe Commercerekening te houden.
- Alle integraties met externe systemen MOETEN integratietests hebben die het bedrijfsproces valideren.
- Alle modules MOETEN een testdekking hebben. Wat precies moet worden getest, DIENT te worden bepaald door het ontwikkelingsteam in samenwerking met de technische architect of de belangrijkste ontwikkelaar. Deze vaststelling dient te berusten op kwalitatieve maatregelen en niet op kwantitatieve maatregelen; een hoog percentage van de dekking van de code is geen indicator van succes en houdt evenmin een hoge kwaliteit van de code in. In plaats daarvan moet u het risico bepalen dat een deel van de code niet wordt gedekt door de waarschijnlijkheid en de ernst van de regressies in dat deel van het programma te beoordelen.
Versioning
De versies van de module MOETEN aan de Semantische Versioning 2.0.0 normnaleven.
De gebiedsdelen op de codebase van Adobe Commerce MOETEN de richtlijnen van de Afhankelijkheid van de Versie van de Module volgen.
HERZIENINGSCONTROLE
Verbintenissen MOETEN vergezeld gaan van zinvolle "commit messages".
Beveiliging
- niet-veilige functiesMOGEN NIET worden gebruikt.
- XSS-preventie strategieënZOU MOETEN worden toegepast.
- het Beleid van de Veiligheid van de InhoudZOU moeten worden toegepast.
- Nieuwe Adobe Commerce-instanties DIENEN te worden afgeleverd op de meest recente beveiligingsrelease van een versie die nog niet de datum "Einde van beveiligingscorrecties" heeft bereikt. Zie het Beleid van de Levenscyclus van de Software van Adobe Commerce.
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60