Deși în ultima vreme activitatea mea se împarte între aplicațiile web și linia de comandă, folosesc totuși un număr de programe normale “desktop” – browser(e), client IM, sticky notes, pachet office. Nu-mi aduc aminte când am configurat ultima dată vreunul din aceste programe (probabil după ce le-am instalat). Știu sigur că n-am intrat niciodată în opțiunile de configurare ale lui OpenOffice.
Și totuși, cei care scriu aceste aplicați se încăpățânează să încarce în memorie la fiecare rulare tot codul și resursele corespunzătoare secțiunii de configurare. La prima vedere ai putea să zici “și ce dacă, 10 funcții, 3 butoane”… Dar toate astea se adună, iar dacă ții cont că unele dintre programe au tot felul de “wizards” care rulează doar o dată, în schimb conțin poze sau chiar animații, devine evidentă irosirea de resurse.
Filosofia UNIX spune că programele trebuie să fie mici, să facă bine task-ul pentru care au fost concepute și să nu aibă funcții inutile. Configurarea programelor “old school” se face editând câteva fișiere text, iar software-ul le citește și le interpretează atunci când este pornit.
Metoda asta, deși funcționează de zeci de ani, are atât avantaje cât și neplăceri. Este bine că folosești o singură unealtă pentru configurare (un editor banal de texte), dezavantajul este că fiecare creator de software cere formatarea fișierului de configurare după cum are chef, neexistând un standard. Este simplu să greșești ceva și să “determini” programul să facă ce nu intenționai sau chiar să nu mai pornească. Încă mai am coșmaruri cu fișierul de configurare de la Sendmail.
Problema cu standardul de stocare al opțiunilor a primit mai multe rezolvări, de exemplu Windows folosește faimosul Registry, iar în lumea Linux, Gnome ține setările în GConf – acesta salvează totul într-un set de fișiere XML ce, în ultimă instanță, pot fi editate chiar și cu un editor de text normal.
Acestea fiind spuse, îmi vine greu să înțeleg de ce aproape toți programatorii de aplicații desktop salvează datele în baza de date standard (GConf, Registry), dar insistă să includă partea de configurare în aplicație, cu toate dezavantajele pe care deja le-am enumerat, când ar fi fost mult mai logic să existe un program separat pentru configurare.
Avantajele sunt evidente: nu încarci în memorie cod pe care nu-l folosești decât extrem de rar, e mai ușor de dezvoltat și de făcut debugging, devine mai simplu să apelezi funcțiile de configurare din alte părți (de exemplu un wizard care rulează după instalarea sistemului de operare ar putea să lanseze modulele de configurare de la cele câteva programe instalate implicit). Iar pentru utilizator, toate astea pot fi transparente – în definitiv, el nu știe că atunci când dă click pe Options programul principal lansează un alt executabil…
Tu ce crezi? Am dreptate și această metodă ar reduce din “bloat”-ul programelor desktop? Sau ar trebui ca aplicațiile să fie monolitice? Scrie un comentariu mai jos!
Image credit: Kai Hendry.
Related posts:
Esti sigur ca un program ca OpenOffice nu isi tine dialogurile de configurare intr-o biblioteca ce se incarca atunci cind e nevoie de ea?
Sunt 94,8% sigur. Fișierele deschise și map-uri de memorie sunt identice atunci când am OO deschis în mod normal și atunci când deschid dialogul de configurare. Nici nu crează un thread nou și nici nu lansează un alt proces.
Există și diverse aplicații care sunt modularizate, e adevărat, dar cele mai multe nu încarcă/descarcă dinamic respectivele module, ci încarcă totul în memorie de când pornesc, deci tot aia e.