eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingJakie typowanie jest najlepsze i dlaczego statyczne?Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
  • Data: 2013-02-07 23:07:34
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 07/02/2013 09:34, Maciej Sobczak wrote:
    > W dniu środa, 6 lutego 2013 23:18:56 UTC+1 użytkownik Andrzej
    > Jarzabek napisał:
    >
    >> Więc liczenie wydaje mi się zbędnym etapem, bo jeśli z refleksji i
    >> z liczenia wynikają sprzeczne wnioski,
    >
    > Nie zrozumiałeś. Nie mogą wyjść sprzeczne, bo to są różne etapy
    > jednego procesu. Refleksja prowadzi do określenia wymagań
    > (checkboksów), natomiast ich liczenie odbywa się później, przy
    > wyborze konkretnego narzędzia. Nie rozumiem, gdzie tu może powstać
    > sprzeczność.

    Normalnie, reflektujesz, wypisujesz checkboxy, z refleksji wynika, że
    biorąc pod uwagę wszystkich checkboxy A jest lepsze od B, ale A ma tylko
    5 checkboxów po swojej stronie, a B 15, więc z liczenia wychodzi, że B
    jest lepsze.

    >> Ale też rozwijać można się w bardzo różnych kierunkach. Jako
    >> javowiec możesz spokojnie rozwijać się w kierunkach, w których
    >> zalety Scali nigdy nie wypłyną: TDD, refaktoryzacja, design
    >> patterns, Spring, CI, cotamjeszcze.
    >
    > Nie! Nie da się. Nie można wprowadzić Springa czycotamjeszcze, bo...
    > <tu wstaw wszystkie swoje argumenty, które do tej pory napisałeś>.

    Jakie argumenty? Przecież ja nie twierdzę, że czegoś nie można czy się
    nie da.

    >> Konflikt przejawia się np. tym, że w twojej metodzie checkboksowej
    >> pracodawca wpisałby checkboska "trudniej będzie wymieniać
    >> programistów" po stronie wad, natomiast programista mógłby go
    >> wpisać po stronie zalet.
    >
    > Pracodawca musi się zdecydować, jak widzi rolę swojego biznesu na
    > rynku, np. czy chce być twórcą rozwiązań, czy ich integratorem,
    > liderem, czy w ogonie, czy chce podejmować ryzyko inwestując i być
    > może tracąc czy też odwrotnie, itp. Z tego wynika też różne ryzyko
    > podejmowanych działań a w tym są takie rozważania jak to, czy coś
    > jest trudno wymienić. Podobnie jak z samochodami - w tych lepszych
    > też różne rzeczy się trudniej wymienia.

    Nawet jeśli jest liderem itd. to konflikt interesu nadal istnieje.

    >> Dyskutujesz z moją dygresją, że może nie należy pozwolić
    >> programiście wybierać technologii, bo programista może wybrać to,
    >> co go osobiście interesuje (jest cool, modne), a nie to, co jest
    >> dobre dla projektu.
    >
    > A skąd wiadomo, co jest dobre dla projektu?

    Z doświadczenia, z analizy, z intuicji - nie jest to pewna wiedza, ale
    jakaśtam jest.

    > A może akurat w firmie,
    > która chce być liderem branży (albo nawet jakiejś niszy) i chce
    > podejmować ryzyko techniczne, właśnie większy entuzjazm programisty
    > jest dobry?

    Zapewne, pytanie jednak na ile korzyści z entuzjazmu przekraczają lub
    nie przekraczają strat wygenerowanych owym entuzjazmem.

    > Kto o tym ma decydować? (hint: znowu checkboksy, choć na
    > innym poziomie)

    Nie ma chyba uniwersalnej odpowiedzi na to pytanie, a ja na pewno jej
    nie mam. W praktyce napisałem, kto może decydować, i cały czas piszę
    dlaczego.

    >> Natomiast zauważę, że w wielu instytucjach takie decyzje podejmuje
    >> się na jakichśtam stanowiskach kierowniczych typu "head of
    >> development" czy CTO.
    >
    > I czy to sprawia, że nie mogą być podjęte? Nadal mogą.

    Oczywiście ale rozmawiamy o krytyce opcji "o wyborze języka decydować
    będzie ten, kto będzie go używał".

    >> Cały czas jednak problem w konflikcie interesów - po refleksji dla
    >> pracownika dobre może być co innego niż dla pracodawcy.
    [...]
    > Scalę czy nie używać. Konflikt, o którym piszesz, nie musi wystąpić a

    Musi. Znaczy niekoniecznie tak jest, że wybór akurat Scali jest dobry
    dla pracownika a niedobry dla pracodawcy, ale konflikt jest immanentny w
    stosunkach pracownika i pracodawcy.

    >> Ale rekrutujesz, bo potrzebujesz programistów do tego akurat
    >> projektu.
    >
    > Albo po to, żeby ogólnie rozwijać firmę. Nie muszę mieć na myśli
    > żadnego konkretnego projektu.

    Rozmawiamy o ryzyku stuacji, kiedy program dzięki zastosowania nowego
    języka pięknie się rozwija, a tu nagle pracownik odchodzi i to, co
    zyskałeś na Scali stracisz przez to, że przez długi czas nie możesz
    znaleść nikogo nowego na to stanowisko. Zatrudnienie kogoś na innym
    stanowisku nie rozwiąże problemu - twój program w Scali nadal radzi
    sobie gorzej, niż gdyby pozostał przy Javie.

    > Ogólnie mam wrażenie, że kręcimy się w kółko w tej dyskusji, niczego
    > nowego już do niej nie dodając. Chyba mamy różne doświadczenia z
    > projektów o różnych kulturach ich prowadzenia.

    Jeśli jednak mi imputujesz, że twierdzę, że decyzji o adopcji
    (metafotycznej) Scali nie da się podjąć, to przynajmniej to mogę sprostować.

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

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: