Ogólnie dużo zasad programistycznych skłania nas programistów do tworzenia drobnoziarnistego kodu, małych zgrabnych i prostych klas/funkcji, które łatwo i szybko można zrozumieć, ktore najlepiej jeśli odpowiadają jedną rzecz.
Natomiast mnie ciekawi inna rzecz, jaka sytuacja/rzecz/stan sprawia, że świadomie decydujecie się nie dzielić kodu na mniejsze części. W jakich okolicznościach dłuższy kod bez wydzielonej odpowiedzialności jest waszym zdaniem lepszy?
Chyba nigdy :P
Jeśli przebywasz w latach 80tych XX wieku i masz słaby kompilator, a kod musi działać na słabym sprzęcie, to czasami lepiej będzie zrobić nieco większe funkcje.
W dzisiejszych czasach uzasadniają to chyba jedynie jakieś ekstremalne optymalizacje albo praca na jakiś interfejsach co mają po 100 - 200 równorzędnych pól. Właściwie dziś to już chyba dotyczy jedynie języków interpretowanych ( np. JS ).
Jeszcze 10 lat temu pisząc w PHP serwer jednej usługi wywalenie klas i funkcji oraz przerzucenie wszystkiego do jednej funkcji przyspieszyło kod ponad 5 razy (walka była o każdą milisekundę). Nie da się jednak ukryć, że ten kod to koszmar programisty. Wówczas jednak priorytetowa była wydajność ( czas wykonania skryptu ).
Obecnie takie tricki jeszcze czasem stosuję w JavaScript np. gdy robię jakieś efekty graficzne, obliczenia poszczególnych pikseli w dużej tablicy (jedynie w sferze hobbystycznej).
job safety. Piszesz taki kod że tylko ty będziesz go umiał utrzymac :D
W innym wypadku nie ma to za bardzo sensu, bo kompilatory i JITy potrafią sobie ten kod zoptymalizować i nie trzeba tego robić ręcznie.
Nie wiem czy tego dotyczy pytanie, ale..
Pisząc jakąś nową funkcjonalność - na samym początku - KISS wydaje mi się ważniejsze niż SRP - tzn. jak mam powiedzmy pobrać jedną konkretna informację z jakiegoś datastore to nie robie całej hierarchii klas, interfejsów i całej masy "best practices", tylko próbuje to zamknąć w najmniejszej ilości kodu, jednej klasie/funkcji (zależy od jezyka). Bo wydaje mi się, że może będzie miała ona ciut za dużo odpowiedzialności, ale przynajmniej nie trzeba skakać po jakichś dziwnie nazwanych bytach żeby dowiedzieć się co się tam konkretnie dzieje.
Oczywiście nie pozwalam żeby to się rozrosło i jak tylko zauważam, że będzie się z tego datastore pobierało więcej albo w bardziej złożony sposób to staram się to zrobić już po ludzku, tak żeby to się łatwo rozwijało/utrzymywało.
Czyli w skrócie próbuje unikac overengineeringu :D ale tj. mówie może nie tego dotyczyło pytanie
natomiast co do:
W jakich okolicznościach dłuższy kod bez wydzielonej odpowiedzialności jest waszym zdaniem lepszy
Uważam, że to co opisałem nie jest... lepsze; bardziej bym to nazwał wystarczającym i czytelniejszym. To co jest "lepsze" jest ściśle związany z konkretnym kontekstem
Zależy co masz na myśli. Bo jeśli mówimy o np zrobieniu jednej lub dwóch warstw w architekturze zamiast 10 które by wymyślił architekt, no to chyba mówi samo przez się, że chodzi o budżet projektu lub czas wydania mvp.
@katakrowa:
Obecnie takie tricki jeszcze czasem stosuję w JavaScript np. gdy robię jakieś efekty graficzne, obliczenia poszczególnych pikseli w dużej tablicy (jedynie w sferze hobbystycznej).
A serio sprawdzałeś, że ma to sens?
Akurat V8 od dawna ma wbudowany inlining ( przez VM JS nie działa jak klasyczne interpretowane języki). Powinno nie być różnicy.
Dodam jeszcze, że w przypadku Javy kilka razy widziałem benchmarki pokazujące, że wieksze funkcje są lepsze - chyba 100% tych benchmarków było zrypanych.
Crypto. Wtedy loop-unrolling i inne dziwne wynalazki są często nawet pożądane by kompilator nie wyoptymalizował jakichś rzeczy za nas. W przeciwnym wypadku, praktycznie nigdy.
Jeszcze 10 lat temu pisząc w PHP serwer jednej usługi wywalenie klas i funkcji oraz przerzucenie wszystkiego do jednej funkcji przyspieszyło kod ponad 5 razy (walka była o każdą milisekundę).
No tak. Walcz o kazda milisekunde i jednoczesnie pisz w PHP - co za glupota