Exponential bewerten
Diese Seite richtet sich an Ingenieure, denen die Frage "Sollen wir auf Exponential aufbauen?" gestellt wird. Sie zerlegt diese Frage in kleinere, die das Repository und die Dokumentation beantworten können, sodass das Ergebnis auf Belegen statt auf Eindrücken beruht. Schreiben Sie die Antworten mit ihren Quellen auf; die Checkliste für Design-Reviews ist eine Vorlage für das Ergebnis.
Inhalt
- Eine Testinstallation aufsetzen
- Die Fragen, nach Bereich
- Die eigenen Standangaben des Projekts lesen
- Abzuwägende Risiken
Eine Testinstallation aufsetzen
Bewerten Sie an einer echten Installation, nicht an Screenshots. Am schnellsten geht es mit SQLite, das keinen Datenbankserver braucht:
composer install
./console exp:install --helpexp:install verwendet SQLite, wenn kein --db angegeben ist (Datenbankunterstützung). Das
Installationsbuch beschreibt jede Installationsmethode (Eine Installationsmethode wählen).
Liefern Sie sie mit Velocity aus, um die empfohlene Laufzeitumgebung zu sehen (Anwendungsserver).
Die Fragen, nach Bereich
| Bereich | Frage | Wo Sie die Antwort finden |
|---|---|---|
| Eignung | Bildet das Inhaltsmodell unsere Daten ab (typisierte Attribute, Versionen, Übersetzungen, Beziehungen, Platzierungen im Baum)? | Das Inhaltsmodell für Ingenieure |
| Eignung | Welches Produkt der Familie brauchen wir, und enthält es die Teile, die wir brauchen? | Was Exponential ist |
| Laufzeit | Welche PHP-Versionen und -Erweiterungen haben unsere Server? | composer.json, Anforderungen |
| Laufzeit | Welcher Server wird es ausliefern? | Anwendungsserver |
| Daten | Welche Datenbank, und wird sie in der CI getestet? | Datenbanken: eine wählen und betreiben |
| Leistung | Was kostet eine gecachte und eine ungecachte Seite auf unserer Hardware? | Leistungsmessung und Benchmarks |
| Skalierung | Brauchen wir mehrere Webknoten, und was muss geteilt werden? | Skalierung und Clustering |
| Sicherheit | Was sind die Standards, und wie werden Schwachstellen gemeldet und behoben? | Sicherheitstechnik im Überblick |
| Integration | Welche APIs brauchen unsere anderen Systeme? | API-Design: REST, ezjscore und Headless |
| Qualität | Was prüfen die CI und die lokalen Gates? | CI-Gates |
| Wartung | Was zählt als brechende Änderung, und wie wird sie angekündigt? | Richtlinie zur Rückwärtskompatibilität |
| Releases | Wie oft erscheinen Releases, und wie werden sie nummeriert? | Release Engineering, doc/changelogs/ |
| Lizenz | Ist die GNU GPL, Version 2 oder später, damit vereinbar, wie wir unseren Code verbreiten? | LICENSE, Beiträge an das Projekt |
Die eigenen Standangaben des Projekts lesen
Die Standardseiten in doc/eng-us/standards/ stufen das Projekt gegenüber öffentlichen Standards als Complies,
Partly complies, Does not comply oder Unverified ein und listen bekannte Lücken. Sie sind die ehrlichste
einzelne Quelle für eine Bewertung, weil sie benennen, was fehlt:
- Sicherheitsstandards: OWASP Top 10, ASVS, CSP.
- Quellcodeverwaltung und Releases: Branch-Schutz und signierte Commits sind als Lücken aufgeführt.
- Standards für Datenbanken und SQL und Tests und CI.
- Standards zur Internationalisierung und Barrierefreiheit.
Abzuwägende Risiken
- Geerbter Code. Der Kernel ist alt und groß; PHPStan läuft auf Stufe 1 mit einer Baseline der Befunde, die bei der Einführung der Prüfung bestanden (Mit technischen Schulden umgehen).
- Datenbank-Updates von Hand bei alten Installationen. Seit 6.0.15 wenden
exp:upgradeund die Migrationen (exp:migration:migrate) jede Änderung an und halten sie fest; eine Installation, die von Hand mit den SQL-Updatedateien aktualisiert wurde, hat keine Aufzeichnung, welche Anweisungen ausgeführt wurden (Schemaänderungen und Migrationen). - Richtlinie, nicht Durchsetzung. Einige Repository-Regeln (kein Force-Push, Merge-Stil) sind Richtlinien ohne Branch-Schutz (Quellcodeverwaltung und Releases).
- Ein kleineres Ökosystem als die größten PHP-Frameworks. Prüfen Sie den Erweiterungskatalog auf das, was Sie brauchen, bevor Sie planen, es zu schreiben (Der se7enxweb-Erweiterungskatalog).
Verwandte Seiten
- Exponential für Softwareingenieure
- Checkliste für Design-Reviews
- Häufige Fragen von Softwareingenieuren
- Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.
Werden Sie Exponential-Partner
Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.