Dla początkujących - co wolno, a czego nie wolno robić w programowaniu

Odpowiedz Nowy wątek
2019-08-03 01:01
19

Trochę mnie już męczy - tym bardziej, że często siedzę w dziale np. Edukacja czy wątkach bardziej entry level - że ludzie, którzy m.in.

  • uczą się podstaw programowania
  • mają jakieś podstawy i chcą zrobić krok dalej np. zacząć budować aplikacje webowe
  • mają pomysł na aplikację ale nie wiedzą, od której strony się za to zabrać
  • nauczyli się jakichś narzędzi, a teraz nie wiedzą, do czego je wykorzystać

Powtarzają jak mantrę jedno i to samo pytanie, zadawane pod różnymi postaciami, w mniej lub bardziej zawoalowany sposób, jednak zawsze sprowadzające się do tego samego dylematu:

Czy wolno mi wykorzystać framework X do zrobienia Y? Czy mogę napisać aplikację, która robi A w języku B?

Więc chyba najwyższa pora, by raz, wyraźnie i definitywnie odpowiedzieć na to pytanie nurtujące pokolenia:

TL;DR tak, wolno.

Nikt Ci nie może zabronić eksperymentowania i sprawdzania co działa, a co nie. Bycie programistą nie polega na tym, że robisz wszystko w jedyny sposób, dzierżąc dumnie w dłoni młotek i wbijając nim wszystko, co choć z grubsza przypomina gwoździa. Znaczy - tacy też są, ale chyba nie cieszą się zbyt wielkim poważaniem. Są też ludzie, dla których jedynym słusznym podejściem jest ich własne, niezależnie od faktów - które nie zawsze działają na ich korzyść. Czasami mogą być przekonywujący w swoich wywodach, a czasami sprzeciw lub wątpliwości wywołują u nich furię.

Jest jeszcze jedna grupa programistów, która na pytanie czy X nadaje się do Y? prawdopodobnie odpowie to zależy. I to jest zwykle najlepsza odpowiedź, bo istnieją tysiące czynników wpływających na odpowiedź na tego typu pytania. Dopiero z biegiem czasu uczysz się dostrzegać te czynniki i na ich podstawie dokonywać osądu... ale by móc dokonać trafnego osądu, musisz jak najlepiej znać kontekst - a takie ogólne pytania są go zwyczajnie pozbawione.

Szczękanie zębami w strachu, że wykorzystasz język/bibliotekę do celu, do którego nie została przewidziana donikąd Cię nie zaprowadzi. Niczego się w ten sposób nie nauczysz. Natomiast jeśli zamiast się zamartwiać, czy wolno Ci pisać coś w czymś po prostu spróbujesz, możesz się nauczyć kilku rzeczy:

  • że w ogóle nie da się tego zrobić
  • że da się zrobić, ale szkoda zachodu
  • że da się zrobić, ale kiepsko to działa i warto by poszukać innego rozwiązania
  • że da się zrobić i nawet szczególnie to nie boli
  • eureka, bibilioteka A w połączeniu z B doskonale nadaje się do robienia C!

Przy czym pewnie mnóstwo ludzi już to przed Tobą odkryło, jedni metodą prób i błędów, inni czytając książki, jeszcze inni prowadząc teoretyczne rozważania (i po drodze udowodnili pewnie coś ważnego, z czym wypadałoby się zapoznać). Ale Ty nie siedzisz w ich głowach, i jeśli nie zdążyłeś się czegoś dowiedzieć z książek, publikacji, wykładu na studiach albo czyjejś prelekcji na konferencji, to równie dobrze możesz spróbować na własnej skórze.

Czego więc nie wolno robić w programowaniu?

  • rzeczy niezgodnych z prawem
  • rzeczy łamiących licencje i inne takie
  • zakładać, że jest się najlepszym programistą na świecie
  • zakładać, że nie da się czegoś zrobić lepiej
  • nie robić nic ze strachu, że będzie zrobione "nieodpowiednio"

Prosząc o pomoc w wiadomości prywatnej odbierasz sobie szansę na otrzymanie pomocy od kogoś bardziej kompetentnego :)
edytowany 1x, ostatnio: superdurszlak, 2019-08-03 11:22
2019-08-03 13:24
1

Nie wspomniałem, że nie ma problemów jako zagadnień. Junior nie ma problemów z tym, że musi odkryć, wymyślić jak coś zrobić. On ma problem, bo musi to znaleźć. Wybacz, ale postawienie pionowego diva, czy znalezienie tematu na SO nie brzmi jak pionierskie rozwiązywanie problemów, które wymaga własnej implementacji x rzeczy tylko, należy użyć czegoś co już jest gotowe. To nie jest sztuka, pionierstwo i odkrywcze działanie. To zwykłe wyszukanie opisanego rozwiązania plus nieco inzynierii. Problem jest jak ktoś podejdzie do tego własnie twórczo i zacznie upychać wszędzie divy lub tabelki i rzeźbić po swojego, a faktycznie powinien użyć jak sam piszesz flexboxa - więc gdzie tutaj sztuka i pionierstwo? Chyba, że dla Ciebie pionierstwem jest znalezienie informacji w Sieci, która ma np. 1-2 lata i skorzystało z niej już 2 mln programistów. Najpierw wkłada sie bajki o pionierstwie, sztuce, a potem ludzie są rozczarowani rzeczywistością i się "wypalają" . Dla mnie EOT. Przedstawiłem swój pogląd i nie mam zamiaru się kopać i kogokolwiek przekonywać - każdy oceni czy to jest warte rozważenia, czy nie. Miłej dalszej dyskusji,

Pozostało 580 znaków

2019-08-03 13:31
0
czysteskarpety napisał(a):

Odnośnie rozwiązań przy budowaniu apek.
Musi być ruch w biznesie, nie w programowaniu, a w biznesie, bo programowanie to biznes.

Wiele osób się zastawia czemu powstaje tyle rozwiązań i czemu aż tle jest utrzymywanych, bo to jest biznes.
Firma X robi aplikację, po kilku latach firma Y dzwoni i proponuje aplikację na innym frameworku+coś tam gratis, potem po kilku firma Z znowu przekonuje, że zrobi coś szybszego na innym fw w którym się specjalizuje i tak się biznes kręci :)
Gdyby wszystkie rozwiązania były idealne to z czasem nie byłoby pracy, bo nie byłoby co robić, wszystko działa super to po co zmieniać.
Takie decyzje są zwykle na poziomie biznesowym, a nie logiczno-programistycznym.

Nawet ostatnio przerabiałem stronę, goowno straszne, pytam się po co w ogóle to przerabiać skoro taniej zaorać i zrobić nowe, a to się okazało, że firma syna kolegi prezesa ją robiła i mamy stronę utrzymywać przy życiu za wszelką cenę.

Każda zmiana softu z firmy X na Y a potem na Z jest podyktowania czynnikiem biznesowym. Może być to większa kasa z aplikacji, niebezpieczna stara aplikacja i ryzyko wycieku, lub lepsze UI w nowej bo klienci już marudzą na stare etc. Mimo różnych pobudek na końcu stoi decyzja biznesowa i jak to przełoży się na złotówki. Dlatego o ile rozumiem migracje na nowe systemy, tak też rozumiem utrzymywanie starych. Sam znam systemy które pracują już ponad 20 lat. Co do strony syna kolegi prezesa - może prezes czerpie korzyści osobiste z tego dealu, a może kolega prezesa jest przy okazji kontrahentem dającym niezły dochód? Moim zdaniem nie istnieje zmiana tylko dla sztuki, czy tylko, że coś jest bardziej fajne. Za wszystkim stoi biznes i kasa - zarówno za zmianą, jak i za jej brakiem.

Pozostało 580 znaków

2019-08-03 14:20
0
somedev napisał(a):

Nie wspomniałem, że nie ma problemów jako zagadnień. Junior nie ma problemów z tym, że musi odkryć, wymyślić jak coś zrobić. On ma problem, bo musi to znaleźć. Wybacz, ale postawienie pionowego diva, czy znalezienie tematu na SO nie brzmi jak pionierskie rozwiązywanie problemów, które wymaga własnej implementacji x rzeczy tylko, należy użyć czegoś co już jest gotowe. To nie jest sztuka, pionierstwo i odkrywcze działanie. To zwykłe wyszukanie opisanego rozwiązania plus nieco inzynierii. Problem jest jak ktoś podejdzie do tego własnie twórczo i zacznie upychać wszędzie divy lub tabelki i rzeźbić po swojego, a faktycznie powinien użyć jak sam piszesz flexboxa - więc gdzie tutaj sztuka i pionierstwo? Chyba, że dla Ciebie pionierstwem jest znalezienie informacji w Sieci, która ma np. 1-2 lata i skorzystało z niej już 2 mln programistów. Najpierw wkłada sie bajki o pionierstwie, sztuce, a potem ludzie są rozczarowani rzeczywistością i się "wypalają" . Dla mnie EOT. Przedstawiłem swój pogląd i nie mam zamiaru się kopać i kogokolwiek przekonywać - każdy oceni czy to jest warte rozważenia, czy nie. Miłej dalszej dyskusji,

A gdzie ja wspomniałem cokolwiek o pionierstwie? Nigdzie. Przecież to ty pisałeś. Rozwiązywanie problemów nie musi być pionierskie na skalę światową. Odsyłam do definicji słowa problem:
https://sjp.pwn.pl/sjp/problem;2572488.html

  1. «trudna sytuacja, z której należy znaleźć jakieś wyjście»
  2. «poważna sprawa, która wymaga przemyślenia i rozstrzygnięcia

Dla niektórych problemem będzie "jak wysłać ludzi na Marsa" dla innych problemem będzie "w co się rano ubrać".

Tak samo jeden programista będzie rozwiązywać jakieś innowacyjne problemy, inny będzie rozwiązywać problemy, na które ktoś już dawno znalazł odpowiedź.

Jednak w momencie kiedy uznamy, że junior to nie rozwiązuje żadnych problemów, tylko implementuje w 100% to, co ktoś inny już wymyślił to równie dobrze można go wywalić na zbity pysk i napisać skrypt automatyzujący pracę. Jednak tak się nie dzieje (jeszcze?) i ci juniorzy jednak dalej są potrzebni.

Swoją drogą ja jestem akurat zdania, że klepanie HTML/CSS wg dostarczonego z góry designu akurat powinno zostać zautomatyzowane, ale to inna sprawa (póki co jeszcze nie jest). A powinno zostać zautomatyzowane właśnie dlatego, że jest mało twórcze, powtarzalne. Więc niech to robią komputery, a nie ludzie.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 1x, ostatnio: LukeJL, 2019-08-03 14:21
HTML/CSS wg dostarczonego z góry designu akurat powinno zostać zautomatyzowane - moim zdaniem nie zostanie, bo biznes nie lubi stagnacji, dlatego google cały czas coś zmienia i "poprawia" a my grzecznie musimy wyciskać 100% w audycie i robić aktualizacje ;) - czysteskarpety 2019-08-03 15:18
rzecz w tym, że w firmach zwykle inne osoby są odpowiedzialne za ustalanie celów biznesowych, inne osoby za design, a inne osoby za klepanie gotowych designów do HTML/CSS. Mówiąc o automatyzację miałem na myśli właśnie ten ostatni etap w tym waterfallu - czyli masz np. design z XD (czy innego programu, ale XD ma najśmieszniejszą nazwę XD) i kodujesz do HTML/CSS. Myślę, że w przyszłości narzędzia do prototypowania będą umożliwiać eksport do HTML/CSS/wypluwać apkę Reactową (to już się zaczyna dziać, niektóre tego typu aplikacje pozwalają na osadzanie komponentów React). - LukeJL 2019-08-03 15:25
więc na tym etapie praca kodera HTML/CSS będzie mogła zostać skutecznie zlikwidowana (ale HTML/CSS to tylko kawałek frontendu, zaawansowanej logiki pewnie się tak szybko nie zautomatyzuje). - LukeJL 2019-08-03 15:27
@LukeJL: Niby tak, z drugiej robiąc coś większego wolę już poświęcić kilkanaście godzin i zrobić ręcznie (wiem co mam), niż liczyć na to co tam mi "wypluje" i po pól roku poprawiać ;) - czysteskarpety 2019-08-03 15:41
@czysteskarpety kwestia dopracowania technologii i zbudowania zaufania do niej. Przecież teraz developerzy np. kompilują kod Babelem albo TypeScriptem i nawet się nie zastanawiają co im ten transpilator wypluje. Albo np. korzystają z Gita i nie zastanawiają się czy Git dobrze zmerdżował pliki (chyba, że palnie konfliktem). Albo Sass czy inne cuda do CSSa. Też co innego jest na wejściu, a co innego wypluwane na wyjściu. - LukeJL 2019-08-03 15:51
@LukeJL: No wiem, wiem, ale ja jeszcze poczekam aż będzie coś sprawdzonego. - czysteskarpety 2019-08-04 10:41

Pozostało 580 znaków

2019-08-04 23:39
2

TL;DR tak, wolno. Nikt Ci nie może zabronić eksperymentowania i sprawdzania co działa, a co nie

A ja się nie zgodzę. Bo, oczywiście, użycie PHP do zrobienia aplikacji desktopowej, wprawdzie nie jest nielegalne, ale nie jest najlepszym pomysłem ;) Myślę, że większość osób pytających o to, czy może zrobić X przy użyciu Y jest mocno początkująca i potrzebuje rady/pomocy/pokierowania. Odpowiedź "pobaw się i zobacz, co się stanie" nie jest najlepsza. W zasadzie, to ona nic nie wnosi do tematu, bo pytający ma taki sam bałagan (albo i większy), niż miał w chwili zadawania pytania. Oczywiście - pewną część totalnie bezsensownych spraw można by olać, ale część ludzi pytających o takie rzeczy to nie są debile, tylko ludziki, którym coś świta, gdzieś coś słyszeli, ktoś coś poradził i starają się to przetrawić we własnym zakresie. Ale że to jakoś im nie wychodzi, to pytają na forum.


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say

Pozostało 580 znaków

2019-08-05 14:38
2

Ale osoba początkująca powinna najpierw ogarnąć jakieś podstawy programowania w ogóle a nie zastanawiać się, jaka technologia będzie najlepsza do zrobienia danej rzeczy. Na specjalizację przyjdzie czas.
Z kolei osoby bardziej zaawansowane raczej mają już pojęcie, do czego który język będzie sensownym wyborem, albo są w stanie szybko wyszukać tego typu informacje.

Pozostało 580 znaków

2019-08-06 01:16
2
cerrato napisał(a):

Odpowiedź "pobaw się i zobacz, co się stanie" nie jest najlepsza. W zasadzie, to ona nic nie wnosi do tematu, bo pytający ma taki sam bałagan (albo i większy), niż miał w chwili zadawania pytania.

Dlaczego nie? Ja tak zawsze robiłem, nikogo o nakierowanie nie prosiłem, i nie sądzę, abym źle na tym wyszedł.
Inżynieria jest empiryczna z definicji. A jeśli nie będzie się bawić i próbować, to doświadczenia się nie zdobędzie. Bardziej doświadczeni paradoksalnie mogą podzielić się wyłącznie wiedzą, doświadczenie nie jest transferowalne.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
A do tego jak liczyć całki też sam dochodziłeś, czy jednak ktoś to Tobie wyłożył? Jednak opieranie się na wiedzy przodków, już zdobytej i opracowanej pozwala nam iść do przodu. Ponowne odkrywanie wszystkiego na własną rękę, powodowało by, że jako cywilizacja w najlepszym przypadku stalibyśmy w miejscu, a znając, życie następował by niezły regres. - somedev 2019-08-06 08:44
1. Całki to nie jest inżynieria. 2. Nigdzie nie napisałem, żeby nie opierać się na wiedzy przodków. Napisałem, że doświadczenie, to jest coś, co się zdobywa samemu. Ty rozumiem sam nie napisałeś żadnego programu, bazujesz jedynie na wiedzy swoich przodków, którzy pisali? - somekind 2019-08-06 10:42
Całki to przykład. Rozumiem, że serwer jak miałeś napisać stronę http to próbował byś eksperymentów np. pisząc serwer w asm czytając i pisząc do plików będących portami? Generalnie ważne jest eksperymentowanie, ale Juniorom raczej należy dać kierunek - Q "Chcę napisać system CRUDOWY" A "Weź do tego C# lub Jave", Q "Chcę napisać algorytm przetwarzania wideo" A "Weź C++" etc. Pamiętaj, że piszemy o Juniorach, a Ci bez doświadczenia miewają czasami straszne pomysły, jak drapanie się za prawym uchem lewą ręką przez prawe kolano. - somedev 2019-08-06 10:51
Nie, nie rozumiesz. - somekind 2019-08-06 11:00
Na szczęście to tylko Twoja opinia ;) - somedev 2019-08-06 11:12
Nie, to fakt. Nie zrozumiałeś, co napisałem, wyciągasz wnioski z czapy i z nimi dyskutujesz. - somekind 2019-08-06 12:43

Pozostało 580 znaków

2019-08-06 03:47
0

@somekind, ale to brzmi, jakbyś chciał czegoś uczyć pytających. Moim zdaniem pytający nie chcą się uczyć – może są wyjątki – tylko chcą otrzymać odpowiedź na ich pytanie; czasem chcą jeszcze, by sformułowano samo pytanie na podstawie ich wątpliwości. Jeśli ktoś chce uczyć pytających, będzie robić to w części przypadków na siłę.


Pozostało 580 znaków

2019-08-06 05:00
0
Silv napisał(a):

@somekind, ale to brzmi, jakbyś chciał czegoś uczyć pytających. Moim zdaniem pytający nie chcą się uczyć – może są wyjątki – tylko chcą otrzymać odpowiedź na ich pytanie; czasem chcą jeszcze, by sformułowano samo pytanie na podstawie ich wątpliwości. Jeśli ktoś chce uczyć pytających, będzie robić to w części przypadków na siłę.

Nie zgodzę się do końca ani z Tobą ani z @somekind. Choć po części też wg. mnie obaj macie rację. Czym innym jest bawienie się kodem żeby na ten przykład stworzyć jakieś narzędzie na własny użytek albo żeby się przekonać czy się uda coś zrobić, gdzie nie myśli się o konwencjach, clean code, architekturze itp., a czym innym jest klepanie kodu żeby wyszło ładnie i żeby nie było później wstydu pokazać go komuś. W tym pierwszym przypadku jest miejsce na eksperymenty, zabawę, próbowanie różnych rzeczy. W tym drugim już chyba jednak warto się niekiedy spytać czy coś odbiega od szeroko przyjętych standardów czy też nie, jeśli ma się wątpliwości. Poza tym wbija się ludziom do głów DRY i KISS, więc czasami chyba warto spytać się o radę czy da się to zrobić prościej? Sami pewnie przyznacie, że w sieci jest pełno tutoriali które uczą złych nawyków. W książkach (!!) dobrze ocenianych wpaja się ludziom złe nawyki. Ile razy marudzono że MSDN uczy złych nawyków? Tak więc nie dziwcie się że czasami ktoś może być nieco zagubiony i się spyta o poradę albo opinię.

Pozostało 580 znaków

2019-08-06 08:25
1

Inżynieria jest empiryczna z definicji

Częściowo się zgadzam, w zakresie R&D, tworzenia nowych technologii, pracy badawczej itp.. Podczas normalnej pracy jest wręcz przeciwnie - zamiast robić eksperymenty, korzysta się z dziesiątek/setek lat doświadczeń poprzedników. Owszem, dla własnego rozwoju, takie badania we własnym zakresie są bardzo przydatne, ale podczas codziennej pracy już średnio.

Inżynier to nie tylko programista, ale też np. koleś który projektuje pociągi. W tym drugim przypadku też uważasz, że eksperymenty na produkcji są OK? W sensie - nie powiem Ci jak to zrobić, kombinuj, w końcu zrobisz tak, żeby koła nie odpadały na zakrętach?


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say

Pozostało 580 znaków

2019-08-06 13:04
Silv napisał(a):

@somekind, ale to brzmi, jakbyś chciał czegoś uczyć pytających. Moim zdaniem pytający nie chcą się uczyć – może są wyjątki – tylko chcą otrzymać odpowiedź na ich pytanie; czasem chcą jeszcze, by sformułowano samo pytanie na podstawie ich wątpliwości. Jeśli ktoś chce uczyć pytających, będzie robić to w części przypadków na siłę.

Jeśli ktoś nie chce uzyskać wiedzy, to niech nie pyta. Zaoszczędzi czas swój i nasz.
Zakładam jednak, że skoro już ktoś zapytał, to chce uzyskać pomoc - a pomoc to nie zawsze odpowiedź: "tak" lub "nie".

cerrato napisał(a):

Podczas normalnej pracy jest wręcz przeciwnie - zamiast robić eksperymenty, korzysta się z dziesiątek/setek lat doświadczeń poprzedników.

Przecież to się nie wyklucza. :|

Inżynier to nie tylko programista, ale też np. koleś który projektuje pociągi. W tym drugim przypadku też uważasz, że eksperymenty na produkcji są OK? W sensie - nie powiem Ci jak to zrobić, kombinuj, w końcu zrobisz tak, żeby koła nie odpadały na zakrętach?

WTF, jakie eksperymenty na produkcji, bo ja o żadnych nie pisałem?
Uważasz, ze konstruktorzy pociągów nie zdobywają doświadczenia w projektowaniu podczas swojej edukacji i kariery, i nie używają go do projektowania pociągów? Że wszystko robi się na podstawie książek? To czemu wszystkie pociągi na świecie nie mają takich samych konstrukcji i osiągów?


Jak widzę po postach i komentarzach wyżej kilka osób kompletnie nie zrozumiało, o co mi chodziło, więc spróbuję jeszcze raz.

Ja nigdzie nie napisałem, żeby nie czerpać z już dostępnej wiedzy ani nie zapoznać się z zasadami czy wzorcami. To są elementarne aspekty, którą należy przyswoić. Ale zrozumienie, kiedy co się sprawdza, kiedy których należy używać, i jakie są konsekwencje ich nieużycia, wymaga właśnie doświadczenia. A doświadczenie wymaga eksperymentu. Dopóki nie napiszesz kodu źle, nie dowiesz się, że jest zły. Dopóki nie napiszesz dobrze, nie dowiesz się, że jest dobry.
Inżynieria to ne matematyka, decyzje techniczne odnośnie sposobu rozwiązania danego problemu podejmuje się bazując na doświadczeniu.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2019-08-06 13:04

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

2 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 1

Robot: CCBot