Reguła KISS

KamilAdam napisał(a):

ToTomki napisał(a):

Ferdynand Lipski napisał(a):

Nie wydaje Ci się to oczywiste?

Zamierzasz dodawać do projektu aplikacji zasoby, których (prawdopodobnie) nigdy nie użyjesz, a które obciążają przestrzeń dyskową i/lub pamięć operacyjną?

Jeśli ktoś nie programuje superniskopoziomowo to te parę kb więcej w pamięci nie ma żadnego znaczenia

Nie chodzi o wielkość kodu tylko o czas klepania tego. A potem o czas utrzymywania i szukania interesującego fragmentu

To w pierwszej kolejności. Co do wydajności to może być ona powodem w niektórych językach że robi się kopiuj wklej kodu bo język nie daje możliwości zrobi genetycznego rozwiązania co by szybko działało. I potem mamy skopiowane i delikatnie zmienione SQLe, lub własne generatory SQLi

Odpisujesz mi, a ja odpisuję Lipskiemu. Tak, dokładnie to napisał, że jego zdaniem wielkość kodu jest powodem, dla którego zbędnego kodu nie należy pisać.

lester29 napisał(a):

Hej, czy to prawda że lepiej implementować w swoim kodzie funkcjonalności tylko te co potrzebuję i resztę dobudowywać w miarę potrzeby zamiast implementowania na zapas na zasadzie „bo może się kiedyś przyda”?

to YAGNI, jak już zostało wspomniane.
KISS to "Keep it simple, stupid".

implementowania na zapas na zasadzie „bo może się kiedyś przyda”?

Tutaj dużą rolę pełni doświadczenie.
Ktoś niedoświadczony może wrzucić na zapas "bo może się kiedyś przyda", czego efektem będzie przeładowanie projektu o niepotrzebne rzeczy.

Ale odwrotna postawa:

implementować w swoim kodzie funkcjonalności tylko te co potrzebuję i resztę dobudowywać w miarę potrzeby

może poskutkować tym, że projekt będzie dryfował bez ładu ładu i składu.

Żeby umieć coś zaprojektować dobrze, trzeba nabyć najpierw doświadczenie. Przez doświadczenie rozumiem tutaj doświadczenie w robieniu konkretnych projektów i rozwiązywaniu konkretnych problemów. Ktoś doświadczony w niszy X, niekoniecznie będzie w stanie zaprojektować dobrze rzecz w niszy Y. Chociaż oczywiście ogólne doświadczenie programistyczne również ma duże znaczenie.

I teraz - jak jesteś już wystarczająco doświadczony, tj. przerobiłeś już temat wielokrotnie ucząc się na błędach (własnych i cudzych), to wiesz, co jest ważne i jesteś w stanie zrobić coś prosto, ani nie dodając na zapas, ani nie pisząc rzeczy na partyzanta.

Z mojego doświadczenia najskuteczniejszym można być wtedy, kiedy się jest w stanie przewidzieć, co będzie projekt potrzebował od A do Z, jednak robić tylko wybrane rzeczy z tego (np. tylko A, D, F, Z), bo się wie, jak one pasują do układanki. Czyli widzieć wszystko/cały przekrój z lotu ptaka i w szczególe, ale robić tylko wybrane rzeczy. Czyli design w głowie, a KISS i YAGNI w działaniu.

Wtedy jak będzie potrzeba dorobienia kolejnych rzeczy, to się je dorobi, bo projekt będzie miał na tyle lekką architekturę, że będzie można ją rozszerzać (ew. niektórych rzeczy się nie dorobi, ale wtedy będzie to świadoma decyzja projektowa, żeby zrezygnować z pewnych rzeczy na stałe narzucając sobie z góry pewne ograniczenia, żeby zachować prostotę designu).

I wtedy można faktycznie świadomie zrobić coś zachowując zasadę KISS.

Tak, jak pisali (niektórzy) poprzednicy: ogólnie to dobrze nie komplikować prostych rzeczy i jeśli coś nie będzie potrzebne, to tego nie dawaj
ALE
z drugiej strony - dobrze jest przemyśleć całość aplikacji i zastanowić się, na ile takie "prostsze" rozwiązanie nie będzie później kulą u nogi.
Bo tworzenie całego frameworka od podstaw, żeby zrobić coś prostego jest totalnym przerostem formy nad treścią. Ale z drugiej strony - czasem jak coś wpiszesz na pałę to potem takie działanie skutecznie blokuje możliwość jakichkolwiek zmian, a żeby zmienić coś prostego to musisz poprawić połowę plików w projekcie. Tylko na to nie ma złotej zasady, musisz to poczuć, a takie wyczucie przychodzi z doświadczeniem. I tego raczej nie przeskoczysz.

KISS wychodzi dopiero jak się robi za którymś razem podobny projekt.

• najpierw rzeczy mogą być za trudne i będziemy kombinować i błądzić we mgle. Będzie nam brakowało wiedzy technicznej, żeby połączyć kropki.
• początkowo możemy też mieć błędne wyobrażenia i tworzyć zamki w chmurach, barokową architekturę. Zamiast budować na solidnych fundamentach, to będziemy tworzyć hipotezy (to może się przydać, wydaje mi się, że tak będzie szybciej, o tym wzorcu projektowym czytałem w książce, więc go zaimplementuję)

Natomiast jak już się robi coś któryś raz, to już się ma ogarnięte technikalia oraz wie się, jaki design się sprawdza, a jaki generuje problemy. Więc można zrobić coś prosto, bo człowiek już na tym etapie wie, co robi.

KISS nie mówi aby nie dodawać niepotrzebnych rzeczy tylko aby nie komplikować niepotrzebnie tej funkcjonalności, która jest niezbędna. W programowaniu każdą rzecz można napisać na wiele sposobów. Zasada KISS mówi aby sopśród tych sposobów wybrać ten możliwie najprostszy, bo im prostszy kod tym łatwiej go utrzymać, tym mniej potencjalnych błędów będzie zawierał i tym łatwiej będzie go czytać.

Niestety łatwo powiedzieć, trudniej zrobić. Tworzenie prostych rozwiązań jest sztuką. Zauważyłem, że im ktoś bardziej początkujący, tym zwykle tworzy bardziej skompilowany kod. Zdarzało mi się wywalić 80% kodu bez utraty ani grama funkcjonalności.

Programiści nie zawsze zgadzają się też odnośnie tego co jest proste. Dla mnie prosty kod to taki, który mogę czytać po kawałku i będę w stanie zrozumieć co się dzieje. Jeśli muszę przeczytać najpierw 10k linii aby cokolwiek zrozumieć, to kod jest przesadnie skomplikowany. Ale spotkałem się z poglądem, że abstrakcje w kodzie dodatkowo komplikują, i że taki wielki blob spaghetti w którym nasz pomieszanie poziomów abstrakcji jest prostszy, bo wszystko widać od razu i nic nie jest ukryte. No nie mogę się z tym zgodzić, ale takich programistów też spotykam.

lester29 napisał(a):

Hej, czy to prawda że lepiej implementować w swoim kodzie funkcjonalności tylko te co potrzebuję i resztę dobudowywać w miarę potrzeby zamiast implementowania na zapas na zasadzie „bo może się kiedyś przyda”?

Zgadza się. To jest właśnie to co w innej działce z powodzeniem wdraża JIT. U nas w Javie nie do końca im wyszło ale nie powiela się błędów przeszłości.

Nie robi się na zapas bo utrzymanie zapasu też kosztuje czas i energię którą można spożytkować na coś innego.