Dlaczego, w imię szybszego dowożenia, tworzony jest marnej jakości kod - skoro przecież wiadomo, że w przyszłości będą z tego problemy?
Na dłuższą metę firmom to się opłaca patrząc jedynie na rachunek zysków i strat? Czy może działa tu zasada "jakoś to będzie"?
Czasem trzeba pocisnąć żeby klient nie uciekł. A potem tak zostaje
Zależy co masz na myśli. Bo cześć programistów mając na myśli "dobry kod" ma na myśli kod przeinżynierowany z 20 warstwami które nic nie znoszą teraz ale może za 50 lat coś wniosą, a jak nie to bedą chociaż mogli usiąść przed lustrem i powiedzieć "zrobiłem zajebisty kod" to nic że nie ma on sensu i nigdy mieć nie będzie.
Nie rozumiem, commitujesz marnej jakości kod? Czy widzisz, że inni to robią? Jak w ogóle można tworzyć marnej jakości kod i nic, przezież płacą nam za "software engineering".
lion137 napisał(a):
Nie rozumiem, commitujesz marnej jakości kod? Czy widzisz, że inni to robią? Jak w ogóle można tworzyć marnej jakości kod i nic, przezież płacą nam za "software engineering".
To chyba nie pracujesz w IT albo masz tyle szczęścia, że pracujesz w jakimś korpo gdzie się robi release raz na 3 lata.
lion137 napisał(a):
at przedmówcy, to są wymówki na wrzucanie słabego kodu?
trollujesz nieźle :)
anonimowy napisał(a):
@lion137: trollujesz czy naprawdę nie rozumiesz? Projekt rozwijany 10 lat i żeby coś dodać wypadało mi zrefacorować sporą część bo powoli się rozlatuje ale nie ma na to czasu
jak projekt jest rozwijany przez 10 lat, to tego czasu było aż zanadto i pewnie jeszcze będzie (zakładając, że dany projekt będzie jeszcze utrzymywany długo)
W takich sytuacjach członkowie zespołu myślą zbyt krótkoterminowo. Że programista-mid, który wchodzi do takiego projektu, będzie tak robić, to mnie nie dziwi. Natomiast już senior czy PM powinien być mądrzejszy.
Potat0x napisał(a):
Dlaczego, w imię szybszego dowożenia, tworzony jest marnej jakości kod - skoro przecież wiadomo, że w przyszłości będą z tego problemy?
To się nazywa dług techniczny i jest czymś normalnym (powinno być) w nowych czy krótkotrwałych projektach - lepiej dowieźć szybko i zweryfikować niż się bawić w przeinzynierowanie czegoś, co i tak w przyszłości będzie inne. Czasem spaghetti kod jest rozsądnym sposobem optymalizacji.
Czyli:
Niestety niektorym ludziom się priorytety przestawiły i robiąc długofalowy projekt wrzucają tam spaghetti i udają, że nie ma czasu. I projekt nie da się utrzymywać, wszyscy tylko na tym tracą, ale będą dalej żyć w kłamstwie.
Z kolei w greenfieldach przesadzają w druga stronę i już robiąc projekt od zera go przeinzynierowuja już na starcie, co potem spowalnia dodawanie nowych funkcji oraz nie na jakiejś specjalnej korzyści (ponieważ zwykle ta pierwsza architektura i tak kompletnie nie pasuje do wymogów projektu, których to wymogów ktoś nie znał, jak ją projektował)
Dobry kod dla biznesu to taki, za który klient płaci. Programista jest częścią tego biznesu więc czy chce czy nie chce, również musi brać to pod uwagę. Ogólnie zgadzam też się z @ehhhhh, jak słyszę od programisty, że chce napisać dobry kod to potem często na pull requeście widzę nawalonych klas z tyłka, które nie dość, że przeszkadzają w czytaniu to na dodatek nie pomagają w jednej z najważniejszych rzeczy jakie musi spełniać gruba abstrakcja by jej istnienie miało jakikolwiek sens, czyli w automatycznym testowaniu.
Każdy programista powie Ci że chce napisać dobry kod, ale większości tylko wydaje się że tworzą dobry kod, a w rzeczywistości wychodzi im coś w stylu FizzBuzzEnterprise realizującego niepotrzebne rzeczy o które biznes nawet nie prosił. Sam się łapie na tym że po napisaniu działającego kodu często mogę uprościć lub wręcz usunąć bardzo wiele rzeczy. I takie upraszczanie przeprowadzane regularnie jak najbardziej ma sens, bo potem ciężko się pracuje z projektem w którym jest mnóstwo niepotrzebnego kodu.
U nas niestety w niektórych projektach jest przyjęta zasada aby zmieniać jak najmniej kodu, co z jednej strony ogranicza zapędy do dodawania niepotrzebnych funkcji, ale z drugiej strony niestety utrudnia czyszczenie. Dlatego najczęściej udaje mi się coś uprościć poprawiając błąd - tj. mówię "patrzcie - było przekombinowane i przez to był błąd, więc ten błąd uzasadnia refactor".
anonimowy napisał(a):
@LukeJL: To w jakich firmach pracujesz, że pozwalają na poświęcenie tygodnia (z refactorem) na zadanie, które powiedzmy innej osobie może zająć godzinę (bez refactoru)?
Przy tak podstawionych liczbach/czasach wykonania, to faktycznie:
Tylko:
@LukeJL: No to sam sobie przeczysz bo z jednej strony "czemu refaktor ma trwać tydzień" a potem "Jak próbujesz mienić jedną rzecz, a nagle się okazuje, że nie możesz bez ruszania tuzina innych, i właśnie to powoduje opóźnienia, a nie refaktor...". Właśnie to, że musisz ruszyć tuzin innych rzeczy powoduje, że ten refaktor trwa długo. Bo dodać np. argument do funkcji w 12 miejscach, pozmieniać coś tam itd. to nie problem bo masz testy. Ale żeby to zmienić sensownie może być wiele problemów w takim spagetii
@anonimowy: system małych kroków, przy poprawkach/dodatkach "zostaw kod w lepszym stanie niż go zastałeś" co nie znaczy byś przepisywał cały moduł, tylko np poprawił te 2 metody w których akurat grzebiesz.
@anonimowy: da się zawsze a je śli uważasz że trzeba przebudować cały moduł to najpierw zastanów się 20x czy może to czasem nie ty źle do tego podchodzisz i czy to da jakikolwiek zysk klientowi.
Niestety życie pokazuje, że ten dobry kod i tak jednak potem okazuje się złym kodem. Albo dlatego, że w pewnym momencie został zatruty z powodu pewnych kompromisów zastosowanych dlatego, że nie było czasu już dłużej myśleć nad tym, jak zrobić coś ładnie, albo dlatego że po latach to, co było ładne okazało się jednak brzydkie, tylko nikt tego nie przewidział.
Ja mam spore wątpliwości, czy "marna jakość kodu" jest skutkiem braku czasu. Wbrew pozorom, napisanie dobrego kodu nie jest bardziej czasochłonne niż napisanie złego kodu. Przemyślenie jak coś zaimplementować (raz, a dobrze) wcale nie trwa dłużej niż pójście na żywioł. Oczywiście pomijam sytuację w której do wielkiej kupy trzeba dokleić kolejny kawałek kupy, bo wtedy czasami faktycznie szybciej jest dołożyć kolejnego if'a niż rozplątywać już istniejące Jenga.
Moim zdaniem prawdziwe przyczyny to:
Jak ktoś chce się pokłócić, to chętnie :) Ale proszę na początek zapoznać się z postami studentów (połowa nie wie co ma napisać na zaliczenie), Postami z działu kariera "mnie tam wali domena, kazali napisać, to napisałem" i "ja jestem od pisania kodu, nie wyciągania wymagań", oraz "na kiego grzyba pytają mnie o wzorzec, jak ja będę pisał we frameworku".
No ale tak w ogóle, to należy sobie zadać 2 pytania: jaki jest cel i czy cel został osiągnięty. Jeżeli celem jest wyrobienie się w terminie i zarobienie kasy, a klient jest zadowolony z rezultatu bo aplikacja działa stabilnie i spełnia założenia, to pytanie jest w czym problem? Nie mówię, że jakość kodu nie ma znaczenia, ale czasem urasta to do rangi ideologii i staje się celem samym w sobie.
Wystarczy, że kod będzie taki, żeby dało się go zrozumieć i rozwijać wystarczająco szybko. Zabijanie się o ilość linii kodu w klasie to już przesada. Gdy jakość kodu staje się głównym celem, to jest już patologia przeważnie. To jest właśnie przeinżynierowanie.
KamilAdam napisał(a):
Manago nie rozumieją co to znaczy kod dobrej jakości
A programiści mają deadline'y i w pewnym wieku przestaje im się chcieć kłócićŻeby było zrozumienie musiałbyś mieć technicznego manago, a coraz trudniej o takich
Mój jest nietechniczny, ale nie ma czegoś takiego, że bez względu na wszystko trzeba szybko dostarczyć ficzur, nawet jeśli będzie bez testów itp. Można "negocjować". Oczywiście zamknięcie się w piwnicy na miesiąc, żeby zrobić refactor, nie wchodzi w grę :D
ehhhhh napisał(a):
Zależy co masz na myśli. Bo cześć programistów mając na myśli "dobry kod" ma na myśli kod przeinżynierowany z 20 warstwami które nic nie znoszą teraz ale może za 50 lat coś wniosą, a jak nie to bedą chociaż mogli usiąść przed lustrem i powiedzieć "zrobiłem zajebisty kod" to nic że nie ma on sensu i nigdy mieć nie będzie.
No ja też nie lubię niepotrzebnych komplikacji i to nie jest dobry kod. Mam na myśli przypadki w których kod został doprowadzony do takiego stanu, że ciężko się w nim ruszyć i rozwijać. Lub pójście po linii najmniejszego oporu i świadome robienie jawnie druciarskiego rozwiązania, bo dzięki temu zaoszczędzi się trochę (dosłownie trochę) czasu.
lion137 napisał(a):
Nie rozumiem, commitujesz marnej jakości kod? Czy widzisz, że inni to robią?
Odpowiadając na pierwsze pytanie - subiektywnie nie - staram się pisać dobry kod. Odpowiadając na drugie - tak. Ale to samo w sobie nie jest największym problem. Gorsze jest to, jak mi się wydaje, że czasem też programistom przestaje zależeć i dlatego tak robią.
@gajusz800: Oczywista sprawa, tylko jak kod robi to co ma robić (spełnia wymagania), wiadomo dlaczego to robi (nie został skopiowany ze SO), wiadomo, że robi to ~zawsze (jest przetestowany), to jest to chyba zawsze dobry kod. Moim zdaniem, jeżeli mówimy o chociaż odrobinę złożonym systemie, to nie istnieje coś takiego jak "dobry produkt z dziadowskim kodem".
No i właśnie to nie do końca rozumiesz. Z punktu widzenia firmy to nie kod ma spełniać wymagania, tylko końcowy produkt ma spełniać wymagania. Rozumiane jako wymagania funkcjonalne. Czy w kodzie będą pomieszane warstwy czy nie albo czy są tam klasy po 500 linii, to menedżerów nie obchodzi. Tak długo, jak team będzie dowoził aplikacje które działają tak, jak miały działać, góry nie interesuje jakość kodu rozumiana jako jakieś arbitralnie przyjęte praktyki. Te są ustalane wewnątrz teamu przez team lidera, ale to sprawa drugorzędna tak naprawdę. Jakość kodu nie stanowi tu żadnego decydującego kryterium. Lepsza jakość kodu może przekładać się na to, że aplikacja działa lepiej, ale nie musi bo są też inne czynniki, które na to wpływają.
Ale gdzie ja napisałem o "arbitralnie przyjętych zasadach"? Ja, sprowadzam kwestię "aplikacja działa" do 3 punktów:
Czyli ktoś zebrał wymagania, ktoś zaimplementował, ktoś przetestował.
Moja teza jest, że jeżeli ta aplikacja to coś więcej niż hello world, niech będzie kalkulator, to nie pisząc "dobrego kodu", rozumianego jako coś co jest podatne na zmiany/rozwój nie da się tych 3 kryteriów spełnić w rozsądnym budżecie. To jak rozumiem kod podatny na zmiany jest już bardziej złożone i być może w niektórych szczegółach byśmy mieli odmienne zdanie, ale zdecydowanie nie mam tu na myśli wymagań typu "metoda nie może mieć więcej niż 15 linii", "wcięcia robimy spacjami" itp.
Dlaczego ma być podatne na zmiany? Bo jak robi to więcej niż jeden programista, przez więcej niż jedną godzinę, to trzeba będzie to zmieniać.
@piotrpo: no i właśnie dochodzimy do punktu "kod podatny na zmiany" kiedy nie wiesz jakie zmiany beda w przyszłości to tylko zgadywanie, które bardzo często sprawia że ktoś robi kod myśląc że bedą zmiany X a okazuje się że są Y które sprawiają że to co napisał nadaje się tylko do całkowitego usunięcia. Tym samym nie ma to biznesowego sensu bo nigdy się nie przygotujesz na każda zmianę jaka może być potrzebna bo wtedy logowanie usera byś pisał 3 miesiące. Także w mojej ocenie lepiej pisać kod zwięzły który robi to co ma robić i wrazie potrzeby zawsze można go zaorać i napisać na nowo w wersji rozszerzonej niż pisać z myśla o rozbudowie której i tak nie przewidzimy.
Ileś razy (ale głównie w jednej konkretnej firmie) skonfrontowałem programistę z managerem produktu pytając czy naprawdę życzy sobie, aby ficzur był zrobiony byle jak, z bugami, bez testów, byle szybko. I o dziwo okazywało się, że wcale sobie tego nie życzy - to tylko dziwne domniemania programistów.
Spotkałem się w życiu z presją dupnych menadżerów, ale o wiele częściej wirtualną presję wymyślają sobie programiści. Głównie po to, żeby mieć wymówkę do robienia na odczep.
@jarekr000000: ja pracuje dość blisko biznesu, na 80% wycen dostaje info "czemu tyle czasu? takiego budżetu nie mamy".
Rozumiem, że tu jest forum programistów a programiści tworzą kod. Naturalnym wydaje się być, że dobry programista tworzy dobry kod i po tym można odróżnić tego dobrego od złego. Choć też głównie jestem programistą to widzę to zupełnie inaczej. Dobry programista powinien umieć napisać dobry kod, powinien umieć tworzyć generalizacje w postaci często nadmiarowych abstrakcji ale realizując konkretne zlecenie do jego rozwiązania powinien potrafić zastosować narzędzia i techniki odpowiedniego kalibru do problemu. Na to co należy użyć będą miały wpływ termin realizacji zadania czy cena końcowej aplikacji. To dwa niezmiernie ważne czynniki aspekty, o których większość programistów zapomina, uważając że kod musi być super bo inaczej aplikacje będzie zła... Niestety to nie jest prawda.
W pewnym przypadku dobrym kodem będzie relatywnie łatwe do ogarnięcia "spaghetti" w całości umieszczone w funkcji main a w innym przypadku starannie zaprojektowany zbiór dziedziczących po sobie klas może okazać się porażką. Tu nie ma ogólnie dobrych wytycznych.
Skupianie się na samej jakości kodu to projektowy błąd. Sama jakość kodu bardzo rzadko przekłada się na biznesowy sukces projektu. Dobry kod może być dumą programisty ale w tym samym czasie konkurencyjna firma sprzeda 10 razy więcej licencji mimo, że kod mają beznadziejny ale wystartowali pół roku wcześniej.
Po ponad 20 latach projektowania i pisania systemów, aspekt jakości kodu uważam za pomijalny - nie mówię tu o ewidentnych kaszanach i "druciarstwie". Każdy kod napisany z zachowaniem minimum staranności da się rozwijać i modyfikować nawet po 10 latach.
Jeśli jednak miałbym wskazać coś co ma potwierdzony wpływ na łatwość rozwoju systemu, nawet po wielu latach, to będzie to jego architektura.
Nie sam kod a odgórna idea narzucająca reguły i ramy, w których będą poruszać się programiści tworzący poszczególne moduły systemu.
Nie da się jednak łatwo powiedzieć jaka architektura będzie dobra bo to już zależy od specyfiki rozwiązania, które się tworzy. Nie mając wystarczającej wiedzy na temat tego jak projekt się rozwinie możemy popełnić poważny błąd a wtedy nie uratuje nas nawet najpiękniejszy kod, z którego zbudowana jest źle zamodelowana aplikacja.
Na oceną kodu ma duży wpływ też to, kto za niego płaci. Myślę, że niejednemu głosicielowi idei pięknego kodu przyszło zapłacić za większy projekt z własnej kieszeni to szybko zrewidowałby swoje poglądy na temat "jakości".
Nie zawsze naszym klientem jest bank, automotive czy inny finansowy moloch. Łatwo jest się "wymądrzać" kiedy budżet mamy niemal bez ograniczeń.
