somekind napisał(a):
No więc są sposobami osiągania celu, a nie celem samym w sobie.
Dla mnie jest to raczej na odwrót. Na jakość tworzonego przez siebie kodu mam wpływ, na to co pracodawca z nim zrobi już nie. Dla mnie zysk pracodawcy jest ewentualnym efektem ubocznym, a nie celem. Jak ktoś ma kiepskich menadżerów lub sprzedawców to nawet najlepsi programiści mu nie pomogą.
caer napisał(a):
Dla mnie jest to raczej na odwrót. Na jakość tworzonego przez siebie kodu mam wpływ, na to co pracodawca z nim zrobi już nie. Dla mnie zysk pracodawcy jest ewentualnym efektem ubocznym, a nie celem. Jak ktoś ma kiepskich menadżerów lub sprzedawców to nawet najlepsi programiści mu nie pomogą.
A jeśli ktoś nie ma co sprzedawać, to nawet programistów nie potrzebuje.
Można sobie pisać kod, którego celem jest bycie ładnym kodem, ale w komercyjnym działaniu zawsze liczy się tylko zysk.
Drogą skojarzeń doszliśmy do wniosku, że całą dyskusję można zamknąć jednym słowem "ZYSK". Wyczerpaliśmy temat :D
Zapytanie napisane przez programistę, który nie wie jak działa baza danych będzie zwracać pożądane dane (do tego wystarczy znajomość SQL), ale może być nieoptymalne. Jeżeli Waszym klientom to wystarcza i pani Zosia z księgowości jest zadowolona, że ma dwie godzinki wolnego gdy generuje się raport albo klient zawiesza działalność gdy na bazie zrobią się deadlocki, bo Wasze selecty nie chodzą po indeksach i lockują całą tabelę to spoko.
Oh tak, bo jak ktoś nie wie, jak działa baza danych, to już na 100% skutkiem tego będzie to, że pani Zosia będzie miała 2h wolnego :D Czemu tak się ograniczać, czemu nie zarzucisz dwoma tygodniami wolnego...? Przecież szara rzeczywistość jest taka, że w 99% przypadków nieoptymalny kod będzie wystarczający, bo pani Zosia poczeka 2s zamiast 1s i nawet nie zauważy. Płakanie w tej sytuacji, że kod działa dwa razy wolniej jest IMHO fanatyzmem.
Oczywiście, że lepiej jest coś wiedzieć, niż nie wiedzieć, szczególnie gdy mówimy o narzędziach, z którymi pracujesz. Oczywiście, że lepiej wiedzieć, co się dzieje pod spodem - choćby dlatego, że szybciej dojdziesz do błędu, jeśli zrozumiesz treść komunikatu, zamiast szukać na oślep. Ale też nie dramatyzujmy.... Przecież nikt nie zaczynał jako alfa i omega. Ja tam wciąż pamiętam, jak nie rozumiałam o co chodzi w tych całych obiektach, że to niepotrzebna abstrakcja jakaś. Nie wywołuje we mnie traumy fakt, że jakiś inny programista jeszcze czegoś nie ogarnął. Inaczej bym może podchodziła do sytuacji, gdzie ktoś pracuje w zawodzie 10 lat i dalej nie ogarnął, ale raczej nie spotkałam nikogo, kto by odmawiał rozwoju a utrzymał się w zawodzie...
Inna sprawa, że naprawdę nie ma potrzeby, by wszyscy ogarniali wszystko. Chyba właśnie po to mam w firmie specjalistów od bazy danych, żebym ja mogła skupić się na tym, co akurat ja umiem najlepiej...
aurel napisał(a):
Oh tak, bo jak ktoś nie wie, jak działa baza danych, to już na 100% skutkiem tego będzie to, że pani Zosia będzie miała 2h wolnego :D Czemu tak się ograniczać, czemu nie zarzucisz dwoma tygodniami wolnego...? Przecież szara rzeczywistość jest taka, że w 99% przypadków nieoptymalny kod będzie wystarczający, bo pani Zosia poczeka 2s zamiast 1s i nawet nie zauważy. Płakanie w tej sytuacji, że kod działa dwa razy wolniej jest IMHO fanatyzmem.
Gdy wejdę na pasy na drodze bez rozglądania się to w 99% przypadków przeżyję, ponieważ nie będzie jechał żaden samochód lub zdoła wyhamować lub mnie minąć, ewentualnie odniosę niegroźne obrażenia. Czy to znaczy, że od dziś mam zacząć wchodzić na jezdnie bez rozglądania się?
Dlaczego ignorancja stała się wartością, a niewiedza cnotą?! :(
Przecież szara rzeczywistość jest taka, że w 99% przypadków nieoptymalny kod będzie wystarczający
Pani Zosia najprawdopodobniej nie wybierala programu, ktory uzywa. Zrobil to dla niej szef byc moze w wyniku przetargu, ktory wygrala najtansza firma.
W wielu przypadkach czas reakcji interfejsu jest wazny i jak sie go oleje to uzytkownicy wybiora program bardziej uzywalny. Google kiedys chcialo zwiekszyc liczbe wynikow na jednej stronie kosztem zwiekszenia czasu reakcji o ulamki sekundy. Bardzo szybko tego pozalowali.
A Microsoft zwiększył liczbę wyników na wielu stronach kosztem zwiększenia czasu reakcji o ułamki sekund. Do dziś chwalą sobie tę decyzję.
Dlaczego ignorancja stała się wartością, a niewiedza cnotą?! :(
Chyba trochę odleciałeś. Nie przedstawiłam niewiedzy jako cnoty, tylko jako normalny stan, w jakim się jest, zanim wiedzę nabędziesz. No oczywiście poza @Haskell, bo ty przecież urodziłeś się już z całą wiedzą programistyczną tego świata. Brawo ty!
Pani Zosia najprawdopodobniej nie wybierala programu, ktory uzywa. Zrobil to dla niej szef byc moze w wyniku przetargu, ktory wygrala najtansza firma.
No samo życie, zapewne znasz trójkąt szybko/dobrze/tanio?
Smutna prawda jest taka, że czasem bardziej opłaca się zapłacić za dwa razy więcej czasu pani Zosi, niż za dwa razy szybszy program...
Haskell napisał(a):
Gdy wejdę na pasy na drodze bez rozglądania się to w 99% przypadków przeżyję, ponieważ nie będzie jechał żaden samochód lub zdoła wyhamować lub mnie minąć, ewentualnie odniosę niegroźne obrażenia. Czy to znaczy, że od dziś mam zacząć wchodzić na jezdnie bez rozglądania się?
Jak jesteś niewidomy, to wzrok ci nie pomoże xd
Jak jest ciemno zawsze możesz ustawić się tak, że między szybą przednią i drzwiową jest pewien element co utrudnia widzenie, wejdziesz na pasy, a gościu cię rozjedzie przypadkiem bo byłeś na dead strefie.
aurel napisał(a):
Chyba trochę odleciałeś. Nie przedstawiłam niewiedzy jako cnoty, tylko jako normalny stan, w jakim się jest, zanim wiedzę nabędziesz. No oczywiście poza @Haskell, bo ty przecież urodziłeś się już z całą wiedzą programistyczną tego świata. Brawo ty!
Ja też kiedyś nic nie wiedziałem, ale poznając kolejne aspekty pracy programisty zacząłem orientować się czego nie wiem i czego warto by się dowiedzieć. Wydawało mi się, że jest to coś naturalnego, że jak się czymś zainteresujesz, to zgłębiasz kolejne tajniki, czytasz książki, oglądasz tutoriale, chodzisz na konferencje czy zadajesz pytania. Podobnie wydawało mi się, że jak mam coś robić profesjonalnie i zarabiać w ten sposób na chleb, to w naturalny sposób chcę robić to jeszcze lepiej, żeby zabezpieczyć swoją przyszłość i mieć więcej możliwości zawodowych. Niestety odwiedziłem to forum i dowiedziałem się, że "programista jest użytkownikiem biblioteki i nie musi wiedzieć jak ona działa" albo "mamy w zespole programistów, którzy napiszą każde zapytanie, ale z wiedzą o indeksach jest już gorzej". Może teraz rozumiesz o co mi chodziło z tą "cnotą" i "niewiedzą"...
Zgoda, że co innego pisać poprawne zapytania, a co innego optymalne i poprawne zapytania. I to nie musi być kwestia sekund, tylko już minut. Jak zaczynałem swoją przygodę z bazami danych, aplikacja tworzyła skomplikowany raport od 20 minut do ponad godziny. Po wielu tygodniach prób i czytania o optymalizacji itd. zszedłem do 2 do 4 minut. Tak więc wszystko zależy, co robisz. Jeśli zrobisz szybko produkt i można go sprzedać i klient nie marudzi, to jesteś cenniejszym pracownikiem niż ten, który poświęci na produkt 2 razy więcej czasu, ale zrobi go najoptymalniej albo najzajebiściej. To jest tak jak z lekarzem na rejonie. 5 minut na pacjenta. Grunt to przyjąć największą ilość pacjentów, żeby kasa się zgadzała. Potępiam to, ale tak niestety jest. I możesz to zmienić, zakładając własną firmę. Ale wtedy tym bardziej musi Ci się kasa zgadzać ;) Więc wszystko tak naprawdę zależy.
aurel napisał(a):
Oh tak, bo jak ktoś nie wie, jak działa baza danych, to już na 100% skutkiem tego będzie to, że pani Zosia będzie miała 2h wolnego :D Czemu tak się ograniczać, czemu nie zarzucisz dwoma tygodniami wolnego...? Przecież szara rzeczywistość jest taka, że w 99% przypadków nieoptymalny kod będzie wystarczający, bo pani Zosia poczeka 2s zamiast 1s i nawet nie zauważy. Płakanie w tej sytuacji, że kod działa dwa razy wolniej jest IMHO fanatyzmem.
Tylko, żeby wiedzieć, że to będą 2 sekundy zamiast jednej, trzeba to zmierzyć. A ktoś, kto umie i widzi potrzebę zmierzenia tego, raczej syfu nie zostawi.
A, że mało kogo to interesuje, po podczas klepania kolejnych wspaniałych formatek wszystko działa błyskawicznie, to efekty nieraz są tragiczne.
Filtrowanie danych po stronie aplikacji, select n+1, naprawianie go poprzez includowanie wszystkich powiązanych tabel, które generuje makabryczny SQL, bezmyślne dobieranie typów danych, próby używania ORMów jako narzędzi ETL albo systemów raportujących, testowanie prędkości działania na minimalnej ilości danych... to nie są zmyślone przypadki tylko typowe, codzienne błędy programistów.
Inna sprawa, że naprawdę nie ma potrzeby, by wszyscy ogarniali wszystko. Chyba właśnie po to mam w firmie specjalistów od bazy danych, żebym ja mogła skupić się na tym, co akurat ja umiem najlepiej...
Ale nie trzeba się znać na tuningu wydajnościowym baz danych, żeby umieć odpalić profilera i choćby rzucić okiem na to, ile i jakich zapytań generuje kod, który właśnie napisaliśmy.
@somekind ale wiesz ze premature optimization is the root of all evil? :) Optymalizacje robi się tam gdzie są potrzebne i kiedy są potrzebne. Oczywiście jak ktoś robi select n+1 albo sortuje dane w O(n!) to znaczy że jest idiotą i nie zaliczam tego w ramach "optymalizacji". Ale nie dajmy się zwariować - jeśli system działa i nikt się nie skarży (i nie ma tam błędów, bo taki select n+1 to jest zwyczajny bug) to nie ma też sensu siedzieć tydzień z profilerem i dopisywać n-poziomowe cache, albo przenosić się z ORMa na złożone natywne zapytania żeby urwać kilka ms.
Jak ktoś będzie klepał HFT albo jakiś hard real-time to pewnie ma to jakieś uzasadnienie, ale w systemie raportowania dla pani Basi zwyczajnie mija się to z celem, bo ona nie zauważy, a system nagle zrobi się znacznie bardziej złożony i koszt jego utrzymania wzrośnie niewspółmiernie do uzyskanych korzyści.
Haskell napisał(a):
Czy macie czasem poczucie, że rozwiązujecie co raz bardziej wirtualne problemy na co raz bardziej wirtualnym sprzęcie? W dzisiejszym, pędzącym świecie musimy poruszać się na bardzo wysokich poziomach abstrakcji, ponieważ gonią nas terminy i musimy dowieźć oprogramowanie na czas. Piszemy kod pod wirtualne maszyny, które pracują na nieznanym nam systemie operacyjnym, na nieznanym sprzęcie, często jeszcze w chmurze. Wielu programistów Javy czy C# szczególnie tych młodych zapomniało już co to jest zarządzanie pamięcią, jej alokowanie, zwalnianie czy odwoływanie się do niej. Frameworki w stylu Hibernate zwalniają nas z potrzeby pisania kodu SQL, a wielu Javowych wymiataczy nie wie nawet czym jest strona w bazie danych. Piszemy z umiłowaniem lambdy w Kotlinie bez świadomości, że tworzymy tysiące małych obiektów, które zaśmiecają pamięć i obciążają GC. Programujemy wątki, które wykonuje JVM na wieloprocesorowych maszynach, na wielordzeniowych procesorach, które często jeszcze używają hyper-threading, a często nie mamy świadomości czym jest semafor i synchronizacja. Zawsze tam pod spodem jest jakiś sprzęt i wszelkie problemy na niskich poziomach abstrakcji rzutują na ten na którym się poruszamy. Jak szczur przegryzie kabel w serwerowni, to zapomnijcie o tym, że rozwiązanie będzie w waszej dokumentacji...
Idąc tym tropem można by rzec - "Wielu programistów Javy, czy C#, szczególnie tych młodych, zapomniało już co to jest wyszukiwanie żył rudy miedzi, cyny, żelaza i innych cennych kruszców. Wielu zapomniało już nawet jak się zabezpiecza szyby kopalniane i jak się przetapia wydobytą rudę. Nikt już praktycznie nie kopie krzemu i nie robi z nich wafli. Mało kto kładzie luty na płytach głównych i testuje napięcia na układach. Czy ktoś pamięta jeszcze, jak się pisze bios? Ah, ah... Gdzie ta młodzież zmierza... Tylko im maszyny wirtualne w głowach, co raz to wyższe stopnie abstrakcji, jednolinijkowce, które robią rozproszony mining danych i plotują 1000 zmiennych na 10 wymiarowych plotach. Ah, ah..."
To nieuchronne, że rozwój technologii i wiedzy prowadzi do co raz to wyższych stopni abstrakcji, co raz to węższych dziedzin specjalizacji. W przypadku zaistnienia osobliwości technologicznej istnieje również ryzyko, że nikt nie będzie do końca rozumiał proponowanych przez komputery rozwiązań i ludzkość skupi się na wyznaczaniu celów. Niestety nie mamy możliwości bycia perfekcyjnymi we wszystkich aspektach życia, które zostały do tej pory przez ludzkość opracowane - tyczy się to również programowania. Kolejne wysokopoziomowe frameworki itp., to tylko co raz to bardziej wyrafinowane "młotki". Zasada w ich przypadku jest ta sama co w innych dziedzinach usług, przemysłu, gospodarki.
Shalom napisał(a):
Optymalizacje robi się tam gdzie są potrzebne i kiedy są potrzebne.
Nie wiem jak Ty, ale ja piszę w Management Studio z włączoną opcją "Include Actual Execution Plan". To już jest zboczenie?
@Haskell jeśli robisz to żeby sie upewnić że wykonanie działa zgodnie z twoimi założeniami to ok. Ale jeśli non stop myślisz czy zmiana połowy indeksów na gridowe a drugiej połowy na drzewo B- zamiast B+, zeby urwać 3ms na zapytanie, to znaczy że jesteś nienormalny ;)
Shalom napisał(a):
@somekind ale wiesz ze
premature optimization is the root of all evil? :) Optymalizacje robi się tam gdzie są potrzebne i kiedy są potrzebne.
Ten cytat z Knutha jest często nadużywany i czasami przedstawiany jako powód, aby w ogóle nie myśleć o wydajności przy tworzeniu systemu. Niestety często okazuje się, że jeśli na końcu system mocno nie domaga wydajnościowo, to jedyne co można zrobić to przepisać dużą część na nowo.
Knuthowi chodziło tylko o to, aby nie robić drobnych mikrooptymalizacji w kodzie, bez poprzedniego sprawdzenia profilerem czy mają one sens. Natomiast jak najbardziej wskazane jest uwzględnianie aspektów wydajnościowych bardzo wcześnie, już na etapie projektowania systemu. A tego nie da się zrobić bez podstawowego rozumienia paru niższych warstw abstrakcji, ponad którymi będziemy się poruszać.