Multe idei de aplicații încep ca o soluție propusă: “Avem nevoie de o platformă pentru …—, “Trebuie să automatizezi asta sau “ar trebui să existe o aplicație pentru asta.” Astfel de propoziții pot marca o direcție bună. Ele nu sunt suficiente pentru dezvoltare. Între o idee interesantă și un produs viabil există decizii despre oameni, situații, date, limite și mai târziu de funcționare.
Prin urmare, cea mai importantă lucrare începe înainte de primul ecran. Care este adevărata problemă? Cum este rezolvată astăzi? Ce duce la erori sau creează incertitudine? Și cum ar putea un instrument digital să îmbunătățească situația?
O aplicație întreținută este mai mult decât un cod scris curat. Are un scop de înțeles, un model de date coerent și un domeniu de aplicare pe care o echipă îl poate gestiona chiar și după prima versiune.
Descrieți problema într-o situație observabilă
Managementul de proprietate este confuz este prea larg. Declaratia nu dezvaluie cine este afectat, nici ce fel de confuzie conteaza. “Detinatorii privati nu pot gasi in mod sigur cea mai recent inregistrata citire contor si fotografia sa in timp ce departe de casa. Ea numeste persoana, situatie, informatii si rezultatul dorit.
Definiţiile bune ale problemelor rămân iniţial independente de soluţie. Poate că o mai bună stocare existentă, un proces modificat sau o mică interfaţă web este suficientă. Oricine necesită imediat o tehnică specifică omite adesea modalităţi mai simple. Scopul analizei timpurii nu este de a justifica o aplicaţie, ci de a înţelege dacă şi unde ar fi utilă.
Ce pași fac oamenii astăzi? Ce instrumente folosesc? Unde se schimbă între hârtie, foi de calcul, mesaje și fotografii? Care sunt excepțiile? Este important nu doar să se solicite funcții dorite. Oamenii descriu soluții din experiența anterioară. Dificultățile observate explică mai bine ce are de făcut produsul.
Grupul țintă înseamnă, de asemenea: în mod conștient, nu pentru toți
Un produs pentru “persoane fizice și companii de toate dimensiunile” probabil că nu are încă un grup țintă clar. Diferite grupuri au termeni, riscuri și fluxuri de lucru diferite. O singură persoană nu are nevoie de management de rol. O echipă nu poate lucra în mod fiabil fără roluri și date comune.
O descriere de grup țintă utilă include, prin urmare, contextul de utilizare, experiența, frecvența și limitele. Are cineva de lucru singur sau împreună? Pe un smartphone sau la mai multe stații de lucru? Va fi deschisă aplicația zilnic sau numai atunci când are loc un anumit eveniment? Trebuie să funcționeze fără o rețea? Ce greșeli ar fi enervante, care ar avea consecințe grave?
Aceste întrebări afectează mai târziu aproape totul: navigare, stocare de date, model de securitate, texte de ajutor și model de afaceri. Delimitarea nu este pur marketing-orientare persona de lucru. Este o parte a specificației tehnice.
Găsirea celui mai mic proces complet
Un produs timpuriu ar trebui să fie mic, dar nu rupt. Dacă doriți să documentați un contor, de exemplu, aveți nevoie pentru a selecta proprietatea, introduce data și valoarea, opțional o fotografie, salva, găsi mai târziu și corecta. Pentru a construi doar un singur formular fără istorie sau corectarea erorilor ar fi mai puțin efort, dar nici un beneficiu complet.
Cea mai mică secvență completă conține începutul, mijlocul și sfârșitul, precum și cele mai importante abateri. Ce se întâmplă dacă permisiunea camerei lipsește? Poate fi salvată fără o fotografie? Cum arată o stare goală? Ce se petrece atunci când un număr este invalid sau cineva anulează? Se va reține intrarea după o întrerupere?
Doar atunci când această cale de bază este clară, funcţiile pot fi separate în mod semnificativ în ceea ce este necesar şi opţional. Ceea ce este nevoie este ceea ce face ca rezultatul să fie posibil sau protejează împotriva unei erori inacceptabile. Opţional este ce extinde confortul, variantele sau grupurile ţintă ulterioare. Această separare ar trebui verificată periodic, deoarece o opţiune aparent mică poate genera noi date şi state.
Prototipuri pentru a face deciziile vizibile
Un prototip este deosebit de valoros atunci când dezvaluie intrebari. Oare oamenii inteleg termenii folositi? Gasesc urmatorul pas? Lipsesc informatii inainte de a se putea decide? Se potriveste procedura cu situatia in care este folosit de fapt telefonul smartphone?
Prototipul nu trebuie să fie perfect vizual. Un design simplu clickable cu conținut realist arată adesea mai mult decât o prezentare lustruită plină de deținători de locuri. Nume reale, texte mai lungi, imagini lipsă și mai multe înregistrări face vizibil dacă aspectul și arhitectura informației ține în sus.
Prototipurile ar trebui să conțină, de asemenea, stări critice: nu există date, încărcare sau salvare erori, permisiune refuzată, offline, font foarte mare și acțiuni ireversibile. Oricine care demonstrează doar secvența ideală testează o poveste în loc de un produs.
În orientările sale privind interfața umană, Apple subliniază ierarhia, coerența și adaptarea la diferite ecrane. Aceste principii nu pot fi adăugate ca decorare la sfârșit. Ele influențează deja structura prototipului: Ce este conținutul, ce este acțiunea, ce informații rămân în prim plan și ce interacțiune este familiară pe platforma respectivă?
Modelul de date este decizia profesională pe termen lung
Suprafețele se pot schimba în mod semnificativ. Importanța datelor stocate rămâne adesea de ani de zile. Prin urmare, este util să se clarifice timpuriu care entități există în produs și modul în care acestea sunt legate. Este o cameră întotdeauna parte dintr-o unitate? Poate fi atribuit un document mai multor procese? Ce se întâmplă cu sarcinile atunci când un obiect este arhivat? Sunt sumele și măsurătorile monetare stocate exact?
Un model de date consistent împiedică aceleași informații să devină inconsecvente în mai multe locuri. Dezvoltatorii Android recomandă, printre altele, o sursă clară de date și limite clare de responsabilitate pentru arhitecturile aplicației. Aceste principii tehnice susțin o proprietate de domeniu: Atunci când informațiile se schimbă, trebuie să fie clar care reprezentare este autorizată ulterior.
Migrațiile aparțin, de asemenea, acestei decizii. De îndată ce există date reale, o nouă versiune nu poate redenumi sau șterge câmpurile dorite. Produsul necesită reguli privind modul în care statele mai în vârstă sunt transferate într-o nouă structură. Un prim proiect bun nu încearcă să prezică fiecare dezvoltare viitoare. Cu toate acestea, separă termeni de domeniu stabili de logica de suprafață pe termen scurt.
Protecția datelor începe cu problema de care sunt necesare date
Protectia datelor devine scumpa daca este verificata doar dupa implementare. Apoi permisiunile, serviciile externe si modelele de date sunt deja conectate. Privind mai devreme, ea poate simplifica domeniul de aplicare.
Aplicația are nevoie de un cont? Trebuie importat un contact complet sau este suficient pentru o persoană înregistrată manual? Accesul la locație este necesar permanent, doar pentru o singură acțiune sau nu? Trebuie să părăsească dispozitivul? Fiecare element de date care nu este colectat reduce suprafața, cazurile de eroare, munca de securitate și procesele ulterioare de ștergere.
Android recomandă minimizarea cererilor de permisiune şi, dacă este posibil, proiectarea funcţiilor în aşa fel încât acestea să poată face fără acces inutil. Dacă este necesară o permisiune, aceasta ar trebui să fie solicitată în contextul acţiunii concrete. O permisiune respinsă nu trebuie să facă automat întreaga aplicaţie inutilizabilă dacă este posibilă o alternativă raţională.
Protecția datelor acoperă întregul ciclu de viață: economisirea, afișarea, partajarea, exportul, susținerea și ștergerea. Stocarea locală necesită o strategie de rezervă. Datele cloud necesită protecția contului, reguli de acces și un proces de ștergere ușor de înțeles. Pentru furnizorii terți, trebuie să fie clar ce informații primesc și de ce.
Întreţinerea apare prin limite şi responsabilităţi
O bază de cod întreținebilă are module cu sarcini clare. Interfața coordonează interacțiunile, logica domeniului pune în aplicare reguli, iar stratul de date gestionează sursele și persistența. Atunci când accesul la rețea, prezentarea și regulile de afaceri sunt amestecate în aceleași componente, schimbări și teste devin mai dificile.
Numai separarea tehnică nu este suficient. Produsul are nevoie, de asemenea, limite de responsabilitate. Cine decide în termeni? Care parte a produsului este autoritate pentru un set de date? Ce promisiuni face produsul atunci când un serviciu extern nu reușește? Există o cale manuală? Ce nu este susținut în mod expres?
Fiecare dependenţă ar trebui să aibă un scop recunoscut. O bibliotecă poate accelera dezvoltarea, dar necesită actualizări şi monitorizare de securitate. Un serviciu cloud poate prelua munca complexă, dar creează costuri şi un punct de eşec. Un sistem intern oferă control, dar cere îngrijire permanentă. Menţinerea înseamnă alegerea conştientă a acestor obligaţii.
Documentaţia susţine această claritate atunci când explică deciziile. O listă lungă a fiecărui fişier îmbătrâneşte rapid. Mai valoroasă sunt descrierile scurte ale limitelor sistemului, fluxurile de date, regulile migraţiei şi motivele pentru care deciziile nu sunt evidente. Membrii noi ai echipei sau viitoarea ta persoană trebuie să înţeleagă de ce a fost construită o parte ca aceasta.
Testele urmăresc riscurile și căile reale
Un număr mare de teste automate nu dovedesc automat calitatea produsului. Factorul decisiv este dacă riscurile relevante sunt acoperite. Testele de unitate sunt potrivite pentru regulile de domeniu și calcule. Teste de integrare verifica interacțiunea de bază de date, servicii și migrații. Teste finale pot asigura căi de utilizare centrale. Teste manuale rămân importante pentru limba, ierarhia vizuală, orientare focalizare și situații care sunt dificil de automatizat pe deplin.
Testele ar trebui să funcționeze cu date realiste: nume lungi, liste goale, înregistrări mai vechi, valori zecimale neobișnuite, atașamente multiple și conexiuni întrerupte. Diferite dimensiuni ale ecranului și texte mari arată dacă un aspect este într-adevăr adaptabil. Cititorii de ecran și tastaturile fac vizibile slăbiciunile semantice pe care nu le arată o captură de ecran.
W3C WAI recomandă ca accesibilitatea să fie evaluată devreme și regulat și ca persoanele cu handicap să fie incluse într-o formă adecvată. Acesta este un bun principiu general de calitate: nu numai pentru a verifica versiunea terminată în raport cu o listă de verificare, ci pentru a include feedback-ul în cazul în care deciziile pot fi încă schimbate.
În special acțiunile riscante au nevoie de controale specifice. Ștergerea, restaurarea, statutul de cumpărare, export și permisiuni merită mai multă profunzime decât un cadru pur decorativ. Prioritizarea în funcție de impact și probabilitate este mai utilă decât necesită aceeași cantitate de testare peste tot.
Publicarea pas cu pas nu înseamnă publicarea neterminată
O primă versiune nu trebuie să conțină fiecare plan pe termen lung. Cu toate acestea, căile sale de bază promise ar trebui să fie complete, ușor de înțeles și rezistente. “Paș cu pas” descrie dezvoltarea domeniului de aplicare, nu scuza pentru lipsa de manipulare a erorilor sau responsabilitatea neclară a datelor.
Înainte de a elibera, produsul are nevoie de criterii verificabile: dispozitive și versiuni susținute, procese de bază testate, limite de produs de înțeles, magazin corect și texte juridice, suport accesibil, backup sau comportament de ștergere, și un plan pentru erori critice. Un grup de testare controlat poate arăta utilizare reală înainte de a se lua un angajament larg.
După publicare, feedback-ul nu devine automat intrări în foaia de parcurs. Feedback oferă dovezi cu privire la situații reale. Mai multe cereri pentru aceeași funcție pot arăta un model bază sau indică un proces existent pe care nimeni nu îl poate găsi. Echipele de produse ar trebui să înțeleagă problema, frecvența, grupul țintă și riscul înainte de a alege o soluție.
O versiune ulterioară poate adăuga noi capacități. Nu ar trebui să ascundă nucleul și să respecte datele existente. Migrația, compatibilitatea înapoiată și explicațiile modificate fac parte din funcție, nu din activitatea de curățare din aval.
Firul comun este rezultatul concret
De la prima observaţie la operaţiune, o întrebare simplă ajută: Această decizie îmbunătăţeşte experienţa de zi cu zi a grupului ţintă? Un prototip frumos, o arhitectură modernă sau o listă mare de funcţii poate fi fiecare valoroasă. Cu toate acestea, fără conexiunea la problemă, acestea optimizează cu uşurinţă sistemul greşit.
O aplicație întreține mai multe tipuri de claritate: o problemă reală, un grup țintă limitat, procese de bază complete, un model de date coerent, căi de date minime și ușor de înțeles, responsabilități testabile și limite de produse oneste. Această lucrare este mai puțin spectaculoasă decât primul ecran clickable. Cu toate acestea, decide dacă o idee devine un instrument care poate fi dezvoltat în continuare coerent după mai multe versiuni.
Surse și informații suplimentare
- Android Developers: Guide to app architecture – modele de date, o singură sursă de adevăr, testabilitate și limite de responsabilitate.
- Android Developers: Data layer – rolurile și delimitarea stratului de date.
- Android Developers: Minimize permission requests – minimizarea datelor și permisiuni solicitate în context.
- Apple Human Interface Guidelines – ierarhie, consecvență, aspect și interacțiuni adecvate platformei.
- W3C WAI: Planning and Managing Web Accessibility – integrarea timpurie și continuă a accesibilității și evaluării.
