Projektbeschreibung
ÜbersetztWir verkaufen Computerhardware online, und die Kunden verwenden einen Build-Konfigurator, um ein Motherboard, einen Prozessor, Speicher und andere Teile vor dem Checkout auszuwählen. Momentan gibt es nichts, was einen Käufer daran hindert, eine CPU und ein Motherboard mit unterschiedlichen Sockeln oder Speicher, der nicht mit dem unterstützten Typ des Boards übereinstimmt, zu kombinieren, und wir erfahren erst, nachdem die Bestellung zurückgeschickt wird, um eine Rückerstattung zu erhalten. Wir benötigen einen Freelancer, der eine Kompatibilitäts-Engine in unseren Konfigurator einbaut, die vor dem Checkout auf nicht übereinstimmende Teile hinweist.
Die Kernaufgabe ist eine Spezifikationsdatenbank, die Sockel, Chipsätze, Speichertypen, Formfaktoren und Leistungsanforderungen abdeckt, die in Regeln integriert sind, die vergleichen, was bereits im Build ist, mit jedem neuen Teil, das hinzugefügt wird. Wenn zwei Teile nicht funktionieren, sollte das Widget erklären, warum, anstatt einen generischen Fehler anzuzeigen, und stattdessen eine passende Kategorie vorschlagen. Grenzfälle, wie ein Kühler, der technisch passt, aber fast keinen Platz lässt, sollten ebenfalls gekennzeichnet werden.
Wir sind offen für verschiedene Ansätze: clientseitige Regeln, die aus unserem Katalog gespeist werden, oder einen kleinen Dienst, den der Storefront bei jeder Änderung des Builds aufruft. Was zählt, ist Geschwindigkeit, Genauigkeit und eine Möglichkeit, die Regeln selbst zu aktualisieren, wenn neue Komponenten erscheinen.
Was wir erwarten:
— Überprüfungen von Sockel, Chipsatz, Speichertyp/-geschwindigkeit und physischer Passform
— klare Warnungen, die an die spezifischen konfliktierenden Teile gebunden sind
— eine bearbeitbare Regel-Tabelle, keine fest kodierte Logik
— Hinweise zum Hinzufügen neuer Komponentenfamilien später
Die Kernaufgabe ist eine Spezifikationsdatenbank, die Sockel, Chipsätze, Speichertypen, Formfaktoren und Leistungsanforderungen abdeckt, die in Regeln integriert sind, die vergleichen, was bereits im Build ist, mit jedem neuen Teil, das hinzugefügt wird. Wenn zwei Teile nicht funktionieren, sollte das Widget erklären, warum, anstatt einen generischen Fehler anzuzeigen, und stattdessen eine passende Kategorie vorschlagen. Grenzfälle, wie ein Kühler, der technisch passt, aber fast keinen Platz lässt, sollten ebenfalls gekennzeichnet werden.
Wir sind offen für verschiedene Ansätze: clientseitige Regeln, die aus unserem Katalog gespeist werden, oder einen kleinen Dienst, den der Storefront bei jeder Änderung des Builds aufruft. Was zählt, ist Geschwindigkeit, Genauigkeit und eine Möglichkeit, die Regeln selbst zu aktualisieren, wenn neue Komponenten erscheinen.
Was wir erwarten:
— Überprüfungen von Sockel, Chipsatz, Speichertyp/-geschwindigkeit und physischer Passform
— klare Warnungen, die an die spezifischen konfliktierenden Teile gebunden sind
— eine bearbeitbare Regel-Tabelle, keine fest kodierte Logik
— Hinweise zum Hinzufügen neuer Komponentenfamilien später
Webentwicklung Bargeld, Banküberweisung
