La velocità di spedizione è direttamente proporzionale alla qualità della struttura dei dati, specialmente nell'era in cui l'interfaccia utente può essere sempre più considerata un bene effimero. Più concretamente, questo include: - il tipo di archivio che utilizzi, ad esempio relazionale, grafico, ecc. - il modo in cui strutturi i tuoi dati in entità e relazioni - il modo in cui catturi le informazioni, ad esempio potresti voler memorizzare uno stato come booleano (ad esempio is_disabled) oppure potresti scegliere di dedurre queste informazioni da un timestamp (ad esempio disabled_at), entrambi hanno vantaggi e svantaggi - il modo in cui colleghi i dataset cross-platform, ad esempio database, archiviazione, log, ecc. - il modo in cui strutturi la tua API, costruisci query e consumi dati Essere data-first è un codice segreto per aumentare la tua velocità di spedizione. Decisioni sbagliate sui dati possono essere estremamente dolorose da annullare e quando inizi a vederle chiaramente, non puoi mai tornare indietro.
dennis
dennis5 lug 2025
Più progetto/costruisco, più mi rendo conto: La struttura dei dati sbagliata è come un'attaccatura dei capelli sfuggente. Sei cotto. Cercare di coprirlo rende le cose ancora peggiori Ho parlato con altri fondatori che concordano sul fatto che la struttura dei dati è compito del CEO. Ogni ingegnere sa di dover evitare le migrazioni quando possibile. Un posto facile per scopare l'interfaccia utente è la tabella degli account. Questo richiede alle aziende in scala +6mo per essere risolto. Quasi sicuro rampa/nave lineare veloce perché qui hanno commesso meno errori.
51,43K