Już jakiś czas temu, napisałem dla mojej byłej firmy pewną aplikacyjkę, która jako tako działa do dzisiaj. Gdy ją pisałem, robiłem to dość chaotycznie jeśli chodzi o strukturę kodu. Jest straszny bałagan i pomimo sporej ilość komentarzy nawet ja już ledwo mogę się w tym połapać
Druga sprawa, to to, że gdy ją pisałem, nie znałem się w ogóle na języku obiektowym więc pisałem wg zasady jak leci, byle działało W tej chwili, mając trochę wolnego czasu, chciałem odświeżyć ten kod. Chciałbym go bowiem wykorzystać do swojego portfolio gdybym szukał nowej pracy. Wiem, że potencjalny pracodawca lubi zajarzyć do kodu i gdyby zobaczył ten mój raczej nie byłby zachwycony Związku z tym, chciałbym się was poradzić o kilka spraw związanych z pewnymi rozwiązaniami, które tam zawarłem i czy wg waszej opinii można by zrobić to lepiej tak aby działało to lepiej zarówno pod kątem szybkości jak i pamięciożerności no i bezpieczeństwa.
Po krótce opiszę, że jest to aplikacja działająca w lokalnej sieci firmy. Jej celem jest ewidencjonowanie dokumentów, poczty i faktur. Służy ona jedynie do zapisywania informacji o tym jaki dokument, kiedy, od kogo i do kogo przyszedł bądź do jakiego klienta został on wysłany i od jakiego pracownika. Kod jest jak już wspominałem napisany w PHP a baza jest na MySQL. Jako, że rocznie może być nawet około 50 tyś dokumentów, zrobiłem podział na lata. To znaczy oddzielne tabelki na dokumenty, faktury z nazwą roku. Tak wiec, praca w programie jest podobna jak w programie do księgowości. Aby działać w nim, trzeba najpierw wybrać rok pracy systemu. Jest też tabelka z kontrahentami, użytkownikami, z grupami uprawnień, działami w firmie, rodzajami stanowisk, z historią zmian w dokumentach, oraz z logami. Typowa aplikacja sieciowa.
Największym problemem w specyfice tego programu było stworzenie czegoś na kształt bufora dokumentów. Chodziło o to, że w momencie, kiedy użytkownik, wpisywał dany dokument, musiał znać już jego ID. Niby nic trudnego ale. Osoba wpisująca dane musiała bowiem w tym czasie, dany ID wpisać ręcznie na "fizycznym" dokumencie, który właśnie ewidencjonowała. Po za tym, w programie, nie mogły istnieć przerwy w numeracji. Jakakolwiek "dziura" musiała być załatana i to tak, aby dokumenty z jednego dnia nie mogły być np na przemian z dokumentami dnia poprzedniego. Było to o tyle skomplikowane, że ewidencja taka, była prowadzone prze kilka osób jednocześnie.
Przechodząc jednak do sedna sprawy, Mam kilka pytań, jak wg was powinienen zmienić, niektóre mechanizmy, (albo i nie, jeżeli uznacie, że tak może być):
1. Kwestia logowania i sesji. Zastosowałem mechanizm tradycyjnej sesji przechowywanej w tablicy $_SESSION. Jak już wspomniałem, aplikacja działa tylko w sieci lokalnej, więc super zabezpieczenia wg mnie nie były tak konieczne. Może macie jednak inne zdanie. W sesji przechowywałem bowiem takie dane, jak imię, nazwisko, użytkownika, jego grupa uprawnień, rok pracy w systemie, czy też zmienne wykorzystywane do wspomnianego wcześniej bufora. Czy wg was, lepiej zmniejszyć ilość przechowywanych danych w sesji i częściej pytać o nie bazę?
2. Czasami, podczas wyszukiwania danych użytkownicy pracują na kilku już wprowadzonych dokumentach. Edytując je po kolei, chcą aby po każdym zapisaniu dokumentu, móc powrócić do tego samego wyniku wyszukiwania tak aby znowu nie musieli szukać tych samych dokumentów. W tym momencie, równie korzystam ze zmiennej sesji, w której zapisana jest ścieżka do strony z parametrami wyszukiwarki. Czy wg was to dobre rozwiązanie, czy można je zastąpić innym?
3. Główna strona jest zrobiona w taki sposób, że jej szkielet, czyli zawartość, która jest na każdej podstronie programu, jest na stronie index.php a pozostała treść, która zmienia się , przy pomocy swicha ładowana jest includami zewnętrzne pliki php. Czy wg was lepsze było by inne rozwiązanie do ładowania danej treści. Zastanwaiałem się nad zastosowaniem szablonów tzw smartów? Nie mam z tym jednak dużego doświadczenia. Czy takie rozwiązanie jest mniej wydajne. Z tego co czytałem, to na pewno jest wygodniejsze podczas późniejszej zmiany na portalach internetowych, ale czy coś takiego sprawdzi się w aplikacji takiej jak moja?
5. Podczas wypełniania dokumentu przy wyborze kontrahenta, zastosowałem mechanizm AJAX, który podobny jest ten jak przy wpisywaniu frazy w wyszukiwarce google. Wpisując już pierwsze 3 litery, wyświetlają się rekordy zaczynające się na ten łańcuch znaków. Zastanawiałem się, czy nie skorzystać z czegoś innego. Myślałem, ogólnie o zastosowaniu flasha. Użyłbym go do wprowadzaniu danych w formularzach i przy dynamicznym wyświetlaniu rekordów. Tak samo, można by w nim zbudować ciekawe menu podobne do takich jak w aplikacjach niewebowych. Co o tym sądzicie? Czy flash to jednak nie jest zbyt dobre rozwiązanie do takiej aplikacji. Może coś innego polecacie? Czy lepiej zostawić tak jak jest?
6. Czy lepiej jest tworzyć wiele zmiennych czy jedną tablicę dwu wymiarową w której zapisane były by wszystkie wymagane parametry wykorzystywane np w wyszukiwarce?
7. Sam mechanizm bufora, na razie nie zmieniłem jego kodu na klase. Jak to zrobię to go umieszczę do waszej oceny.
To na razie wszystko, po więcej pytań zgłoszę się w trakcie migracji. Mam nadzieje, że ktoś dotarł do końca po mozolnym wstępie
Pozdrawiam i z góry dziękuje za wszelkie porady.
) - ale polecam zapoznać się z taką np. kohaną (albo innym frameworkiem MVC) - osobiście zawsze miałem problemy z przejrzystością kodu (jak to programistom zdarzy się czasami... "powymiatać" za bardzo, a tam masz z góry wszystko narzucone i po prostu nie ma opcji coś zwalić.
Nie ma 4 ? 