Mă gândeam zilele trecute ce puncte ar trebui să acoperi pentru a face un soft perfect. Aici, prin perfect, mă refer nu numai la îndeplinirea exactă şi completă a funcţiilor pentru care acel soft a fost conceput, nici la oferirea către utilizator a unei interfeţe intuitive, uşor de folosit, complet ergonomică, şi aşa mai departe. Mă refer în schimb la abilitatea soft-ului de a face faţă cu brio în orice condiţii ar fi rulat. Mă refer la abilitatea lui de a îşi adapta interfaţa la absolut orice necesităţi sau condiţii ciudate ar avea utilizatorii săi.
Prin urmare m-am decis să incerc să identific măcar o parte din cazurile în care soft-urile sunt puse în dificultate. Plec evident de la premiza că părţile care sunt în general adresate în proporţie cât mai mare de dezvoltatori (funcţiile soft-ului, utilizarea memoriei, interfaţa grafică, etc) sunt acoperite 100%. Prin urmare avem un program care nu are bug-uri, nu crapă sau se blochează, nu consumă toată memoria de pe maşina gazdă, nu are funcţii lipsă. Cu alte cuvinte, merge perfect.
Internaţionalizare şi localizare
Primul test de stres pentru soft este să îl distribui pe Internet (distribuire care a devenit standard în zilele noastre). Astfel orice user, din aproape orice ţară, este la un click distanţă de download-ul aplicaţiei. Prin urmare aplicaţia trebuie să suporte rularea măcar în 20-30 dintre cele mai utilizate limbi. Procesul se cheamă internaţionalizare şi în general am observat o tendinţă tot mai mare de a oferi aplicaţii şi site-uri în cât mai multe limbi. Sigur, asta e bila albă, pentru că cea neagră este legată de conţinut tradus doar parţial din engleză sau germană, caractere specifice acelei limbi afişate însă incorect (din cauza encoding-ului greşit, citiţi mai multe pe tema strădaniei şi chinurilor de a scrie în limba română aici), etc.
Partea a doua se referă la localizare. După ce ai reuşit să traduci interfaţa aplicaţiei în cât mai multe limbi, trebuie să identifici culturile, caracteristicile sociale, obiceiurile şi uzanţele grupurilor de oameni ce vor ajunge să folosească aplicaţia. Algoritmi specializaţi pentru afişarea datei, a monedei, de calcul a sărbătorilor religioase şi oficiale, de adaptare a formularelor la diferitele reguli şi legi din ţările şi zonele geografice respective – toţi aceşti algoritmi trebuie implementaţi în soft şi aplicaţi în momentul rulării într-un atare mediu.
Dreptul de a utiliza aplicaţia nu poate fi îngrădit de lipsa sau funcţionarea parţială a vreunei abilităţi de ordin motric, verbal, auditiv, optic sau de orice altă natură. Prin urmare aplicaţia trebuie să poată fi folosită de orice persoană, indiferent de dezabilităţile pe care aceasta le are. În cazul aplicaţiilor web, accesibilitatea poate fi asigurată într-o oarecare măsură prin conformarea cu standardele stabilite în acest sens, (cum ar fi WCAG). Mă întreb, însă, ce fel de măsuri se pot lua pentru aplicaţiile desktop, de exemplu. De asemnea, mă întreb oare ce ar trebui adăugat în aplicaţie astfel încât să poată accesa device-uri concepute pentru persoanele cu dezabilităţi, cum ar fi device-urile pentru limbajul Braille.
O altă arie unde aplicaţia trebuie să se adapteze uşor este portabilitatea. Aici domeniul este mai larg, avem portabilitate pe:
- diferite procesoare şi tipuri de procesoare (PC processors, Mac, PDA processors, mobile processors)
- diferite platforme (32biţi, 64biţi)
- diferite variante de device-uri (a se vedea portabilitatea pe diferite plăci video)
- diferite sisteme de operare
- diferite browsere
- diferite rezoluţii (deşi asta nu pare o problemă la prima vedere, aplicaţia e posibil să fie obligată să ruleze pe rezoluţii de 1600X1200, 1280X1024, 1024X600, 640X480 (PDA-urile moderne), 320X240 (PDA-urile mai vechi, marea majoritate a telefoanelor medii-spre-bune ca şi performanţe), etc.
Având în vedere că Internetul este accesibil pe orice platformă şi sistem, este vital să încerci să dezvolţi aplicaţia cât mai independentă de maşina sau de mediul în care rulează. De aceea consider că varianta cu o maşină virtuală este printre cele mai bune variante, unde prin maşină virtuală mă refer atât la un Java VM, de exemplu, cât şi la un browser, care face, conceptual vorbind, acelaşi lucru. Practic poţi rula o aplicaţie web pe absolut orice sistem care are Firefox instalat, de exemplu, şi asta deoarece nivelul la care aplicaţia rulează este cu mult peste nivelul de la care apar diferenţe între platforme şi arhitecturi.
Deployment
Următoarea problemă pe care trebuie să o iei în calcul atunci când îţi concepi aplicaţia să fie folosită de cât mai multe persoane este deployment-ul. Cum aplicaţia ta poate ajunge pe platforme diferite ca şi arhitectură (Windows, Unix, PDA-uri, telefoane mobile, etc) trebuie ori să faci un pachet care să poată fi deployed pe toate platformele (cerinţă greu de realizat), ori faci pachete multiple, fiecare utilizator descărcând pachetul potrivit. După ce ai rezolvat faza cu pachetele specializate, trebuie să te gândeşti şi la dependinţe. Nu de puţine ori mi s-a întâmplat pe Windows să îmi ceară un program să am instalat .NET Framework 2.0, sau pe Linux să am anumite biblioteci de funcţii gata instalate. Cum în acest post ne axăm pe a face viaţa utilizatorului cât mai uşoară, probabil cea mai bună soluţie este să oferi un script sau un program adiţional de instalare care să automatizeze instalarea bibliotecilor de care aplicaţia depinde (aşa am observat că face Wireshark, care necesită WinPcap).
Undeployment
Soră cu problema de mai înainte este undeployment-ul. Aşa cum menţiona Gusty într-un post anterior, ştergerea fără griji la dezinstalare a directorului în care a fost instalată aplicaţia nu e mereu cea mai bună soluţie. În plus de asta, trebuie analizat dacă are sens să ştergi şi bibliotecile dependente, deoarece este posibil între timp utilizatorul să fi instalat şi alte aplicaţii care depind de aceste biblioteci.
Concluzii
Cam acestea sunt cele câteva probleme care nu ţin neapărat de programarea aplicaţiei, şi de care te loveşti atunci când visezi spre o aplicaţie perfectă. Pentru unele dintre ele sunt soluţii/biblioteci ajutătoare, pentru altele trebuie să găseşti pe loc cea mai bună soluţie care se potriveşte. De asemenea, tot ce poţi face este să încerci să te apropii cât mai mult de îndeplinirea 100% cerinţelor de mai sus, deşi probabil 100% nu o să reuşeşti niciodată.
Listă de link-uri:
- Internaţionalizare: http://www.debian.org/doc/manuals/intro-i18n/
- Localizare: http://en.wikipedia.org/wiki/Language_localization
- Accesibilitate: http://en.wikipedia.org/wiki/Accessibility
- Web Content Accessibility Guidelines: http://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
- Problema diacriticelor din limba română: http://dorinlazar.wordpress.com/2009/06/24/diacritice-da-din-nou/
- Portabilitate: http://en.wikipedia.org/wiki/Software_portability
- Povestea realizării unui “release”: http://cultivatinro.wordpress.com/povestea-realizarii-unui-release/
Doar citind postul asta… nu mai vreau sa fiu dezvoltator de software
. Prea multe probleme.
Si uite de-aia nu sunt programe perfecte ci doar programe aproape perfecte: bune pentru un context. (Ma rog.. in afara de programele proaste). Finisajele sunt multe, mici si scumpe.
Probleme de acces sunt in general ignorate. Oamenii cu dezabilitati sunt putini din punct de vedere procentual, deci dezvoltarea de software care sa poata fi folosit si de ei e in general mai scump.
Cele de internationalizare sunt implementate de f. multe ori; si se pune un accent destul de mare pe capitolul asta. Eu cred ca in multe cazuri e facut degeaba. Pe de o parte, e un lucru bun , pe de alta parte, un lucru rau. Existenta unei limbi vorbita pe toata planeta o consider a fi un lucru bun. De ce sa nu fie folosit deja lucrul asta?
La portabilitate cred ca trebuie puse limite clare. Altfel vor aparea probleme de neconceput. Mai ales considerand ca si deployment-ul e legat de portabilitate.
E doar un vis momentan. Poate pe masura ce vor aparea frameworkuri mai bune, va incepe sa para un vis mai real. Pana atunci mai este.