Propozycje do uporządkowania kodu

openpkw / openpkw-weryfikator

Backend dla aplikacji weryfikującej wyniki wyborów

2 stars 8 forks source link

Propozycje do uporządkowania kodu #19

Closed SebastianCelejewski closed 8 years ago

SebastianCelejewski commented 8 years ago

Kilka propozycji z mojej strony:

Wybór środowiska, względem którego uruchamiane są automatyczne testy akceptacyjne przy pomocy parametrów Mavena, np. -Dopenpkw-env=test, aby strzelał w Dobromira, -Dopenpkw-env=local, aby strzelał w localhost.
Przejrzenie nazw tabel i kolumn w encjach.
Wprowadzenie log4j we wszystkich miejscach, gdzie jest System.out.println().
Przeniesienie wszelkiej logiki biznesowej do projektu openpkw-services.
Dostosowanie kodu aplikacji Androidowej, aby korzystała z najnowszych wersji API do tworzenia użytkowników, logowania się do systemu i wysyłania kodów QR.

Dopisujcie swoje propozycje:

SebastianCelejewski commented 8 years ago

Oprócz tego wszystkie sprawy związane z RESTem (w osobnym issue pt. ,,Opracowanie koncepcji ogólnej dla REST'').

adamkowalewski commented 8 years ago

Odnośnie trzeciego punktu: odradzam bazowanie na log4jw środowisku kontenera JEE. WildFly na dzień dobry oferuje slf4j jako provided. Projekt ze zdefiniowaną zależnością API:

<dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>${version.slf4j}</version>
      <scope>provided</scope>
</dependency>

może definiować Logger

...
private static final Logger logger = LoggerFactory.getLogger(...);
...

którego implementację dostarczy kontener.

SebastianCelejewski commented 8 years ago

Dzięki za poradę.

Problem tkwi jednak w tym, że część kodu to są toole do uruchamiania z command line i takie rozwiązanie nie działa. I teraz mamy wybór albo będziemy używać dwóch podejść (slf4j i log4j), albo wybierzemy jedno, spójnie dla całego komponentu (i wtedy będzie to log4j).

pogos commented 8 years ago

Jaki jest problem z slf4j w aplikacjach command line?. W jaki sposób uruchamiasz tool z command line? Moim zdaniem możliwe, że brakuje zależności na classpath.

slf4j to jedynie API pod którym w naszej aplikacji i tak ukrywa się log4j.

SebastianCelejewski commented 8 years ago

Jeszcze mam jedną propozycję do ewentualnego refactoringu: pozbycie się Spring Application Framework i przejście na czystą Java EE. Dałoby to m. in. znaczną redukcję wynikowych jarów, a w związku z tym szybsze deploymenty.

mrozim78 commented 8 years ago

Myślę że to musimy przedyskutować we wtorek bo mam kilka wątpliwości co do tego pomysłu.

SebastianCelejewski commented 8 years ago

Czy możemy to issue zamknąć? Chyba jest stara i dawno wykonana.

SebastianCelejewski commented 8 years ago

Stwierdzam timeout - zamykam.