Pomysl na poranny flame (specjalnie przejaskrawiam): skad sie bierze cisnienie na nauke i poznawanie jak najnowszych frameworkow, wersji jezykow etc. Dlaczego ludzie nie sa chetni to pracy z legacy codem, czy tzw. dojrzalymi technologiami (czyli np. Java 1.6 :) ), badz pracy przy naprawianiu bugow (ja osobiscie lubie taka prace, zwlaszcza gdy po roku czy dwoch widac jak udaje sie projekt usprawnic i wyprowadzic na prosta). A co najciekawsze skad sie bierze rozjazd miedzy tym o co jest sie pytanym na rozmowach kwalifikacyjnych (bardzo czesto o nowosci) jak pozniej sie okazuje ze tak naprawde praca polega na utrzymaniu 20 letniego systemu.
0
0
Co do ostatniego to mam wrażenie, że kazdy chce być na czasie. I jak jesteś na rekrutacji i przepytuje cię kilka programistów i pokażesz, że znasz rózne nowe technologie, to myślę, że szczególnie jeśli ci programisci pracuja z legacy kodem, beda chetnie patrzec na kogos, kto moze wniesc jakis powiew swiezosci w projekt. Projekty są jakie są. Trzeba get shit done. Ale zatrudniajac programiste wydaje mi sie, ze patrzy sie czesto na to, co dana odoba moze wniesc do calego zespolu (wymiana wiedzy itp.) a nie tylko to co moze zakodować.
Dlatego pewnie to co na rozmowie rozni sie od codziennej pracy, Na rozmowie sprawdzaja cie jako czlowieka, a w pracy po prostu robisz to co jest do zrobienia, nawet jesli jest to shit, ktory musi być zrobiony,
Co do fascynacji nowymi technologiami, to jest to wg mnie do pewnego stopnia dobre (bo ciagle sie cos usprawnia w jezykach, bibliotekach, narzedziach, podejsciach i dobrze byc na czasie), z drugiej strony czesto sie to przeradza w dosc plytkie podejscie zachwytu kazda nowoscia, zamiast doceniac rzeczy sprawdzone... (cos jak fascynacja Gwiazdką Pop Sierpnia 2015, zamiast Madonną)
1
Też mnie to zastanawiało, ale potem przyszło mi odgadnąć czemu pod IE6 document.getElementById("a") zwraca element o id "b" i już wszystko zrozumiałem. Technologia ma nam pomagać, a nie tworzyć nowe problemy.
0
Bo nie chcesz "przespać" na takiej zasadzie Nokia olała smartfony i już Nokii nie ma... jednocześnie każdy chce stworzyć "coś wiekopomnego" i powstają gigantyczne ilości bibliotek, frameworków czy "przełomowych rozwiązań".
0
Dobra, czas na straszne wyznanie.
Lubię pracę z legacy codem :|
Najbardziej to lubię się go pozbywać. Bardzo miło się patrzy, jak znikają setki linii redundantnego kodu.
A skąd dążenie do nowego? No właśnie stąd, że sporo legacy code'u widziałam i wiem, jak ciężko czasem z nim bywa. Dlatego właśnie jak piszę coś nowego, to nie chcę już za tydzień słyszeć, że framework traci wsparcie, albo że nie otworzę projektu po aktualizacji systemu...
0
Każda technologia ma błędy i są z nią jakieś problemy.
Nowe technologie eliminują część znanych błędów i problemów.
Dodają co prawda nowe, ale przynajmniej na stan wiedzy kiedy powstają mniej uciążliwe.
To widać już nawet w samych językach programowania:
kiedyś ludzie pisali dłutem na glinanych tabliczkach, później powstał asm bo tak było wygodniej, później powstał C bo tak było wygodniej, później powstał C++ bo tak było wygodniej, teraz jest epoka Javy/C# bo tak jest szybciej i wygodniej, ale już czają się Pythony i inne w których pisze się jeszcze szybciej.
Ta szybkość powstawania kodu ma bezpośredni wpływ na koszt wytworzenia oprogramowania więc jest silne ciśnienie biznesowe i zroworozsądkowe żeby koszty ograniczać.
0
Jakkolwiek lubię javę i w niej piszę to trzeba przyznać, że wieczna nie będzie, i coś ją w końcu wyprze bo będzie umozliwiać pisanie większych systemów przy tym samym wysiłku.
Czy to będzie python, scala, golang czy coś innego to już kwestia wtórna.
0
aurel napisał(a):
Dobra, czas na straszne wyznanie.
Lubię pracę z legacy codem :|Najbardziej to lubię się go pozbywać. Bardzo miło się patrzy, jak znikają setki linii redundantnego kodu.
A skąd dążenie do nowego? No właśnie stąd, że sporo legacy code'u widziałam i wiem, jak ciężko czasem z nim bywa. Dlatego właśnie jak piszę coś nowego, to nie chcę już za tydzień słyszeć, że framework traci wsparcie, albo że nie otworzę projektu po aktualizacji systemu...
Skoro da się kod przepisać w rozsądnym czasie to znaczy, że nie jest tak bardzo źle, bo musi przestrzegać jakiejś architekturę.
Jeśli się odziedziczy kod, który nie ma architektury (nie ma rozdzielonych warstw, wszystko łączy się za wszystkim) w połączeniu z dużą ilością funkcjonalności, to się po prostu nie da tego przepisać.
Naprawianie legacy kodu, może być przyjemne, ale to zależy od tego ile czasu trzeba by najpierw go zrozumieć, potem znaleźć problem, a na koniec ustalić jak naprawić by nie było nowego błędu.
0
w sumie to do tej pory sie nie spotkalam z jakimis wielkimi innowacjami na rozmowach (no ale nie pracuje w webdevie czy mobile ktore bardzo dynamicznie sie rozwijaja) niemniej z punktu widzenia firmy moze to miec to sens, chocby z powodow marketingowych ;)
osobiscie, wieksza satysfakcje sprawia mi naprawienie beznadziejnej architektury, optymalizacja czegos co wydawalo sie optymalne czy znalezienie i usuniecie buga ktory do tej pory nikt nie rozpoznal niz pisanie czegos od zera w nowszym, lepszym stylu. lubie stopniowo dodawac nowinki, kombinowac zeby stare i nowe elementy wspolpracowaly itp.
mysle ze praca z najnowszymi rozwiazaniami znanymi ma oczywiscie swoje wielkie plusy, jednak jakos nigdy mnie do tego nie ciagnelo, wole 'masterowac' klasyke
0
MarekR22 napisał(a):
Skoro da się kod przepisać w rozsądnym czasie to znaczy, że nie jest tak bardzo źle, bo musi przestrzegać jakiejś architekturę.
Jeśli się odziedziczy kod, który nie ma architektury (nie ma rozdzielonych warstw, wszystko łączy się za wszystkim) w połączeniu z dużą ilością funkcjonalności, to się po prostu nie da tego przepisać.
Od braku architektury gorsza jest tylko zła architektura. Bo nie mając żadnej, można ją zacząć wprowadzać, przepisując porządnie system kawałkami.
Jeśli masz skopaną architekturę, to nie możesz niczego ruszyć, więc niczego nie poprawisz.
0
Zła czy dobra to pojęcie względne. Kiedyś dobra architektura to była architektura WinApi i MFC. Dzisiaj obie są złe.
Za jakiś czas architektura MVC będzie już zla bo ktoś sobie coś nowego wymysli i tylko to będzie dobre.
0
katelx - czyli widze ze sa osoby ktore podchodza do tego podobnie jak ja. Moze szkoda ze nie dopisalem na poczatku zalozenia ze Legacy Code wcale nie musi oznaczac tego samego co <przymiotnik kojarzacy sie z odchodami, dziadostwem etc> kod. Bo praca z takim bez wzgledu na technologie nie jest przyjemna.
2
Szczery Jacek napisał(a):
Zła czy dobra to pojęcie względne. Kiedyś dobra architektura to była architektura WinApi i MFC. Dzisiaj obie są złe.
To nie są architektury tylko technologie.
Za jakiś czas architektura MVC będzie już zla bo ktoś sobie coś nowego wymysli i tylko to będzie dobre.
MVC to nie archiektura tylko wzorzec projektowy warstwy prezentacji, który ma już ponad 40 lat. I na pewno nigdy nie będzie zły, co najwyżej będzie nieadekwatny do niektórych zastosowań, tak jak zresztą teraz.
0
Może nieprecyzyjnie się wyraziłem. Chodziło o architekturę, którą posiada WinApi albo MFC. Gdyby dziś ktoś tak pisał, to należałoby orzec, że jest to "brak archutektury" czyli podobno to najgorsze co może być.