Wanneer je een app ontwerpt, wat komt er dan meestal in je op? Is het het architecten van de hele app met behulp van tools zoals Figma voor UX (gebruikerservaring) ontwerp of Lucid Chart voor het ontwerpen van het ERD (entiteit-relatiediagram)? Afhankelijk van wat er in je opkomt, blijft het feit dat er een concept aan de orde is en dat dit een daadwerkelijke weergave inhoudt van wat je van plan bent te bouwen.
Het eerste wat je moet doen is plannen hoe deze app ontworpen moet worden. Tools zoalsJirateam-beheerde projecten kunnen helpen bij het snel opzetten van een project dat je kunt gebruiken om de stappen te documenteren en de gegeven sprints te plannen om te weten hoe het project zou vorderen. Dit geeft je ook toegang tot connectors zoals Github waar, wanneer codes worden gecommit, ze kunnen worden gekoppeld aan een specifieke taak binnen de projectfase om deze ofwel te sluiten of naar de volgende taak te gaan. Dit houdt elke belanghebbende of teamlid op de hoogte van wat er is gedaan versus taken die nog niet zijn gedaan.
Nu je met iets bent begonnen, hoe zit het met de gegevens van de app of welke database kan worden gebruikt?
" Ik geef de voorkeur aan het visualiseren van de datatypes van wat mijn app kan doen, vooral bij het gebruik van een database zoals PostgreSQL. "
Ik denk dat het gebruik van een ERD om een idee te krijgen van hoe de tabellen eruit zouden zien een visueel gevoel geeft van hoe het kan worden ontworpen. Dit brengt me bij de titel van dit artikel, wat zijn de dingen om te overwegen bij het ontwerpen van je gebruikersbasis? Als ontwikkelaar of iemand die apps ontwikkelt, is het cruciaal dat je de juiste datastructuur selecteert om binnen een database te gebruiken. Dit komt met ervaring om onmiddellijk te begrijpen wat te doen, maar met de juiste architectuur kun je dezelfde stap bereiken.
In verschillende apps die ik heb ontworpen, begin ik meestal met een gebruikersrepresentatie. Ik moet weten wat een gebruiker is en hoe ik verschillende objecten, die mogelijk niet bestaan in de initiële fase van het project, aan deze gebruikersentiteit kan koppelen. Dat is hoe ik het zou benaderen, maar natuurlijk zijn er verschillende manieren en strategieën. Echter, volgens een goed architectonisch ontwerp, zou je kiezen voor praktijken die gestandaardiseerd zijn en een efficiënte inzet van tijd en moeite bieden. Dat gezegd hebbende, terug naar de gebruikersrepresentatie, het construeren van een goed model voor een gebruiker is essentieel voor een goed app-ontwerp. Als je niet kunt begrijpen hoe een typische gebruiker in de app eruit zou zien, dan kan de app een blokkade hebben die later in de ontwikkelingsfase een probleem kan vormen.
Ten tweede moet je nadenken over beveiliging en naleving, hoe kan de app compliant zijn en tegelijkertijd ervoor zorgen dat de gegevens die worden opgeslagen veilig zijn. Welnu, in de huidige technologiesector geloof ik dat het gemakkelijker is geworden om slecht architectonisch ontwerp te detecteren in vergelijking met 10 jaar geleden. Hoewel, het feit blijft; vertrouwen de gebruikers die je app zullen gebruiken erop dat hun gegevens veilig zijn. Het antwoord zou eenvoudig genoeg moeten zijn als je de industrienormen voor het ontwerp van je database of je gegevensopslag hebt gevolgd. Ook is de vraag hoe ik mijn gegevens kan verwijderen altijd aanwezig als het gaat om naleving. Zou je weten hoe je dit proces moet aanpakken en wat het je kost in termen van de infrastructuur die je gebruikt? Ik vind dit deel leuk wanneer een "gebruiker" zijn gegevens verwijderd wil hebben, waarom niet toestaan dat ze de mogelijkheid hebben om hun gegevens onmiddellijk te wissen (tenzij dit nodig is om een geldige reden, dan moet dit duidelijk in je voorwaarden worden vermeld).
Een van de dingen die me door de jaren heen heeft geholpen bij het creëren van gebruikers binnen elke aangepaste app, is het definiëren hoe die gebruiker zou worden verwijderd. Ik kies meestal voor de "soft delete" benadering binnen de gebruikersbasis. Op deze manier bespaart het veel tijd en stelt het ook in staat om verschillende benaderingen te implementeren. Denk erover na, als een gebruiker zijn account wilde verwijderen, wat zijn dan de problemen die je waarschijnlijk zou kunnen tegenkomen door het simpelweg te verwijderen?
Waarschijnlijke problemen
- Verwijderen werkt niet.
- App of service kan crashen door kruisrelatietabellen.
- Geheugen van de database kan opraken (indien aanwezig).
Daarom zou de beste aanpak hier zijn om een "soft delete" mechanisme te gebruiken met de gebruikers tabel en een beleid binnen die tabel toe te passen dat voorkomt dat dezelfde gebruiker opnieuw wordt gebruikt of de gebruiker opnieuw kan worden gebruikt en uit de soft delete context kan worden verwijderd als ze hun verwijderverzoek binnen een bepaalde tijd annuleren. Een andere stap hier is dat je voor naleving de gebruikersgegevens op een later tijdstip kunt verwijderen als de bewaartermijn nog niet is verstreken. Dit moet worden vermeld in je voorwaarden over hoe lang je gegevensbewaartermijn is. Ten slotte is dit alles niet mogelijk als je geen manier hebt om altijd te controleren wanneer een gebruiker is verwijderd of als een gebruiker die al in soft delete is, weer actief moet zijn.
Dit zou waarschijnlijk betekenen dat je geplande verzoeken op je service kunt uitvoeren die deze taken controleren.Rediskan hier worden gebruikt, maar een andere tool die nog beter kan helpen isApache Airflow. Je kunt eenvoudig aanpassen hoe je applicatie of service functioneert door selectief elke taak uit te voeren die is gepland. Dit doet het efficiënt en biedt statistieken over het succes- of faalpercentage.
In wezen is de juiste manier om een gebruiker binnen een aangepaste app te verwijderen altijd het gebruik van een soft delete-mechanisme en vervolgens de gebruiker in te plannen voor verwijdering op een later tijdstip, volgens het retentiebeleid dat je hebt binnen de T&C van de app.