Czy uważacie, że nadchodzi era gdzie programista dający tylko wartość w postaci nowych funkcjonalności kończy się? Czy może już dawno się skończyła? Czy może nigdy nie istniała? Moja projekty zawsze były nastawione typowo na funkcjonalności ale rzadko była potrzeba zapewienia wymagań niefunkcjonalnych. Szukam dla siebie dalszego kierunku rozwoju i zacząłem myśleć właśnie od tej strony a dokładnie to nawet nad studiami i pierwsze do głowy przychodzą mi kwestie bezpieczeństwa i analizy. Czy to nie jest tak, że za chwile typowy programista będzie musiał ogarniać więcej rzeczy niż znać technologie typowo zapewniające dostarczenie funkcjonalności dla danego biznesu?
0
1
Bo trzeba wiedzieć wszystko o czymś i coś o wszystkim.
3
znaczy, że co? ma też kawę przynosić TL czy sprzątać biuro po godzinach?
Bo nie masz chyba na myśli tego, że należy tak pisać kod (implementując jakąś funkcjonalność) aby był "czysty", bezpieczny i wydajny - to się powinno samo przez się rozumieć
0
abrakadaber napisał(a):
znaczy, że co? ma też kawę przynosić TL czy sprzątać biuro po godzinach?
Bo nie masz chyba na myśli tego, że należy tak pisać kod (implementując jakąś funkcjonalność) aby był "czysty", bezpieczny i wydajny - to się powinno samo przez się rozumieć
Przez wymagania niefunkcjonalne mam na myśli wydajność, skalowalność, bezpieczeństwo. Bo to są obowiązki, które trochę rozchodzą się po testerach, devopsach czy administratorach a nie wiem czy tego nie należy z powrotem "pierwotnie" nałożyć na programistę. Tylko za chwile okaże, się, że jest tego za dużo jak na jedną role.
0
Wszystko to moje przemyślenia i widzimisię
Należy rozróżnić dwa typy projektów - tam gdzie jesteś alfą i omegą (czyli twoje zadania zaczynają się od zbierania wymagań od klientów, przez wymyślenie architektury po zakodowanie całości) od projektów wieloosobowych/wielozespołowych, gdzie masz swoją działkę jako programista. Tymi pierwszymi nie będę się zajmował, co do tych drugich to:
wydajność, skalowalność, bezpieczeństwo każda z tych "rzeczy" ma zarówno wymiar globalny dla aplikacji jak i lokalny.
- wydajność - żeby serwer był odpowiednio mocny, żeby load balancer działał poprawnie, żeby na bazie były indeksy itp to tym się powinni zajmować architekci, devopsowie, bazodanowcy itd. Ale optymalizacje na poziomie metody, w czym przechowywać lokalne (w kontekście zmiennych) dane aby dostęp do nich był szybki, jakiego użyć algorytmu itd to już odpowiedzialność programisty.
- skalowalność - to żeby można było postawić np. server RESTowy na kilku maszynach i kierować zapytania do najmniej obciążonego to robota speców od tego, ale programista może napisać 3 metody, każda na 500 linii z czego 3/4 tych metod to copy-paste a może też wspólny kod wydzielić, odchudzić metody albo nawet rozbić na mniejsze itd
- bezpieczeństwo - żeby połączenia do serwera były szyfrowane, żeby nie było dostępu do bazy danych z zewnątrz, żeby DDoS można było szybko wykryć i zablokować itp to nie działka programisty ale żeby hasło w bazie nie było zapisane otwartym tekstem, żeby nie dało się zrobić SQL injection, żeby wrażliwych danych nie zapisywać do logów, ba żeby nie generować exceptionów co chwila to znowu zadanie na poziomie programisty.
Generalnie uważam, że część rozwiązań powinna być narzucona w opisie wymagań/problemu (ticketa), w szczególności te, które są wspólne w wielu miejscach aplikacji (np. dodać logowanie użytkownika. Hasło ma być szyfrowane SHA512)
0
abrakadaber napisał(a):
Wszystko to moje przemyślenia i widzimisię
Należy rozróżnić dwa typy projektów - tam gdzie jesteś alfą i omegą (czyli twoje zadania zaczynają się od zbierania wymagań od klientów, przez wymyślenie architektury po zakodowanie całości) od projektów wieloosobowych/wielozespołowych, gdzie masz swoją działkę jako programista. Tymi pierwszymi nie będę się zajmował, co do tych drugich to:
wydajność, skalowalność, bezpieczeństwokażda z tych "rzeczy" ma zarówno wymiar globalny dla aplikacji jak i lokalny.
- wydajność - żeby serwer był odpowiednio mocny, żeby load balancer działał poprawnie, żeby na bazie były indeksy itp to tym się powinni zajmować architekci, devopsowie, bazodanowcy itd. Ale optymalizacje na poziomie metody, w czym przechowywać lokalne (w kontekście zmiennych) dane aby dostęp do nich był szybki, jakiego użyć algorytmu itd to już odpowiedzialność programisty.
- skalowalność - to żeby można było postawić np. server RESTowy na kilku maszynach i kierować zapytania do najmniej obciążonego to robota speców od tego, ale programista może napisać 3 metody, każda na 500 linii z czego 3/4 tych metod to copy-paste a może też wspólny kod wydzielić, odchudzić metody albo nawet rozbić na mniejsze itd
- bezpieczeństwo - żeby połączenia do serwera były szyfrowane, żeby nie było dostępu do bazy danych z zewnątrz, żeby DDoS można było szybko wykryć i zablokować itp to nie działka programisty ale żeby hasło w bazie nie było zapisane otwartym tekstem, żeby nie dało się zrobić SQL injection, żeby wrażliwych danych nie zapisywać do logów, ba żeby nie generować exceptionów co chwila to znowu zadanie na poziomie programisty.
Generalnie uważam, że część rozwiązań powinna być narzucona w opisie wymagań/problemu (ticketa), w szczególności te, które są wspólne w wielu miejscach aplikacji (np.
dodać logowanie użytkownika. Hasło ma być szyfrowane SHA512)
pewnie, zgadzam się z Twoim opisem, że faktycznie to tak wygląda obecnie albo powinno uwzględniając przedstawione przez Ciebie ścieżki. Tylko czy to nie będzie szło w stronę aby właśnie role się między sobą konsolidowały? Ja widze to tak, że oczywiście na początku jest biznes ale potem pojawił się programista, który cyfryzyuje w jakiby sposób o tym nie myśleć. ostatnia historia pokazała nam jedną bańkę z 2000 roku gdzie po niej rynek zaczął rosnąć i zaczeły się rodzić różne role, wszystko przyśpieszyło i teraz jesteśmy w momencie gdzie to zwalnia. Pojawia się wiele automatyzacji. Zakładam, że liczba aplikacji jaka jest potrzebna ma swoją górę. Jesteśmy za rewolucją na mobilkach, desktopie, webie. To co ja widzę to obszar AI na horyzoncie. Co za tym idzie czy nie wraca to do punktu wyjścia gdzie znowu będzie potrzeba biznesowa i ktoś z IT? nie wiem czy to programista ale ktoś kto tworzy albo przekłada wymagania na konkretne funkcjonalność w jakimś narzędziu ale z racji, że jesteśmy już na jakimś etapie rozwoju to nikt nie będzie tworzył wszystko od zera bo dev jest drogi generalnie. Dlatego czy nie będzie trendem to, że jedna osoba będzie zwyczajnie musiała mieć więcej w zanadrzu niż tylko to co może dawać funkcjonalności?
2
@iPHeCTRA:
Czy to nie jest tak, że za chwile typowy programista będzie musiał ogarniać więcej rzeczy niż znać technologie typowo zapewniające dostarczenie funkcjonalności dla danego biznesu?
To już się dzieje. Co więcej geneza tego, że programista powinien ogarniać więcej niż umiejętność programowania jak na przykład posiadać wiedzę domenową (biznesową) produktu nad którym pracuje ma już z jakieś 30 lat. Jak pobawisz się w archeologa i poczytasz publikacje branżowe z lat 90 ubiegłego wieku to sam zobaczysz, że to co robimy i o czym rozmawiamy to cytując "to już było".
0
@markone_dev: ale wiedza domenowa a wiedza "architektoniczna" to wie różne rzeczy i wiedzę domenową dobrze jest posiadać, szczególnie jak masz bezpośredni kontakt z klientem. Natomiast uważam, że możesz być dobrym/bardzo dobrym programistą lub dobrym/bardzo dobrym architektem ale nie możesz być dobry w obu, co najwyżej przeciętnym - za dużo "świata" do ogarnięcia. Inna sprawa, że coraz częściej biznesowi wystarczy jeden średni, który obskoczy dwa etaty za 1,5 * x$ niż dwóch dobrych, każdy za x$
0
abrakadaber napisał(a):
@markone_dev: ale wiedza domenowa a wiedza "architektoniczna" to wie różne rzeczy i wiedzę domenową dobrze jest posiadać, szczególnie jak masz bezpośredni kontakt z klientem. Natomiast uważam, że możesz być dobrym/bardzo dobrym programistą lub dobrym/bardzo dobrym architektem ale nie możesz być dobry w obu, co najwyżej przeciętnym - za dużo "świata" do ogarnięcia. Inna sprawa, że coraz częściej biznesowi wystarczy jeden średni, który obskoczy dwa etaty za 1,5 * x$ niż dwóch dobrych, każdy za x$
Architekturę podobnie można rozumieć lokalnie i globalnie. Moim zdaniem programista musi mieć świadomość architektury i dawać coś w tym obszarze od siebie ale może niekoniecznie na poziomie organizacji i architektury wszystkich systemów. Dla mnie architektura to część programowania, nie ma albo to albo tamto
1
@abrakadaber: @iPHeCTRA
Ja bym tu dodał, że nie ma jednej architektury. Weźmy pierwsze trzy z brzegu: architekturę aplikacji, architekturę systemową czasem niektórzy używają słowa integracyjna, architekturę korporacyjną.
Programista powinien bardzo dobrze znać architekturę aplikacji nad którą pracuje.
Architekturę systemową też powinien znać (zwłaszcza jeżeli w firmie jest wiele aplikacji które ze sobą współpracują), ale w takim stopniu aby jego aplikacja mogła się integrować z innymi.
Z kolei architektura korporacyjna/przedsiębiorstwa (Enterprise Architecture - EA) zwał jak zwał to już jest poza zakresem wiedzy i kompetencji szeregowego programisty. Znajomość EA to już zadanie dla architektów systemowych/korporacyjnych, których zadaniem jest projektowanie i tworzenie rozwiązań IT w skali całego przedsiębiorstwa, czyli integrującego wiele domen biznesowych jak sprzedaż, magazyn, kadry, produkcja, itd.
0
Zacząłem o tym rozmawiać w najbliższym gronie od momentu udostępnienia tego postu. Dwie rzeczy mnie zaskoczyły poniekąd. Pierwsza opinia to wprost powiedziane, że kończy się "era koderów", czyli takich programistów co tylko programują (cokolwiek to znaczy). Tylko chwile po tym usłyszałem czy to nie ma miejsce już od 20 lat od kiedy scrum się pojawił i zaczął promować interdyscyplinarność. Ja się zgadzam z tym, era koderów już się pewnie dawno skończyła w części organizacji a w części nie. Czyli tak jak ze wszystkim. Mój post wynika chyba z deficytu wiedzy w innych obszarach niż koderstwo więc postanowiłem pójść na podyplomówke z cyberbezpieczeństwa. Ale wciąż będę nasłuchiwał co na to rynek
1
to co opisujesz to jest "o matko już nie jestem juniorem muszę robić coś więcej" i nie chodzi o to że skoczyła się jakaś era ale skończyła się dla Ciebie
2
To zależy od biznesu w jakim siedzisz. Niektóre domeny są tak zawiłe jak na przykład ta w której obecnie pracuję, że bez ludzi typu "Ekspert domenowy" czy tam "SME" (Subject Matter Expert), którzy robią analizę biznesową i definiują wymagania, czasem dość szczegółowo nie wyobrażam sobie obecnej pracy. Z kolei pracowałem też w takich dziedzinach w którym sami jako zespół byliśmy ogarnąć domenę biznesową i nawet proponować biznesowi usprawnienia do ich procesów.