Słaba jakość kodu w dużej firmie?

@Afish: Pominąłeś całkowicie sens, tego co próbowałem przekazać w poprzednich postach.

Może podsumujmy miejsca w których się zgadzamy.

• Czy zgadzamy się, że zbyt ciastno połączone ze sobą moduły są trudne do zmiany (np UI i logika)?
• Czy zgadzamy się, że zbyt ciastno połączone testy z logiką, utrudniają zimanę tejrze logiki?
• Czy zgadzamy się, że wprowadzanie zmian w kodzie bez testów jest obarczone dużo większą szansą że wprowadzimy jakiegoś buga?
• Czy zgadzamy się, jedną dużą wielką klasę, lub jedną dużą wielką funkcję, edytuje się i poprawia się trudniej, niż kilka małych?

Afish napisał(a):

TomRiddle napisał(a):

Jeśli natomiatst dostajesz metodę pełną globalnego stanu, statycznych zmiennych, poukrywanych zależności, taką która miesza logikę z widokiem, albo bóg wie co jeszcze, to oczywiście że nie napiszesz go szybko; ale nie dlatego że nie da się napisać testu szybko, bo da się - ale trzeba najpierw odseparować testowaną funkcję od reszty syfu, w miarę możliwości, i to zajmuje najwięcej czasu. Samo napisanie testu jest szybkie i proste (zakładając oczywiście że wie co się robi).

Okej, czyli już wiemy, że refaktoring robimy minutę (bo to zmiana nazwy zmiennej), dobry test piszemy w minutę (jak już mamy odseparowany kod od syfu). To w takim razie jak nazywa się ten proces "zamiany syfnego kodu w kod, który można testować"? Zdajesz sobie sprawę, że uprawiasz logomachię?

No faktycznie nie mamy w środowisku rozróżnienia tych dwóch rzeczy.

Możemy je nazwać refaktor pojedynczy (np rename metody, przeniesienie jej, zmiana typów, klas, wydzielenie czegoś), i jeden taki refaktor pojedynczy (albo jednostkowy) trwa bardzo krótko; a ten drugi typ o którym mówisz,możemy nazwać "refaktor całościowy" albo "refaktor modułu lub pakietu". Fine by me; dobra nomenklatura to podstawa.

Afish napisał(a):

Właśnie o to chodzi: szybko i tanio nie oznacza najszybciej i najtaniej. Kontrolowanie długu technicznego jest ważną częścią inżynierii oprogramowania, trzeba wiedzieć, kiedy olać refaktoring, a nie wywyższać się ponad menadżera. Wszystko poniżej jest oparte na błędnym założeniu.

Sure, trzeba wiedzieć; i dla mnie rachunek jest prosty. Jeśli dany fragment będzie wymagał zmian w bliskiej lub dalszej przyszłości; to najpewnie dobrze byłoby go zrefaktorować i otestować wcześniej czy później. To jak szybko trzeba coś zrefaktorować i otestować to delikatna decyzja, i trzeba mieć dużo doświadczenia żeby zdecydować czy lepiej wcześniej, czy później.

Jeśli ten kawałek nie będzie wymagał zmian, to można go zostawić.

Jeśli nie wiesz czy będzie się zmieniał, to to jest taka szara strefa i trzeba by się zastanowić na spokojniej, czy ten fragment ma większą szansę że się zmieni w przyszłości, czy raczej nie; i podjąć decyzję nt refaktoru na podstawie tego co ustalimy (czy będzie się zmieniał czy nie), ewentualnie możemy to postpone'ować, aż będzie to bardziej pewne.

Afish napisał(a):

TomRiddle napisał(a):

No; ale co ja Ci poradzę. Ja tak robię w swoich projektach zarówno w pracy jak i prywatnie, i to jakoś działa. Także dla mnie to nie jest utopia tylko pewien konkretny (co prawda wysoki, ale konkretny) standard.

No i masz liczby potwierdzające, że refaktoring bardziej się opłaca? Jak ostatnio rozmawialiśmy, to nie miałeś żadnych danych biznesowych, tylko swoje przekonanie. Ja w swoich projektach mam konkretne liczby pokazujące, że pisanie najlepszego kodu nie jest optymalne.

Problem sprowadza się do tego, że żeby rozumieć takie rzeczy jak to czy refaktor się opłaci czy nie, musiałbyś być programistą. Jeśli jesteś niekompetentny w tej dziedzinie, to nigdy nie zrozumiesz o czym jest mowa, nie mówiąc już o podjęciu jakiejś informowanej decyzji. Więc nie przekonasz nigdy managera lub kogokolwiek nietechnicznego o tym, że warto to robić. Najwyżej możesz dać swoją opinię jako ekspert w temacie, i spodziewać się że ktoś ją weźmie pod uwagę.

Noi jeszcze jest drugi powód czemu ten argument jest bez sensu.

Na pewno widziałeś kucharzy, którzy przed każdym użyciem swojego noża machają nim parę razy na ostrzałce, żeby go przyostrzyć.Albo nawet zwykli ludzie, którzy myją kubek zaraz po użyciu, lub chowają go od razu do zmywarki, zamiast zostawić.

I teraz Twój argument wyżej, dla mnie brzmi tak jakbyś podeszedł do osoby która wkłada kubek do zmywarki i zapytał ją "Przepraszam, czy masz jakieś liczby które potwierdzają że włożenie kubka do zmywarki częściej zajmuje mniej czasu niż odkładanie ich do zlewu?". Doesn't make much sense to me.

Afish napisał(a):

Dam Ci ośmiotysięcznik w JS i nie zrobisz mi refaktoringu ani dobrego testu w minutę. Ponieważ masz jakieś niespójne definicje, to zaznaczę, że chodzi mi o zrobienie praktycznej zmiany, jak w kodzie produkcyjnym, a nie zmianę nazwy zmiennej czy napisania testu do nowej funkcji napisanej na boku.

Całościowego refaktoru na pewno. Ale mógłbym wprowadzić kilka pojedynczych refaktorów w minutę. Odpowiednia ilość takich pojedynczych krótkich refaktorów prędzej czy później doprowadzi do całościowego refaktoru.

Teraz, tak jak rozumiem, to co Ty próbujesz powiedzieć, to to że nie opłaca się robić refaktorów. Rozumiem to tak, że mówisz że dziennie warto robić 0 pojedynczych refaktorów, które na dłuższą metę będą skótkować w 0 całościowych refaktorów.

Ja sugeruję, żeby liczbę pojedynczych refaktorów w jednostce czasu, np dzień, trzymać powyżej zera. Pojedynczy refaktor zajmie krótko, minutę lub mniej, np jeden rename, jeden extract, jedna zamiana miejsc, jedno odwrócenie ifa. Możesz ich zrobić tyle na ile masz czasu, albo tyle na ile uważasz, może to być chociaż jeden, może być 10 może więcej. Ale na pewno się nie zgadzam że okej jest wejść do projektu i zrobić 0 pojedynczych refaktorów.

@Afish: Noi kolejna rzecz; która mi teraz przyszła do głowy. Być może niektórym się wydaje że refaktor, to jest zawsze zmiana z punktu A, to idealnego najlepszego kodu na świecie. Użycia wszystkich dobrych praktyk jakie istnieją, na cudo. To nie jest do końca prawda; bo to nie zawsze ma sens.

To co zawsze ma sens, to jest zrobić to, z czego aktualnie projekt mógłby skorzystać. Jeśli te dwie funkcje są cieżkie do zmiany, popraw je. Ale jeśli widzisz że np dodanie abstrakcji w tym miejscu byłoby "by the book", ale w tym miejscu nie ma sensu - nie rób tego. Mam wrażenie że niektórzy tego nie rozumieją.

Dobre refaktorowanie to nie jest zmiana projektu z tego co jest teraz na Dzieło Sztuki, tylko po prostu iteratywny proces dodawania korzystnych cech do aplikacji. Takich, które sprawią że praca z nimi będzie lepsza. Jesli uważasz że jakaś zmiana nie przyniesie korzyści, nie dodawaj jej, proste.

Jeśli widzisz klase, która powiedzmy łamie SRP na dziesiątą stronę; ale widzisz też że poprawa tego, tak że nie łamałaby jej nie doda nic dobrego do projektu; czyli nawet jakbyś to rozdzielił to i tak wprowadzanie zmian w nim nie było by tańsze, to nie ruszaj jej, nie rób refaktora tam - po co.

@Afish: Noi też trzeba wziąć kolejną rzecz, pod uwagę, która się jeszcze nie pojawiła, a mianowicie: Nie wszyscy jesteśmy równi. Nie każdy umie robić refaktor dobry; i nie każdy umie pisać dobre testy.

• Jak jesteś dobry w refaktor i testy, to dodawanie ich dla Ciebie jest szybkie i proste; a więc tanie dla firmy.
• Jeśli nie jesteś dobry w refaktor i testy, to dodajesz je powoli, i są niższej jakości, więc koszt dla firmy jest większy, a wartość niższa; dlatego że jakoś tych testów jest niższa.

Jeśli w tym temacie wypowiadają się osoby które są bardzo słabe w refaktor, to faktycznie, ciężko będzie ich przekonać że ciągłe poprawianie kodu is the way to go; ale nie rozmawiamy tak na prawdę o temacie samym w sobie; tylko o tym żeby najpierw wyedukować takiego delikwenta.

Nie znam osoby która, nauczywszy się pisać dobre testy, przestałaby je pisać; osoby które ich nie piszą to tylko takie które nie umieją tego robić, i nie doceniają ich wartości.

Podsumowując: Dla managerów, PO i firmy; refaktoring, dobra jakość kodu oraz testy są bardzo wartościowe; pod warunkiem że mają do dyspozycji programistów którzy są w stanie tanio je dodać. Jeśli takich nie mają, to refaktoring sam w sobie się nie opłaca. Tak bym podsumował moje stanowisko.

PS: Ba, powiem więcej. jeśli masz takich programistów; to jest bardzo duża szansa że oni sami z siebie ciągle robią refaktor i ciągle piszą testy. Continuous improvement, continuous refactor; i kod produktu sam z siebie, automatycznie jest wysokiej jakości i otestowany. I wcale wytwarzanie go nie zajmuje dłużej, wręcz przeciwnie.

Afish napisał(a):

Ty używasz tego słowa wygodnie, na przykład raz twierdzisz, że "Jeśli myślisz że refaktor to np przetarcie szmatką kurzu z felg, to myślę że tutaj leży też Twoja wina.", a innym razem mówisz o zmianie nazwy zmiennej.

A jak myślisz, czy nazwy (zmiennych, funkcji, klas) to jest tylko estetyka kodu? Czy jednak wpływa na to jak szybko i jak kosztownie wprowadza się zmiany w oprogramowaniu?

TomRiddle napisał(a):

Czy jednak wpływa na to jak szybko i jak kosztownie wprowadza się zmiany w oprogramowaniu?

Jak bardzo wpływa? Jakieś liczby?

Afish napisał(a):

TomRiddle napisał(a):

Czy jednak wpływa na to jak szybko i jak kosztownie wprowadza się zmiany w oprogramowaniu?

Jak bardzo wpływa? Jakieś liczby?

Niestety nie mogę Ci zaproponować żadnych liczb; i od razu odpowiem. Mam całą masę opinii nt robienia produktów, nie tylko nt refaktorów i testów, ale też mocków, solid, abstrakcji, OOP vs FP; czytelności kodu, podział kodu na klasy, funkcje i pakiety; enkapsulację, i wszystkie inne praktyki wytwarzania oprogramowania.

I na żadne z nich nie mam konkretnych liczb.

Po prostu programowałem już dosyć długo; mam wrażenie że z każdym kolejnym rokiem, kiedy się uczyłem bądź poznawałem jakąś metodologię; mam wrażenie że było to podobne do iteratywnego procesu takiej selekcji naturalnej; jeśli jakaś metodologia pozwalała szybciej robić aplikacje, to była większa szansa że jej użyję, jeśli jakaś metodologia powodowała wolniejsze wytwarzanie, to jest spora szansa na to że już jej nie użyję. I tak się stało; że w ekwipunku moich metodologii zostało TDD, continuous refactoring oraz solid.

Ale again, proces ustalania takich priorytetów, tego co się opłaca a co nie, nie jest poprate liczbami, tylko czymś bardziej podobnym do selekcji naturalnej umiejętności; również zwane doświadczeniem.

Myślę że to samo jest prawdą nt innych dziedzin. Czy jakiś fryzjer ma liczby nt tego kiedy się używa maszynki lub nożyczek?

Być może istnieje jakiś obiektywny zestaw wartości, które obiektywnie mogą wykazać czy jakiś refaktor się opłaca czy nie; albo czy dana metodologia jest szybsza niż inna; ale to nie jest podstawa moich argumentów w tej rozmowie. I ich brak nie czyni tych argumentów niepoprawnymi.

Poza tym, nie muszę ich wcale mieć żeby odeprzeć Twój argument. Oczywiście że nazwy zmiennych, funkcji i klas wpływają na koszt wytwarzania oprogramowania, bo oczywistym jest że mógłbym nazwać każdą zmienną k1, k2, k3, k4, k5, i tak z każdą zmienną i funkcją; i to na milion procent będzie wymagało więcej czasu i pieniędzy żeby edytować taką aplikacją, i będzie większ szansa na dodanie bugów. Z k1, k2, k3 to jeszcze pół biedy; gorzej jak funkcja ma nazwę która mówi jedno, a funkcja tak na prawdę robi drugie. Kłamiąca nazwa jest jeszcze gorsza niz nic nie mówiąca nazwa.

No i masz liczby potwierdzające, że refaktoring bardziej się opłaca? Jak ostatnio rozmawialiśmy, to nie miałeś żadnych danych biznesowych, tylko swoje przekonanie. Ja w swoich projektach mam konkretne liczby pokazujące, że pisanie najlepszego kodu nie jest optymalne.

@Afish: jesteś stronniczy bo pracujesz blisko sprzedaży. Ale sprzedaż to jest tylko wycinek IT. Bardzo często firmy przechodząc z firm produktowych na technologiczne po prostu wydzielają kawałek swojego ciasta zysków na transformację i nie masz jak tutaj udowodnić, że Twoja linijka przynosi zysk lub stratę. Jesteś trybikiem i jak odejdziesz to masz zostawić po sobie łatwy i rozszerzalny proces. Jeżeli widzę, że jakiś dev idzie na skróty i wyprodukował jakąś libkę, która łamie wszelkie kontrakty i robi jakieś z d**y workaroundy to takie coś blokuję, jeżeli to nie pomoże to eskaluję. Priorytetem moich projektów nie jest dowiezienie czegoś po łebkach tylko dowiezienie czegoś działającego bardzo szybko, a później refaktor i upraszczanie procesu. Im prostszy kod i proces, tym lepszy. Im kodu jest mniej, jest czystszy i jest mniej bottlenecków w postaci wszechwiedzących geniuszy, którzy są 24h/dobę w pracy, tym lepiej. Żadnego oceniania czy to się opłaca czy nie, nie ma bo projekt ma się po prostu zmieścić w budżecie i to jest koszt wyścigu zbrojeń poszczególnych firm, które wypadną z rynku jeżeli się nie będą modernizowały.

Patrząc tylko z takiej perspektywy czy linijka na siebie zarabia to można uznać, że programiści i księgowi to koszt. Jedynym działem wartym utrzymywania jest sprzedaż.

...
I nazwy zmiennych mają mega znaczenie. Kiedyś jeden architekt mnie zaprosił na spotkanie gdzie robili w 6 osób wdrożenie i pisali kod po łebkach, żeby przyspieszyć. Jak zobaczyłem jak bardzo zmieniali konwencję nazewnictwa to mówię temu architektowi, że tym oto spotkaniem z live codingiem, gdzie niby chce przyspieszyć właśnie generuje dług, który będziemy spłacać latami bo będziemy się mylili z tymi nazwami. I goście przy mnie poprawiali te wszystkie nazwy zmiennych, żeby używać konwencji, które zostały już wymyślone i mieli się ich trzymać. Mam wrażenie, że jednym z pierwszych zadań architekta powinno być stworzenie konwencji nazewnictwa.

Jak mam niby sfalsyfikować twierdzenie, że będziemy się bujać z nazewnictwem inaczej przez odwołanie się do mojego doświadczenia. Byłem tam Gandalfie. Byłem tam 3000 lat temu.

TomRiddle napisał(a):

Ale again, proces ustalania takich priorytetów, tego co się opłaca a co nie, nie jest poprate liczbami, tylko czymś bardziej podobnym do selekcji naturalnej umiejętności; również zwane doświadczeniem.

No a biznes operuje na liczbach, a te pokazują, że na przykład faang robi miliony, chociaż ma kijowe oprogramowanie i dużo długu technicznego.

TomRiddle napisał(a):

Poza tym, nie muszę ich wcale mieć żeby odeprzeć Twój argument. Oczywiście że nazwy zmiennych, funkcji i klas wpływają na koszt wytwarzania oprogramowania, bo oczywistym jest że mógłbym nazwać każdą zmienną k1, k2, k3, k4, k5, i tak z każdą zmienną i funkcją; i to na milion procent będzie wymagało więcej czasu i pieniędzy żeby edytować taką aplikacją, i będzie większ szansa na dodanie bugów. Z k1, k2, k3 to jeszcze pół biedy; gorzej jak funkcja ma nazwę która mówi jedno, a funkcja tak na prawdę robi drugie. Kłamiąca nazwa jest jeszcze gorsza niz nic nie mówiąca nazwa.

Przecież ja nie twierdzę, że "nazwy nie wpływają na koszt wytwarzania oprogramowania", tylko pytam o rozmiar tego wpływu i twierdzę, że perfekcyjne robienie jest mniej opłacalne od kontrolowanego długu technicznego. Dopowiadasz mi rzeczy, których nie mówię.

twoj_stary_pijany napisał(a):

@Afish: jesteś stronniczy bo pracujesz blisko sprzedaży.

Przecież ja nie pracuję blisko sprzedaży, jestem zwykłym inżynierem oprogramowania, który wpływa na biznes od najniższego szczebelka. Reszty nie komentuję, bo bazuje na jakichś rzeczach, których nie powiedziałem.

Afish napisał(a):

TomRiddle napisał(a):

Ale again, proces ustalania takich priorytetów, tego co się opłaca a co nie, nie jest poprate liczbami, tylko czymś bardziej podobnym do selekcji naturalnej umiejętności; również zwane doświadczeniem.

No a biznes operuje na liczbach, a te pokazują, że na przykład faang robi miliony, chociaż ma kijowe oprogramowanie i dużo długu technicznego.

A są jakiekolwiek liczby które pokazują jaki mieliby wpływ kasy gdyby kod był gorszej jakości lub wyższej? Bo jeśli nie; to ten argument nie ma sensu. Dodatkowo; to że firma dużo zarabia mają gówniany kod, nie znaczy że zarabia dużo dlatego że ma gówniany kod.

Przykład:

• Firma zarabia $90mln. rocznie.
• Firma wydaje $1mln. na rozwój oprogramowania rocznie, które przy okazji jest to gówniane oprogramowanie.

I wychodzi że można zarabiać dużo, jeśli masz oprogramowanie słabej jakości. Mimo że być może z inną strukturą kodu wytwarzanie oprogramowania mogłoby kosztować np $2mln. rocznie lub $100tyś. rocznie.

To ile firma zarabia, jest tylko przeszkadzajką w zrozumieniu tego co się dzieje na prawdę w oprogramowaniu.

Bo owszem, jeśli włożysz dodatkowe $1mln. kasy do projektu, to będziesz w stanie mógł go rozwijać szybciej niż ktoś inny, "kontrolując tech debt" (czyli dokładając tech debt), i tak długo jak wkładasz do niego więcej kasy, tak możesz iść szybciej. Ale to jest dokładnie to o czym mówię: Czyli praca nad kodem z techdebtem bez refaktoru, pochłania więcej kasy, i czasu też.

Nie możesz mieć projektu który ma stały koszt ORAZ jednocześnie zwiększa techdebt. Musisz jedno wybrać; czyli albo robisz continuous refactoring i usprawniasz ciągle kod; albo dokłądasz do niego coraz więcej kasy ()żeby zapanować nad bugami i rosnącymi problemami ze zmianami).

TomRiddle napisał(a):

Przecież ja nie twierdzę, że "nazwy nie wpływają na koszt wytwarzania oprogramowania", tylko pytam o rozmiar tego wpływu i twierdzę, że perfekcyjne robienie jest mniej opłacalne od kontrolowanego długu technicznego. Dopowiadasz mi rzeczy, których nie mówię.

No to się mylisz :D Bo "kontrolowany dług techniczny", to zwiększający się dług technologiczny. A jeśli zwiększy się do odpowiedniego poziomu, to koszt rośnie wykładniczo.

Poza tym, już pomijajac wszystko; to odnosisz się do biznesów, firm, projektów komercyjnych, terminach, zarobkac etc żeby mówić o tym jak wytwarzać oprogramowanie.

Ale spójrzmy na Open-Source'owe, non-profitowe biblioteki i aplikacje, publiczne; rozwijane za darmo, tylko po to żeby je stworzyć; co zaobserwujesz w takim środowisku? Otóż to, że biblioteki które są wysokiej jakości, są ciągle refaktorowane, testowane i ciągle usprawnienia to są te które mają mniej błędów, i częstsze release'y, a to z kolei znaczy że praca nad nimi jest szybsza i bezpieczniejsza.

Jeśli dodasz do równania biznesy, managerów, presje czasu, dochody, to być może rozmowa będzie bliżej komercyjnej w pracy; ale odejdzie od tematu na który rozmawiamy, czyli wpływu refaktoru i wysokiej jakości kodu na szybkość i koszt rozwoju oprogramowania.

Nadal podtrzymuję to co mówiłem wcześniej. Nie ma żadnego powodu żeby nie refaktorować istniejącego kodu. Dodawanie kontrolowanego techdebtu, do aplikacji która ma być ciągle rozwijana; to droga albo do śmierci projektu, albo do rosnących kosztów, albo do przepisania jej.

TomRiddle napisał(a):

A są jakiekolwiek liczby które pokazują jaki mieliby wpływ kasy gdyby kod był gorszej jakości lub wyższej?

Tak. Jeżeli ficzer X możesz dostarczyć na dwa sposoby i oba dają ten sam efekt dla użytkownika, to będziesz miał takie same przychody i potencjalnie niższy koszt wyprodukowania oprogramowania (bo jest kijowej jakości) i potencjalnie wcześniej zarabiasz. Teraz wszystko rozbija się o zysk czasowy i przychody miesięczne - jeżeli oba te wskaźniki są wystarczająco duże, to z zarobionej kasy część przeznaczamy na zatrudnienie nowych pracowników, którzy poradzą sobie z długiem technicznym, a reszta zostaje nam do dyspozycji. I to tak działa.

Teraz problem w tym, że nie da się łatwo powiedzieć, jakie dokładnie są te liczby, bo robi się wiele ficzerów jednocześnie, zmieniają się wymagania i proces trwa miesiącami. Ale to nie usprawiedliwia postępowania dogmatycznego na zasadzie "tylko czysty kod".

TomRiddle napisał(a):

No to się mylisz :D Bo "kontrolowany dług techniczny", to zwiększający się dług technologiczny. A jeśli zwiększy się do odpowiedniego poziomu, to koszt rośnie wykładniczo.

Ach, znowu żonglowanie definicjami. To kontroluj dług techniczny tak, żeby koszt nie rósł wykładniczo. To teraz ja dam Ci przykład: rozwijasz oprogramowanie, a po trzech latach zamieniasz starą platformę na całkiem nową, zrobioną przez inny zespół opłacony z przychodu pochodzącego z wcześniejszego wejścia na rynek. Nowa platforma nie będzie robiła tego samego, co stara, bo zmieniły się realia i stare rozwiązania się zdezaktualizowały. Pytanie brzmi: po co inwestować w starą platformę i wydłużać czas jej powstawania, skoro jej szacowany czas życia i tak wynosi trzy lata?

Poza tym rosnący wykładniczo koszt wcale nie jest problemem, jeżeli tylko przychody rosną szybciej! To jak z kredytem na rozwój firmy - spoko, niech ma on całkowity koszt na poziomie nawet i 100%, ale jeżeli dzięki niemu da się zarobić cztery razy więcej, to dalej się to opłaca.

TomRiddle napisał(a):

Poza tym, już pomijajac wszystko; to odnosisz się do biznesów, firm, projektów komercyjnych, terminach, zarobkac etc żeby mówić o tym jak wytwarzać oprogramowanie.

Właśnie o to się rozchodzi — Ty skupiasz się tylko na programowaniu i traktujesz je jako najważniejsze. Ja patrzę z perspektywy inżynierii, gdzie najważniejszy jest klient i przychód firmy.

TomRiddle napisał(a):

Ale spójrzmy na Open-Source'owe, non-profitowe biblioteki i aplikacje, publiczne; rozwijane za darmo, tylko po to żeby je stworzyć; co zaobserwujesz w takim środowisku. To, że biblioteki które są wysokiej jakości, są ciągle refaktorowane, testowane i ciągle usprawnienia to są te które mają mniej błędów, i częstsze release'y, a to z kolei znaczy że praca nad nimi jest szybsza i bezpieczniejsza.

Czyli jak idziesz do firmy, której celem jest zarabianie pieniędzy, to pracujesz tak, jakbyś pracował w projekcie "rozwijanym za darmo, tylko po to, żeby go stworzyć"?

TomRiddle napisał(a):

Jeśli dodasz do równania biznesy, managerów, presje czasu, dochody, to być może rozmowa będzie bliżej komercyjnej w pracy; ale odejdzie od tematu na który rozmawiamy, czyli wpływu refaktoru i wysokiej jakości kodu na szybkość i koszt rozwoju oprogramowania.

Rozmowa zaczęła się od narzekania na kod w dużej firmie. Firma ma zarabiać pieniądze i tworzenie oprogramowania nie jest jej celem samym w sobie.

@Afish: Ale Ty widzisz, że rozmawiamy na inne tematy zupełnie?

To o czym ja mówię; to to; że jeśli wszystko inne byłoby równe (tak jak równe jest w open-source'ach; wytwarzanie oprogramowania wysokiej jakości na starcie, jest bardziej opłacalne, dlatego że kod słabej jakości ciągnie nas w dół. I tutaj mówię tylko o metodologii wytwarzania oprogramowania, czyli refaktor, TDD, SOLID, dobre praktyki etc.

To o czym Ty mówisz, to po pierwsze nie tylko refaktor, tylko dowolna inwestycja w produkt która może się zwrócić lub nie w dowolnym czasie; (i to nie musi być refaktor, tylko pewnie też update biblioteki, zmiana technologii, ulepszenie infrastruktury), tak rozumiem to co mówisz. Bo wszystkie argumenty które podałeś można oddnieść do dowolnej inwestycji w produkt, która zwraca się nie od razu.

A po drugie próbujesz wykazać że możliwe są sytuacje, w którym przychód i sytuacja finansowa firmy, będą takie że będzie opłacalne najpierw zrobić kod niskiej jakości, a potem go nie zwiększać; ponieważ tymczasowe dochody firmy będą kompensować rosnące koszty projektu.

Nie wiem czy widzisz, ale to są dwa zupełnie inne tematy.

Możliwe, że są takie sytuacje jak mówisz; jasne. Może się tak zdarzyć, że będzie sytuacja w którym faktycznie nie zainwestowanie czasu na zrobienie lepszego produktu da nam więcej kasy (co prawda moim zdaniem tylko w dużych firmach, które mogą sobie na to pozwolić, bo startupy najpewniej nie będą miały tak dużego bufferu na początkowe rosnące koszty), ale tak.

Natomiast to nie zmienia tego co mówiłem w całym wątku; czyli tego, że poprawne wytwarzanie oprogramowania jest tańsze niż dodawanie techdebtu. To co Ty próbujesz pokazać to to; że mogą być sytuacje, w których gorzej znaczy lepiej. Czyli lepiej kupić coś gorszego taniej, bo może się tak stać że to wystarczy żeby potem mieć więcej kasy. Fine. Ale to nie znaczy że gorsze faktycznie jest lepsze.

Innymi słowy; jeśli dasz programiście ileś kasy; jakąś stałą liczbę; to za tą stałą liczbę; on będzie mógł wytworzyć więcej feature'ów jeśli zrobi dobrej jakości oprogramowanie i zrobi je szybciej, najpewniej. I potem do takiego oprogramowania, będzie można dodać jakiś jeden konkrenty feature taniej, niż gdyby to było źle zrobione. To jest to co chcę powiedzieć.

Dlatego że jakikolwiek techdebt nie dodasz, to on na 100% będzie miał większy koszt w przyszłości. Typu zaoszczedzisz teraz kilka godzin, ale stracisz tygodnie w przyszłości. To co Ty próbujesz wykazać, to to; że czasem opłaca się zyskać godzinę; i stracić tydzień w przyszłości; bo być może firma tak urośnie, że strata tych dwóch tygodni i tak będzie bardziej opłacalana. Maybe; zgadzam się że może tak być. Ale to nadal jest wymiana tygodnia vs godziny; i to jest to o czym mówię.

Podsumowując:

• Ja mówię o skuteczności jakiegoś środka
• Ty mówisz o zasadności użycia tego środka

I tym środkiem jest refaktoring

TomRiddle napisał(a):

Dlatego że jakikolwiek techdebt nie dodasz, to on na 100% będzie miał większy koszt w przyszłości.

No właśnie to nie jest prawda. Możemy się tu przerzucać argumentami, ale fakty są takie, że w wielu firmach ten dług techniczny sumarycznie wychodzi taniej. Tylko znowu, Ty pewnie mówisz o samym czasie na programowanie, a nie o koszcie mierzonym w najważniejszym zasobie firmy, czyli pieniądzach.

TomRiddle napisał(a):

Ale to nadal jest wymiana tygodnia vs godziny; i to jest to o czym mówię.

A tu znowu podajesz jakąś miarę "tygodnie vs godziny" tylko bez dowodów. Nawet jeżeli przyjmiemy, że to rzeczywiście jest taka różnica, to wielu firmom dalej się to opłaca. I to jest właśnie powód, dla którego wiele firm naciska na słabą jakość. I co więcej, profesjonalny inżynier oprogramowania powinien robić to samo — zwiększać dług techniczny w sposób kontrolowany, aby potem można było go zmniejszyć i sumarycznie zarobić więcej kasy. Nie żadne dogmatyczne "czyste kody", tylko zysk mierzony w pieniądzach.

Afish napisał(a):

TomRiddle napisał(a):

Dlatego że jakikolwiek techdebt nie dodasz, to on na 100% będzie miał większy koszt w przyszłości.

No właśnie to nie jest prawda. Możemy się tu przerzucać argumentami, ale fakty są takie, że w wielu firmach ten dług techniczny sumarycznie wychodzi taniej. Tylko znowu, Ty pewnie mówisz o samym czasie na programowanie, a nie o koszcie mierzonym w najważniejszym zasobie firmy, czyli pieniądzach.

Mówię o techdebcie samym w sobie. Nie mówię o stosunku kosztów oprogramowania do potencjalnych zysków firmy; o których Ty zdajesz się mówić.

TomRiddle napisał(a):

Ale to nadal jest wymiana tygodnia vs godziny; i to jest to o czym mówię.

A tu znowu podajesz jakąś miarę "tygodnie vs godziny" tylko bez dowodów. Nawet jeżeli przyjmiemy, że to rzeczywiście jest taka różnica, to wielu firmom dalej się to opłaca. I to jest właśnie powód, dla którego wiele firm naciska na słabą jakość. I co więcej, profesjonalny inżynier oprogramowania powinien robić to samo — zwiększać dług techniczny w sposób kontrolowany, aby potem można było go zmniejszyć i sumarycznie zarobić więcej kasy. Nie żadne dogmatyczne "czyste kody", tylko zysk mierzony w pieniądzach.

Zauważyłem już w poprzednim poście, że mówimy o dwóch różnych rzeczach.

Ty nadal mówisz cały czas o tym, że w pewnych okolicznościach zwiększenie kosztu wytworzenia oprogramowania, może przynieść zysk firmie;i ja się zgadzam, czasem tak może być. Jeśli firma ma odpowiedni budżet na to, żeby przez jakiś czas wspierać rosnące koszty wytwarzania oprogramowania; bo i tak przyszłe zyski to przebiją to spoko. Zgadzam się z Tobą.

Jak dla mnie to co piszesz już dawno zeszło na offtopic; bo pod to o czym mówisz, można też podciągnąć np owocowe czwartki i maszyny do kawy. Argumenty których używasz nie mówią o wytwarzaniu dobrego oprogramowania; tylko mówią o zarządzaniu jakością produktów względem ich potencjalnych dochodów.

Rozważania które poruszasz, są z natury "jeśli tutaj zrobię gorszy kod, taniej, to może na tym zarobię tyle, że mi się opłaci". Tylko to jest też prawdziwe z powiedzeniem "jeśli zatrudnię teraz x programistów, to może jak się skalkuluje to mi wyjdzie na plus", możęsz też to wziąć pod np ilość instancji swoich aplikacji, kasy którą wydasz na utrzymanie serwerów, marketing, wszystko.

Ty omawiasz ogólny temat tego w co się opłaca inwestować kasę w produkt, to bardzo szeroki temat; i próujesz na jego podsatwie wyciągać wnisoki nt tego czy refaktoring kodu jest opłacalny czy też nie.

Refaktoring zawsze jest opłacalny względem tego czy taka zmiana sprawi że utrzymanie aplikacji będzie tańsze. Zgadzam się też z Tobą, że Wynikowo nie opłaca się zmniejszyć kosztów o połowę, jeśli mamy w perspektywie zwiększenie zysków czterokrotnie. Ale to już jest zupełnie inny temat i wymaga innej uwagi!

Więc podsumowując. Jeśli wszystko inne jest równe, dobry kod, jest tym tańszy im mą wyższą jakoś. Natomiast to, czy używając go zarobisz więcej lub mniej kasy na utrzymanie go to jest zupełnie inna sprawa; i ja się nie chce pchać w taką dyskusję.

Przecież ja nie pracuję blisko sprzedaży, jestem zwykłym inżynierem oprogramowania, który wpływa na biznes od najniższego szczebelka. Reszty nie komentuję, bo bazuje na jakichś rzeczach, których nie powiedziałem.

Ja w ogóle nie uważam, że zawsze trzeba pisać oprogramowanie. Ale jak już piszemy, to metodyka jest tylko narzędziem do optymalizowania czasu i zasobów, a nie celem samym w sobie. Tak samo oprogramowanie nie jest celem samym w sobie. — Afish dziś, 14:53

@Afish: przechodzisz w defensywę zamiast konstruktywnie rozmawiać.

Optymalizacja czasu i zasobów to nie jest wszystko. Niektóre firmy przez długi czas tylko generują dług aż zdobędą rynek i wtedy skomercjalizują pomysł. Więc nie tylko chodzi o optymalizację zasobów, ale również o skalowanie. Jak sam napisałeś, 8k linii kodu w JS nie jest absolutnie skalowalne pod względem pisania kodu. Nie jesteś w stanie z takim kodem dojść do momentu, że uznasz produkt za skończony i tym samym projekt upada.

Spróbuję to przedstawić przez analogię. Załóżmy, że piszesz grę w asemblerze, masz budżet X i założyłeś sobie, że skoro w rok napisałeś pierwsze rendery to teraz jeszcze 4 lata i napiszesz całą grę, a budżet X wystarczy Ci na finansowanie tych 4 lat. Ale w trakcie developmentu przez te 4 lata zaczynasz zwalniać bo dokładanie nowych renderów się nie skaluje. Wszędzie widziesz takie same błędy i jak załatałeś błąd w jednym miejscu to później musisz robić copy-paste w następnym.

Oczywiście teraz możesz powiedzieć, że Twój wzór na refaktoring też optymalizuje takie spowolnienie projektu bo też masz metryki, którymi to mierzysz. Np. liczba zgłoszonych bugów i też liczysz ile kosztuje jeden bug. Tylko stwórz mi jeszcze jakiś dashboard i milion tooli do metryk, żebym to widział. To też jest czas i koszt projektu.

Są też inne czynniki. Np. firma się modernizuje, żeby ochronić aktualny przychód i przychód za 10 lat. Jak sfalsyfikujesz twierdzenie, że nowy kod pozwolił ochronić istniejący przychód? Albo, że refaktoring 10 lat temu pozwolił firmie przetrwać dzisiaj. Pamiętaj, że ludzie zmieniają pracę co 1,5 roku. Nikt już nie wie, że zrefaktorowałeś kod 10 lat temu w tej firmie i dzięki temu firma przetrwała.

twoj_stary_pijany napisał(a):

@Afish: przechodzisz w defensywę zamiast konstruktywnie rozmawiać.

Wyjaśniam, że nie jestem marketingowcem, a skoro takie poczyniono założenie, to nie będę się odnosił do dalszej części wypowiedzi, bo nie jest ona oparta na rzeczywistości. To nie jest defensywa, to zwykła oszczędność czasu.

twoj_stary_pijany napisał(a):

Spróbuję to przedstawić przez analogię. Załóżmy, że piszesz grę w asemblerze, masz budżet X i założyłeś sobie, że skoro w rok napisałeś pierwsze rendery to teraz jeszcze 4 lata i napiszesz całą grę, a budżet X wystarczy Ci na finansowanie tych 4 lat. Ale w trakcie developmentu przez te 4 lata zaczynasz zwalniać bo dokładanie nowych renderów się nie skaluje. Wszędzie widziesz takie same błędy i jak załatałeś błąd w jednym miejscu to później musisz robić copy-paste w następnym.

Tylko to nie jest sytuacja, o której ja mówię. Poprawną analogią byłoby, gdyby dało się wypuścić coś słabszej jakości po trzech latach i potem dalej rozwijać przez dwa kolejne, czyli w sumie całość zajęłaby 5 lat zamiast 4, ale zarabiałoby na siebie przez dwa lata zamiast przez rok. I już tak całkiem na marginesie dodam, że sama jakość kodu wydaje mi się być dość małym elementem tej układanki, o wiele większym jest wybór odpowiednich ficzerów i kolejności ich wydawania, bo zyski lub straty spowodowane w tym obszarze są zazwyczaj sporo większe.

twoj_stary_pijany napisał(a):

Są też inne czynniki. Np. firma się modernizuje, żeby ochronić aktualny przychód i przychód za 10 lat. Jak sfalsyfikujesz twierdzenie, że nowy kod pozwolił ochronić istniejący przychód? Albo, że refaktoring 10 lat temu pozwolił firmie przetrwać dzisiaj. Pamiętaj, że ludzie zmieniają pracę co 1,5 roku. Nikt już nie wie, że zrefaktorowałeś kod 10 lat temu w tej firmie i dzięki temu firma przetrwała.

Zgadzam się z tym, dlatego właśnie dziwią mnie te stwierdzenia, że refaktoring dzisiaj daje oszczędność tygodni vs godzin za jakiś czas. Tego nie da się określić "ogólnie", to bardzo zależy od kontekstu, sytuacji firmy, momentu rozwoju, rynku i wielu innych czynników. Tylko tak jak za półtora roku ludzie mogą odejść, tak samo za półtora roku projekt może zmienić się diametralnie i nasz dzisiejszy refaktoring się nie spłaci, więc trzeba go robić z głową.

To ile firma zarabia, jest tylko przeszkadzajką w zrozumieniu tego co się dzieje na prawdę w oprogramowaniu.

Ktoś kiedyś powiedział

Any moderatur can build a bridge that stands, but it takes an engineer to build a bridge that barely stands.

Jasne, jak porzucisz constrainy i rzeczywistość to można fajny soft pisać.

Natomiast to nie zmienia tego co mówiłem w całym wątku; czyli tego, że poprawne wytwarzanie oprogramowania jest tańsze niż dodawanie techdebtu.
Dlatego że jakikolwiek techdebt nie dodasz, to on na 100% będzie miał większy koszt w przyszłości.
Refaktoring zawsze jest opłacalny względem tego czy taka zmiana sprawi że utrzymanie aplikacji będzie tańsze.

Dam ci przykład z życia wzięty

Ja mający 0 xp oraz właściwie moja pierwsza web appka z więcej niż 2 endpointami, wcześniej z "prawdziwym" modelowaniem nie miałem wiele do czynienia

Jak sobie pewnie wyobrażasz to była kupa gówna, logika po kontrolerach i chyba tylko singletonów i globalnych zmiennych nie było

w dodatku po kilku miesiącach takiego klepania wywróciły się założenia biznesowe, więc pół projektu do napisania od 0 (a właściwie dostosowania) i tu już trochę coś poczytałem w międzyczasie nt. jak to pisać lepiej i faktycznie ciągłe refaktory, abstrakcje oraz testy do tego doszły,

później kolejne duże zmiany w appce, przez jakiś czas dodawanie nowych featuresów + testów i poszło na proda

przez >2 lat był chyba 2 poważniejsze bugi i z 3-4 małe no i generalnie jakoś to tam stało, refaktorować można było na pewno wiele, pewnie tak z 100-250h byś mógł tam wrzucić na refactor i do dobicia >90% pokrycia testami, ciężko powiedzieć precyzyjnie, ale dużo czasu jeszcze mogłeś tam spokojnie wpakować.

no i ok, w pewnym momencie przychodzi klient i mówi że spoko spoko, doróbcie mi tam XYZ feature, ale tak ogólnie to nastawcie się na to że ubijamy ten projekt za X czasu

czemu?

wykupiła nas firma A, która ma swój taki system

the point is, że to rzeczywistość weryfikuje czy decyzje były zasadne czy też nie. Można to było refaktorować i pakować w to $$ "bo łatwiej bedzie featuresy dodawac", a może przecież być tak że te featuresy i tak nie będą dotykać syfu i łatwo się je doda, albo w ogóle nie będzie czego dodawać.

jako programista nie przewidzisz przyszłości, a więc pakowanie ile się da czasu na "upiększanie" nie jest optymalne.

Jeśli wszystko inne jest równe, dobry kod, jest tym tańszy im mą wyższą jakoś.

wut?

Świeżo zatrudniony team lead, mistrz czystego kodu i FP, słucha prezentacji PO o tym, że nie ma czasu na technical debt, a unit testy dopisze firma z Indii.
(koloryzowane)

TomRiddle napisał(a):

Więc podsumowując. Jeśli wszystko inne jest równe, dobry kod, jest tym tańszy im mą wyższą jakoś.

Nie, to nie jest prawda. To stwierdzenie ma w sobie tyle ukrytych założeń, że nie da się go przyjąć. To jak mówienie, że lepiej jest kupić więcej w hurcie, bo wtedy cena jednostkowa jest niższa — to jest prawda, ale co w sytuacji, gdy potrzebne są ilości detaliczne, a nie hurtowe?

Najprostszy przykład: mam mały, dobrze określony zbiór wymagań, który nie zmieni się w czasie, który mogę na kolanie zaimplementować w tydzień, a samą aplikację mogę szybko (w 1 sekundę) przetestować end to end. Czy w takim przypadku bardziej opłaca mi się pisać perfekcyjny kod i testy jednostkowe do niego? Nie, bo implementacja będzie trwała dłużej i w efekcie kod będzie droższy, a będzie robił dokładnie to samo, co ten tańszy.

Inny przykład: kod ma być w użytku przez najbliższe 2 miesiące, potem zostanie wymieniony na coś innego. Czy opłaca mi się pisać perfekcyjny kod i wydłużać czas implementacji? Ponownie odpowiedź brzmi: nie.

Czy to są nierealne przykłady? Na pierwszy rzut oka tak, ale w rzeczywistości są to bardzo częste realia — pierwszy przykład to chociażby jakiś mikroserwis na boku albo osobny ficzer do aplikacji. Drugi przykład to dowolny kod integracyjny między starym a nowym systemem. Oczywistym jest, że gdy takich rzeczy nagle nazbiera się dużo, to w efekcie powstanie kupa, ale tu właśnie wychodzi umiejętność zarządzania długiem technicznym i intuicja, gdzie ciąć, a gdzie robić solidnie.

Nie można powiedzieć, że dobry kod jest tańszy. Dobry kod będzie tańszy, gdy się spłaci, a żeby to zaszło, to musi być dużo warunków. Można próbować powiedzieć, że "dobry kod jest tańszy w rozwijaniu", ale to też nie jest prawda — na przykład zaklepałeś fantastyczną warstwę dostępu do bazy X, a nagle trzeba ją wymienić na niekompatybilną bazę Y — i nagle się okazuje, że bardzo dużo kodu jest do wyrzucenia, a większy koszt jego pisania już się nie zwróci. Prawdziwym wydaje się dopiero stwierdzenie "dobry kod jest tańszy w rozwijaniu, gdy rozwój idzie w kierunku w większości zgodnym z zaplanowanym", tylko tutaj jest dość naiwne (jak pokazuje empiria) założenie, że przyszłość będzie taka, jak zaplanowaliśmy.

Afish napisał(a):

TomRiddle napisał(a):

Więc podsumowując. Jeśli wszystko inne jest równe, dobry kod, jest tym tańszy im mą wyższą jakoś.

Nie, to nie jest prawda. To stwierdzenie ma w sobie tyle ukrytych założeń, że nie da się go przyjąć. To jak mówienie, że lepiej jest kupić więcej w hurcie, bo wtedy cena jednostkowa jest niższa — to jest prawda, ale co w sytuacji, gdy potrzebne są ilości detaliczne, a nie hurtowe?

Nawet w argumencie który podałeś jest błąd.

Ceny hurtowe zawsze są tańsze niż detaliczne, nie ważne ile ktoś potrzebuje. Tak; musisz kupić ich więcej, co nie musi Ci się opłacić, wynikowo, ale nie prawdą jest powiedzieć że hurtowe nie są tańsze. Czyli mógłbyś kupić czegoś 1000, za 50gr; i wydać 500zł; więc wolisz kupić czegoś 10 za 1zł i zapłacić 10zł. 10zł jest mniejsze niż 500zł; co absolutnie nie zmienia faktu że 50gr < 1zł.

To w Twoich argumentach są dodatkowe założenia. Próbujesz wybronić swojego stanowiska dodatkowymi cechami, które mają sprawić "że na końcu wyjdzie taniej".

Z resztą; ta rozmowa już dawno zeszła z tematu skuteczności refaktoringu; także już nie będę jej kontynuował. Ty cały czas mówisz o opłacalonści wprowadzania jakichś rozwiązań i inwestycjach. Wypaczasz je dodatkowymi efektami i zjawiskami. Próbujesz wziąć całościowy obraz jakiejś gałęzi a potem na jej podstawie wyciągać globalne wnioski o jednostkowych elementach; tak się nie robi.

Mówiąc o elementach i cechach globalnych, przywołuj argumenty globalne.
Mówiąc o elementach i cechach lokalnych, przywołuj argumenty lokalne.

Ty przywołujesz globalne argumenty, do rozmowy o lokalnych elementach.

Najprostszy przykład: mam mały, dobrze określony zbiór wymagań, który nie zmieni się w czasie, który mogę na kolanie zaimplementować w tydzień, a samą aplikację mogę szybko (w 1 sekundę) przetestować end to end. Czy w takim przypadku bardziej opłaca mi się pisać perfekcyjny kod i testy jednostkowe do niego? Nie, bo implementacja będzie trwała dłużej i w efekcie kod będzie droższy, a będzie robił dokładnie to samo, co ten tańszy.

Jeśli na tym by się skończył development, i to byłby końcowy produkt do oddania; i nie wymagałby więcej pracy nad nim; czyli cała praca się kończy na wersji 1.0.0, oddajesz ją klientowi, on płaci i koniec; to tak. To masz rację.

Ale to prawie nigdy tak nie jest. Development projektu trwa znacznie dłużej; początkowy koszt wytworzenia pierwszej wersji to prawie zawsze jest 1-5% całego kosztu projektu; reszta schodzi na jego utrzymanie.

Inny przykład: kod ma być w użytku przez najbliższe 2 miesiące, potem zostanie wymieniony na coś innego. Czy opłaca mi się pisać perfekcyjny kod i wydłużać czas implementacji? Ponownie odpowiedź brzmi: nie.

Nie. Nie opłaca się.

Czy to są nierealne przykłady? Na pierwszy rzut oka tak, ale w rzeczywistości są to bardzo częste realia — pierwszy przykład to chociażby jakiś mikroserwis na boku albo osobny ficzer do aplikacji. Drugi przykład to dowolny kod integracyjny między starym a nowym systemem. Oczywistym jest, że gdy takich rzeczy nagle nazbiera się dużo, to w efekcie powstanie kupa, ale tu właśnie wychodzi umiejętność zarządzania długiem technicznym i intuicja, gdzie ciąć, a gdzie robić solidnie.

Drugi jest realny. Pierwszy, tylko przy założeniu żę oddasz projekt i więcej nie będziesz nad nim pracował.

Nie można powiedzieć, że dobry kod jest tańszy. Dobry kod będzie tańszy, gdy się spłaci, a żeby to zaszło, to musi być dużo warunków.

No jedynym warunkiem jaki widzę to ciągłość pracy nad nim. Tak długo jak się pracuje nad kodem, wtedy się to opłaci. Jeśli praca ustaje, robienie dobrego kodu nie ma sensu.

Można próbować powiedzieć, że "dobry kod jest tańszy w rozwijaniu", ale to też nie jest prawda — na przykład zaklepałeś fantastyczną warstwę dostępu do bazy X, a nagle trzeba ją wymienić na niekompatybilną bazę Y — i nagle się okazuje, że bardzo dużo kodu jest do wyrzucenia, a większy koszt jego pisania już się nie zwróci.

To wymaga technicznych kompetencji żeby to ocenić, i dużó doświadczenia.

Podejmując decyzję jak dobrze zaprogramować jakiś element, musisz wiedzieć jak duża jest szansa że to się opłaci i zwróci. W większości przypadków, szansa na to jest spora. Jeśli jest jakieśpodejrzenie albo pomysł, że być może to jedno konkretne roziwązanie zostanie zaraz wywalone, i użyjemy innego, to być może nie warto faktycznie go refatorować i testować.

Chociaż to też nie jest takie czarno białe; bo jeśli faktycznie zrobiłbyś pierwszą wersję nakładki na dostęp do bazy Y; to musiałbyś owszem, zmienić szczegóły implementacyjne, ale to nie było tak że wyrzucasz i robisz od nowa; tylko mógłbyś przejść powolną ewolucję z jednej bazy do innej; co w mojej opinii rónież byłoby tańsze niż napisanie jej od nowa.

Prawdziwym wydaje się dopiero stwierdzenie "dobry kod jest tańszy w rozwijaniu, gdy rozwój idzie w kierunku w większości zgodnym z zaplanowanym", tylko tutaj jest dość naiwne (jak pokazuje empiria) założenie, że przyszłość będzie taka, jak zaplanowaliśmy.

To jest właściwie dokładna odwrotność tego, po co się robi dobry, czysty kod. Refaktorujesz i utrzymujesz wysoką jakość kodu Właśnie po to żebyś mógł dodać zmiany których nie planowałeś, to jest cała idea. Dodanwanie loose-coupling, refaktorowanie, pisanie testów, korzystanie z wzorcow projektowych - całym sensem istnienia tych rozwiązań jest dokładnie to żebyś mógł łątwo i tanio dodać/zmienić/usunąć/zastąpić elementy których nie planowałeś.

Don't get me wrong; rozumiem jakie masz zdanie. Chcesz powiedzieć, że to nie jest tak żę refaktoring to jest zawsze w 100% way to go, i nie należy ślepo go robić "bo tak", zgadzam się. Znajdziesz zawsze przykłądy kiedy to się nie zwróci.

Ale, po pierwsze - to nie znaczy że refaktoring sam w sobie jest zły i nieopłacalny, bo jest opłacalny.
A po drugie - to nie zmienia faktu że jednak częściej niż nie, refaktoring jednak się opłaca bo w dużych firmach rozwijanie projektów ciągnie się latami; początkowy koszt tych projektów dawno zanik, i teraz jedyne koszty jakie istnieją to jego utrzymanie.
Po trzecie - w Twoich argumentach zupełnie nie bierzesz pod uwagę tego, że dobrzy programiści wykonują refaktoring ciągle i naturalne, oraz szybko; ktoś wprawny w robieniu poprawnego kodu nawet pewnie by nie zauważył że swoimi zmianami poprawia kod; nie mówiąc już o tym jak się postara - ja tak mam. Mam wrażenie że to co mówisz jest pisane z perspektywy osoby która nie jest dobra w refaktor, nie zna wzorców, nie refaktorowała dużo w życiu, i nie dbała nigdy o kod; i też nie jest płynna w testach.

Pozwolę czytającym ten wątek dojść do swoich zdań i przekonań.

TomRiddle napisał(a):

To w Twoich argumentach są dodatkowe założenia. Próbujesz wybronić swojego stanowiska dodatkowymi cechami, które mają sprawić "że na końcu wyjdzie taniej".

Patrzę z perspektywy osoby, która płaci za efekt. Nie za testy jednostkowe, nie za frajdę z zastosowania nowych bibliotek, nie za dyskusje o nazwach zmiennych, tylko za działający kod. Nie interesuje mnie, że hurt jest tańszy jednostkowo, skoro sumarycznie jest droższy, gdy ja potrzebuję detalu.

TomRiddle napisał(a):

Ale to prawie nigdy tak nie jest. Development projektu trwa znacznie dłużej; początkowy koszt wytworzenia pierwszej wersji to prawie zawsze jest 1-5% całego kosztu projektu; reszta schodzi na jego utrzymanie.

Tak, ale nie cały kod projektu jest rozwijany, wiele jego fragmentów jest właśnie napisanych raz w wersji 1.0.0 i tyle.

TomRiddle napisał(a):

Nie. Nie opłaca się.

Czyli twierdzisz, że lepiej jest zapłacić więcej za napisanie kodu, który ma określony krótki czas życia? Czyli sprowadzając do przesady — jak potrzebuję fizz buzza na 100 liczb, to Ty będziesz do tego pisał testy jednostkowe i wprowadzał wzorce projektowe?

TomRiddle napisał(a):

Drugi jest realny. Pierwszy, tylko przy założeniu żę oddasz projekt i więcej nie będziesz nad nim pracował.

No ale mówisz, że drugi realny przykład i tak się nie opłaca, chociaż pokazałem, że można zrobić taniej i uzyskać to samo?

Pierwszy też jest realny - zajrzyj do gita swojego projektu i zobacz, które fragmenty nigdy nie zostały zmodyfikowane.

TomRiddle napisał(a):

No jedynym warunkiem jaki widzę to ciągłość pracy nad nim. Tak długo jak się pracuje nad kodem, wtedy się to opłaci. Jeśli praca ustaje, robienie dobrego kodu nie ma sensu.

Dokładnie tak, jeżeli praca nad kodem ustaje, to nie ma co przesadnie w niego inwestować. Myk polega na tym, że to jest bardzo częsta sytuacja, tylko trzeba ją umieć zauważyć. Ba, pewnie większość biblioteczek używanych w Twoim kodzie działa na dokładnie tej samej zasadzie — z Twojej perspektywy praca nad kodem biblioteczki mogła się zatrzymać i nic to nie zmienia. Dokładnie tak samo jest w wielu aplikacjach, tylko trudniej jest zauważyć te fragmenty, za to jak już się je zauważy i umie tak organizować kod, żeby dało się niezależnie łączyć komponenty, to można znaleźć wiele miejsc, gdzie pójście na łatwiznę jest tańsze i nie ma negatywnych konsekwencji.

TomRiddle napisał(a):

To wymaga technicznych kompetencji żeby to ocenić, i dużó doświadczenia.

Dokładnie tak, tego nie zrobi junior.

TomRiddle napisał(a):

Chociaż to też nie jest takie czarno białe; bo jeśli faktycznie zrobiłbyś pierwszą wersję nakładki na dostęp do bazy Y; to musiałbyś owszem, zmienić szczegóły implementacyjne, ale to nie było tak że wyrzucasz i robisz od nowa; tylko mógłbyś przejść powolną ewolucję z jednej bazy do innej; co w mojej opinii rónież byłoby tańsze niż napisanie jej od nowa.

Jasne, możesz próbować kleić dwie niekompatybilne bazy. To się nazywa impedance mismatch i zazwyczaj kończy się kiepsko.

TomRiddle napisał(a):

To jest właściwie dokładna odwrotność tego, po co się robi dobry, czysty kod. Refaktorujesz i utrzymujesz wysoką jakość kodu Właśnie po to żebyś mógł dodać zmiany których nie planowałeś, to jest cała idea. Dodanwanie loose-coupling, refaktorowanie, pisanie testów, korzystanie z wzorcow projektowych - całym sensem istnienia tych rozwiązań jest dokładnie to żebyś mógł łątwo i tanio dodać/zmienić/usunąć/zastąpić elementy których nie planowałeś.

Tylko realia pokazują, że 30-40% oryginalnych założeń się zmienia (to za esejami w informatyce), więc szansa na wyrzucenie kodu jest spora. Trzymanie się go na siłę jest błędem, aplikację trzeba organizować tak, żeby móc łatwo pozbyć się jakiegoś fragmentu i zastąpić go całkiem niezależnym, a nie na siłę refaktoryzować.

TomRiddle napisał(a):

Don't get me wrong; rozumiem jakie masz zdanie. Chcesz powiedzieć, że to nie jest tak żę refaktoring to jest zawsze w 100% way to go, i nie należy ślepo go robić "bo tak", zgadzam się. Znajdziesz zawsze przykłądy kiedy to się nie zwróci.

A no widzisz, czyli jednak Wina leży w programistach, dlatego że myślą, że jeśli dla kogoś pracują, to ta osoba ma nad nimi władzę absolutną i jeśli PO powie "olać testy", albo "olać refaktor", albo cokolwiek innego, to większość posłusznie słucha; podczas gdy powinni się nie zgodzić. nie jest do końca prawdziwe.