Mam taką apkę do zarządzania kinem i zastanawiam się nad jednym rozwiązaniem. Lepiej zczytać z jakiegoś pliku konfiguracyjnego informacje o salach kinowych (raczej ich ilość się nie zmieni, rzadko się zdarza, że kino się rozbudowywuje) czy udostępnić endpointy do ich dodawania i usuwania?
0
3
Nofenak napisał(a):
Mam taką apkę do zarządzania kinem i zastanawiam się nad jednym rozwiązaniem. Lepiej zczytać z jakiegoś pliku konfiguracyjnego informacje o salach kinowych (raczej ich ilość się nie zmieni, rzadko się zdarza, że kino się rozbudowywuje) czy udostępnić endpointy do ich dodawania i usuwania?
To zależy czego klient na tą chwilę wymaga.
Jeśli klient nie wymaga zmiany tych sal, to najlepiej to zahardcodzić. Nawet nie w żadnym pliku konfiguracyjnym, tylko normalnie w kodzie źródłowym.
Jeśli klient chce móc je dodawać i usuwać, to wtedy musisz to dodać.
1
Tak jak wyżej, przy tak prostej aplikacji, nie ma sensu robić overthinking. Wydziel sobie tylko jakiś interfejs, by w przyszłości łatwiej dodać sobie pod spodem np. bazę, plik czy co tam innego.
0
Dregorio napisał(a):
Tak jak wyżej, przy tak prostej aplikacji, nie ma sensu robić overthinking. Wydziel sobie tylko jakiś interfejs, by w przyszłości łatwiej dodać sobie pod spodem np. bazę, plik czy co tam innego.
YAGNI. Nie warto tego robić, dopóki nie będzie ku temu potrzeby. Jeśli sale okażą się że są stałe, to nie ma sensu tego robić.
0
Tak i nie, YAGNI życiem, zgadzam się, ale interfejs pomaga w przetestowaniu (mocki), więc to nie jest IMO, coś czego nie potrzebujesz. Może przemawia przeze mnie golangu :P
1
Dregorio napisał(a):
Tak i nie, YAGNI życiem, zgadzam się, ale interfejs pomaga w przetestowaniu (mocki), więc to nie jest IMO, coś czego nie potrzebujesz. Może przemawia przeze mnie golangu :P
Testowanie tego mockami to też zły pomysł. Przywiązujesz testy do implementacji, bad idea.
Dodanie interfejsu o którym mówisz to jest dobry krok - owszem - ale wtedy kiedy wiesz że te dane będą dodawane dynamicznie. Jeśli są stałe, tak jak teraz, to dodanie interfejsu to jest tylko dodatkowy koszt który może tak/może nie okaże się opłacalny. Nic nie stracisz nie dodając go teraz. A testy należy napisać pod te dane tak jakby były stałe, więć nie potrzebujesz mockować. Bo one są stałe. Łatwo potem będzie je zdynamizować, jeśli nie napiszesz niepotrzebnych mócków.
0
Dregorio napisał(a):
Tak i nie, YAGNI życiem, zgadzam się, ale interfejs pomaga w przetestowaniu (mocki), więc to nie jest IMO, coś czego nie potrzebujesz.
Mocki zakładają, że dany interfejs ma sens i warto go zabetonować testami. YAGNI zakłada, że trzeba jechać po minimalnej lini oporu
Może przemawia przeze mnie golangu :P
Z tego co czytam po forach (sam programuje w go) to konsens jest taki, żeby nie używać mocków/używać jak najrzadziej. Nawet google oddał swoją bibliotekę do mocków uberowi, bo nie maja chęci w jej utrzymaniu
0
Riddle napisał(a):
Nofenak napisał(a):
Mam taką apkę do zarządzania kinem i zastanawiam się nad jednym rozwiązaniem. Lepiej zczytać z jakiegoś pliku konfiguracyjnego informacje o salach kinowych (raczej ich ilość się nie zmieni, rzadko się zdarza, że kino się rozbudowywuje) czy udostępnić endpointy do ich dodawania i usuwania?
To zależy czego klient na tą chwilę wymaga.
Jeśli klient nie wymaga zmiany tych sal, to najlepiej to zahardcodzić. Nawet nie w żadnym pliku konfiguracyjnym, tylko normalnie w kodzie źródłowym.
Jeśli klient chce móc je dodawać i usuwać, to wtedy musisz to dodać.
To apka do portfolio, więc nie mam zdefiniowanych wymagań przez klienta. Pytam raczej w kontekście, co byłoby lepsze, wygodniejsze dla potencjalnego klienta. Teraz mi przyszedł do głowy taki przypadek, że w przypadku remontu jednej z sal, przydałaby się możliwość usunięcia jej z systemu na ten czas. Hardkodowanie konkretnych sal w kodzie średnio mi się podoba
1
Nofenak napisał(a):
To apka do portfolio, więc nie mam zdefiniowanych wymagań przez klienta. Pytam raczej w kontekście, co byłoby lepsze, wygodniejsze dla potencjalnego klienta. Teraz mi przyszedł do głowy taki przypadek, że w przypadku remontu jednej z sal, przydałaby się możliwość usunięcia jej z systemu na ten czas. Hardkodowanie konkretnych sal w kodzie średnio mi się podoba
Więc to nie jest pytanie programistyczne, tylko pytanie bardziej produktowe - jaką aplikację chcesz zbudować?
- Jeśli chcesz móc zmieniać salę, to musisz to zaimplementować.
- Jeśli sale są stałe, to najlepszym wyjściem jest je zahardcodzić.
Rozumiem, że czujesz się niekomfortowo z pomysłem zahardcodzenia ich. Ale wbrew pozorom, jak ustawisz te sale w konfiguracji np pliku; a potem będziesz chciał to zmienić na bazę, to paradoksalnie prościej jest to zrobić wychodząc od zahardcodzon'ych danych niż tych z pliku - łatwiej jest je zmienić z kodu źródłowego, niż z pliku. Chyba że, masz odpowiedni interfejs zgody z Dependency Inversion tak jak mówił @Dregorio, wtedy to jest proste. Tylko znowu to łamie YAGNI, jak nie ma na to wymagania.
Także - jeśli chcesz je zdynamizować, to zrób to. Jeśli nie, to nie. Jak mówiłem, to nie jest programistyczna kwestia, tylko produktowa - co Ty chcesz żeby ten program robił.
1
Używanie mocków do mockowania wewnętrznych rzeczy (w odróżnieniu od zewnętrznych zależności) to dla mnie przepis na testowanie biblioteki mockującej, zamiast swojego projektu…
Co prawda uważam zmienianie interfejsu po to, żeby się lepiej testy pisało, również za zły pomysł, ale z dwojga złego wolałbym to.
Z punktu widzenia klienta, podejrzewam (nigdy nie pisałem oprogramowania kinowego, ale pisałem takie dla hoteli) że jeśli masz klikalne GUI do tej zmiany, to jest mu prawie wszystko jedno¹, a jeśli nie masz, to… też mu jest wszystko jedno, bo albo się trafi taki klient, który tego w życiu nie ruszy, bo się będzie bał, albo taki grzebacz-majsterkowicz, który będzie losowe pliki usuwał, żeby porównać wrażenia.
Samemu bym wybrał plik konfiguracyjny, ale to bardzo słaba preferencja.
¹ Plik konfiguracyjny ma tę zaletę, że znacząco łatwiej się go backupuje.
0
Riddle napisał(a):
Jeśli klient nie wymaga zmiany tych sal, to najlepiej to zahardcodzić. Nawet nie w żadnym pliku konfiguracyjnym, tylko normalnie w kodzie źródłowym.
W to bym nie szedł, bo po co się ograniczasz do jednego klienta. Lepiej pisać tak, żeby dało się to jeszcze komuś opchnąć.
@Nofenak:
Jak bym to umieścił w bazie.
0
@Riddle:
@S4t:
Nie wiem czy dobrze rozumiecie, bo ta konfiguracja z pliku jest zczytywana raz przy pierwszym starcie aplikacji i te sale są potem zapisywane w bazie
0
Nofenak napisał(a):
Nie wiem czy dobrze rozumiecie, bo ta konfiguracja z pliku jest zczytywana raz przy pierwszym starcie aplikacji i te sale są potem zapisywane w bazie
Nie sądzisz że może się pospieszyłeś trochę z tym?
0
Nofenak napisał(a):
@Riddle:
@S4t:
Nie wiem czy dobrze rozumiecie, bo ta konfiguracja z pliku jest zczytywana raz przy pierwszym starcie aplikacji i te sale są potem zapisywane w bazie
Ale to nie lepiej zrobić w postaci insertów do bazy? Zbędne komplikacje.
0
@Riddle: Nie do końca chyba rozumiem. Mam interfejs z Get i Set. Implementuje sobie to jako zapis i odczyt z pliku, zapis i odczyt z bazy, czy pamięci. Natomiast mocki wygenerowane na podstawie interfejsu dają mi pewność, że funkcjonalności w około nie spadnie z rowerka, bo funkcja get I set będzie poprawnie wywołana.
@slsy: Nie znam tego konsensusu, w projektach, które robiłem/przejmowałem były mocki, bo to był najprostszy sposób na przetestowanie
1
Dregorio napisał(a):
@Riddle: Nie do końca chyba rozumiem. Mam interfejs z
GetiSet. Implementuje sobie to jako zapis i odczyt z pliku, zapis i odczyt z bazy, czy pamięci. Natomiast mocki wygenerowane na podstawie interfejsu dają mi pewność, że funkcjonalności w około nie spadnie z rowerka, bo funkcja get I set będzie poprawnie wywołana.
Jedyną pewność jaką w ten sposób zyskasz, to to że metoda wywołana. To nie jest test który zaobserwuje to co chcesz przetestować. Są lepsze sposoby na przetestowanie tego niż mocki.
0
@Riddle: Przez ponad 2 lata pracowałem w firmie gdzie tak właśnie definiowalismy kontrakty i to działało. Teraz też tak robię i jeszcze mnie nie kopnęło to, jeśli coś się zmieni to dam znać. Ponadto jeśli coś "betonuje", to chce by to działało tak jak chce na wieki.
Może ja źle rozum też SOLID, ale dla mnie Open/Close to właśnie to co robię. Dodać funkcję do interesju tak, zmienić istniejącą - zle
1
Dregorio napisał(a):
@Riddle: Przez ponad 2 lata pracowałem w firmie gdzie tak właśnie definiowalismy kontrakty i to działało. Teraz też tak robię i jeszcze mnie nie kopnęło to, jeśli coś się zmieni to dam znać. Ponadto jeśli coś "betonuje", to chce by to działało tak jak chce na wieki.
Rozumiem pomysł. Ale napisanie tego w taki sposób sprawia że ciężej to zmienić, ergo nie jest to dobry design.
To że "coś działa", to żaden argumenty. Kod ze zmiennymi globalnymi, goto, spaghetti, klasy na 1000 linijek, one też "działają". Chodzi o to jak coś jest proste w utrzymaniu.
Dregorio napisał(a):
Może ja źle rozum też SOLID, ale dla mnie Open/Close to właśnie to co robię. Dodać funkcję do interesju tak, zmienić istniejącą - zle
Dodanie funkcji do interfejsu też łamie Open/Close. Z definicji dodanie funkcji do interfejsu modyfikuje go.
Przestrzeganie Open/Close to byłoby dodanie nowej implementacji tego interfejsu, tak żeby ten interfejs w ogóle się nie musiał zmienić. Także coś tu nie do końca gra z tym O/C u Ciebie.
0
Riddle napisał(a):
Rozumiem pomysł. Ale napisanie tego w taki sposób sprawia że ciężej to zmienić, ergo nie jest to dobry design.
Z moje perspektywy ja nie chce tego zmieniać. Chce mieć pewność, że program zadziała, jak ktoś zaimplementują mój interfejs.
Dregorio napisał(a):
Może ja źle rozum też SOLID, ale dla mnie Open/Close to właśnie to co robię. Dodać funkcję do interesju tak, zmienić istniejącą - zle
Dodanie funkcji do interfejsu też łamie Open/Close. Z definicji dodanie funkcji do interfejsu modyfikuje go.
Przestrzeganie Open/Close to byłoby dodanie nowej implementacji tego interfejsu, tak żeby ten interfejs w ogóle się nie musiał zmienić. Także coś tu nie do końca gra z tym O/C u Ciebie.
W golangu mogę embedowac interfejsy, wiec w moim pojmowaniu nie zmieniam interfejsu, tylko wbudowuje go w nowy, ale rozumiem co masz na myśli
Edit.
To że "coś działa", to żaden argumenty. Kod ze zmiennymi globalnymi, goto, spaghetti, klasy na 1000 linijek, one też "działają". Chodzi o to jak coś jest proste w utrzymaniu.
Jeśli piszesz kod dla siebie, jeśli potem taka biblioteka jest wystawiana na zewnątrz, to zaczyna się problem IMO
0
Dregorio napisał(a):
To że "coś działa", to żaden argumenty. Kod ze zmiennymi globalnymi, goto, spaghetti, klasy na 1000 linijek, one też "działają". Chodzi o to jak coś jest proste w utrzymaniu.
Jeśli piszesz kod dla siebie, jeśli potem taka biblioteka jest wystawiana na zewnątrz, to zaczyna się problem IMO
No to przecież własnie to powiedziałem :D
Odnosiłem się do tego co napisałeś:
Dregorio napisał(a):
@Riddle: Przez ponad 2 lata pracowałem w firmie gdzie tak właśnie definiowalismy kontrakty i to działało. Teraz też tak robię i jeszcze mnie nie kopnęło to, jeśli coś się zmieni to dam znać.
To sam sobie odpowiedziałeś na swój post:
Dregorio napisał(a):
Jeśli piszesz kod dla siebie, jeśli potem taka biblioteka jest wystawiana na zewnątrz, to zaczyna się problem IMO
0
Ok, zgubiłem się :P W takim razie przeczytam jeszcze raz i przemyśle co napisałem