eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plPodatkiGrupypl.soc.prawo.podatkiJPK - jaki program do faktur? › Re: JPK - jaki program do faktur?
  • Data: 2017-06-20 23:08:31
    Temat: Re: JPK - jaki program do faktur?
    Od: Sebastian Biały <h...@p...onet.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 6/20/2017 10:27 PM, Wojciech Bancer wrote:
    > Nie. On po prostu zrobi więcej i lepiej w tym samym czasie.

    Nie ma takich programistów którzy z własnej woli zrobią więcej w tym
    samym czasie. Może poza entuzjastami, ale z tego się da wyleczyć.

    > Czas jak wiadomo jest niezmienny, jest to etat.
    > I tylko gotowych klocków coraz więcej i coraz lepsze, lepsze wzorce,
    > możliwości pisania testów itp. itd.

    Nikt nie stosuje wzroców w nastepnej aplikacji z okolic SELECT * FROM
    customers WHERE. Nikt nie pisze testów. To nie ta działka. Tu się, jak
    to mowią znajmi, napierdala myszką. Głównie myszką. Taki dział
    programowania.

    > To co się pisało 10 lat temu vs to co się pisze teraz, to softy
    > o kosmicznej wręcz różnicy.

    Nie. Zaryzykuje że jakośc softu spada. Głównie z powodu przenoszenia
    funkcjonalności do chmury. A tam królują języki z poziomu mułu jak JS
    czy PHP gdzie pisze się byle jak. Ponadto jest duzo outsourcingu, czyli
    z grubsza polega to na tym że "poprawiamy soft po hindusach a potem będą
    po nas poprawiać ukraińcy" co demotywuje na starcie. Jakośc softu rośnie
    tu i tam, ale ogólnie spada. Sypać przykładami gdzie duże zespoły
    programistów z duzych korpo i duzej kasy produkują kompletnie popsute
    aplikacje można w setkach na minutę. 10 lat temu aż tak źle nie było,
    dzisiaj jestesmy przyzwyczajeni że połowa aplikcji ze sklepu na Androida
    wogóle sie nie odpala poza telefonem developera i nikomu to nie
    przeszkadza. W dużym sofcie tendencja taka sama.

    >> Jasne. Tylko że do tego trzeba mieć pojecie o projektowaniu. Jak ktos
    >> pisze nastepną aplikacje opartą o byle jak posklejany tasmą klejąca SQL
    >> i jakieś piedołowate widoczki to ide o zakład że wynikowy kod bedzie tak
    >> samo gówniany bez wzgledu na użyta technologię.
    > Tylko w czystym SQL to się nie pisze od łohoho i jeszcze trochę.
    > Jak ja studiowałem (2007), to już się od tego odchodziło.
    > Zweryfikuj więc może swoją wiedzę?

    Kilka(nascie) lat temu była chwilowa moda na ORMy. Zrobiło dużo hałasu i
    gdzieś wsiąkło, z nor wypełzli zwolennicy pisania "szybko i prosto" w
    SQLu co akurat było na fali popularności PHP/JS gdzie pisanie obiektowe
    "jest dla frajerów". Gdzieś był wykres z jakiejs procy naukowej że od
    kilku lat ORMy są coraz mniej stosowane na rzecz pisania byle jak w
    SQLu. Przypuszczalnie właśnie dlatego że jakośc software spada a ilość
    rośnie.

    >>> Jakby to co piszesz było prawdą, to wszyscy pisaliby w asemblerze.
    >> Nie. Róznica między C# i asm jest zasadnicza.
    > Czyli jaka?

    O kilka pięter większym poziomie abstrakcji który dalej *realne* zyski
    liczone w dziesiątkach tysięcy procent czasu pisania.

    >> Róznica między C# x oraz C# x+1 jest znikoma i pomijalna. Na pewno nie powinna
    >> generować kosztów u userów.
    > Nie no. Koszty generuje Microsoft ucinając wsparcie dla antyków.
    > I bardzo dobrze.

    Może i dobrze, ale skocz do jakiejś okolicznej przychodni, jak się
    zapatruja na wymianę 100 stacji na Viście które moga działać, ale jakieś
    korpo zdecydowało że nie bo nie. I to wcale nie jest decyzja MS tylko
    jakiegoś pustaka z managmentu któremu się przez przypadek zachciało
    zmienić kompilator na nowszy żeby zaoszczędzić 1% na szybkości neta i
    mieć bardziej zarąbiste ikonki.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1