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

26

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"
0

My thoughts exactly - jak to się mówi :) Programowanie to sztuka/rzemiosło a nie jakieś ścisłe wytyczne.

To nie jest coś, co jest jakąś tam bryłą wiedzy, którą trzeba się nauczyć, tylko to jest coś, co trzeba samemu opanować "na czuja" - bo programowanie polega głównie na rozwiązywaniu problemów.

A rozwiązywania problemów trzeba się nauczyć samemu. Nie znaczy, że trzeba wszystko klepać samemu, umiejętność wyszukania i nauczenia się biblioteki to też pewna samodzielność. Podobnie jak choćby umiejętność zrobienia proof of concept "czy to się da zrobić", ew. przeszukania zasobów internetu w poszukiwaniu prawdziwych case studies, kiedy ktoś użył np. jakiejś bazy danych do czegoś i czy mu się to opłaciło czy nie (zamiast pytania typu "czy Mongo nadaje się do klona FB?" czy podobnego)

Tak samo umiejętność opanowywania skutecznego stosowania wzorców projektowych i wiedzę o tym, kiedy stosować, a kiedy nie stosować danego wzorca - tego też trzeba się samemu nauczyć tak jak wiedzy o tym. Więc pytania typu "czy mogę użyć wzorca X w taki sposób" są równie bezsensowne jak "czy mogę zakładać slipki czy lepiej bokserki".

3
LukeJL napisał(a):

My thoughts exactly - jak to się mówi :) Programowanie to sztuka/rzemiosło a nie jakieś ścisłe wytyczne.

Nie zgadzam się. W moim rozumieniu programowanie czasem może być sztuką, ale czasem powinno/musi być być inżynierią. Co do rzemiosła – nie wiem. Ciekawe rozróżnienie zostało podane na Wikipedii: https://pl.wikipedia.org/wiki/In%C5%BCynieria#In%C5%BCynieria,_rzemios%C5%82o_i_sztuka

To nie jest coś, co jest jakąś tam bryłą wiedzy, którą trzeba się nauczyć, tylko to jest coś, co trzeba samemu opanować "na czuja" - bo programowanie polega głównie na rozwiązywaniu problemów.

Tak, ale zauważ, @LukeJL, że równie dobrze można tak powiedzieć o programowaniu układu sterującego ruchem promu kosmicznego, co o budowaniu mostu. Jedno i drugie wymaga stosowania się do pewnych zasad niezależnie od tego, czy dana osoba uznaje te zasady za właściwe, czy nie. (Jeśli nie – należy zmienić zweryfikować zasady, a nie przestać się do nich stosować). W dalszej części swojego posta wspominasz między wersami o tym, że należy podać kontekst, mówiąc o wyborach w programowaniu. I moim zdaniem należy właśnie podkreślić kontekst i/lub zasady, zamiast podkreślenia opanowywania "na czuja".

Chyba że mówisz o programowaniu w oddzieleniu od inżynierii (wtedy bym się zgodził z podkreśleniem). Jednak ogólnie – nie zgadzam się też z takim podejściem; to jednak inny temat.

2

spoko, tylko że pytanie "czy wolno" może się odnosić też do sytuacji służbowej gdzie juniorowi tysiąc razy się powie i napisze "nie wolno" a ten przeczyta że programowanie jest sztuką i po cichu będzie odp* głupoty

1
Miang napisał(a):

spoko, tylko że pytanie "czy wolno" może się odnosić też do sytuacji służbowej gdzie juniorowi tysiąc razy się powie i napisze "nie wolno" a ten przeczyta że programowanie jest sztuką i po cichu będzie odp* głupoty

Jeśli junior pyta na forum, czy wolno mu pisać serwis z, powiedzmy, przepisami na domowy twaróg w Spring Boocie albo w czym powinien napisać kółko i krzyżyk to coś chyba poszło mocno nie tak przy rekrutacji :)

3

Jeśli programista robi "sztukę", w kodzie to taki kod potem jest cierniem w dupie systemu. Wiadomo - IT to młoda dziedzina ale już mamy jakieś standardy. Jak pisze się jakieś większe systemy www to według wzorca MVC. Co prawda teraz wprowadza się reaktywność, ale nadal to poligon i nie wiadomo jakie podejście wygra. Jak jakieś API to wiadomo, że WCF, SOAP, lub lekki REST po HTTP.Aplikacje okienkowe - jeśli coś małego to na eventach z kreatora można zrobić, ale, żeby miało to sensowną strukturę to może MVC lub MVVM. Też już są jakieś standardy składania obiektów przez fabryki i wstrzykiwanie zależności - mało kto powinien ręcznie robić obiekty przez new. Są zasady, luźnego powiązania komponentów systemu .... tego są tony już przemaglowanej praktycznie wiedzy z ostatnich 50 lat. Nie jest tego mało, ale wystarczy poczytać. Mówienie, że programowanie to sztuka i jak pionierzy rozwiązujemy problemy, jest co najmniej ignorancją. Owszem znajduje się problemy, które nie mają rozwiązania gdzieś opisanego, ale to jest raczej obecnie rzadkie. LZD(Liczba Z d**y) ale 99% problemów jakie napotyka Junior jest dobrze rozpoznane, ktoś już to robił i jest 1-2 najlepsze sposoby na jego rozwiązanie. Robienie tutaj sztuki nie sprzyja dobremu kodowi, a sprawia często błędne wrażenie dla autora kodu, że jest zajebisty i utwierdza się w pisaniu antywzorców.

1

@somedev: tylko zauważ, to co opisujesz to jest trochę inny etap i inny poziom rozważań. Delikwent, który właśnie wziął szturmem kolejny rozdział tutoriala i czuje, że chce napisać swoją aplikację tylko nie wie, w czym i jaką to trochę inny poziom dyskusji niż ktoś, kto ma dylemat czy lecieć w MCV czy w reaktywność albo czy w takim a siakim przypadku jest sens pchać się w kolejny API endpoint i strzelać do niego z karabinu maszynowego, czy jednak zrobić websockety. Tu już na ogół jest podany jakikolwiek kontekst. Tu na ogół OP ma zagwozdkę, jak coś zrobić lepiej, albo żeby w ogóle miało ręce i nogi bo wychodzi mu kaszanka, pyta o dobre praktyki itp. Szuka porad i opinii, a nie pozwolenia na robienie czegoś albo potwierdzenia że nikt go nie zamknie za używanie tej biblioteki a nie innej.

Co innego z kimś na poziomie przerobiłem 3/4 tutoriala i chciałbym napisać swoją aplikację do X. MVC, SOAP, REST to dla takiego jakieś niezrozumiałe zlepki literek, być może będzie kojarzył MVC bo akurat składał Contoso University z kursu Microsoftu albo klecił coś w NodeJS z tutoriala do NodeJS i tam pisało, że to jest RESTowe. Tutaj pojawiają się problemy egzystencjalne w stylu:

chcę napisać apkę webową czy mogę ją pisać w Pythonie i Django?

A skądże, Django to tylko taki bait na programistów, potem skanujemy GitHuba i zamykamy w więzieniu ludzi piszących apki webowe w Django.

chcę napisać platformówkę, czy mogę ją napisać w Javie?

Nie, pisanie platformówek w Javie jest zabronione przez konwencje genewskie

czy mogę użyć Laravela do napisania apki webowej, która będzie zwracała negatyw wrzuconego obrazka?

Broń Boże, Laravela używa się do pisania stron dla sklepów rowerowych, ewentualnie apek do zwracania wpisanego tekstu tyłem, jeśli chcesz robić negatywy obrazków to zostaje Ci Symfony.

Na tego typu pytania aż cisną się na język (na klawiaturę?) tego typu sarkastyczne odpowiedzi, bo pytania są zwyczajnie z czapy. Na ogół są bez kontekstu - ba, kontekst w ogóle nie istnieje, bo OP dopiero ma jakiś pomysł albo wręcz szuka pomysłu - nie wiadomo, czego OP oczekuje. Na ogół nawet z punktu widzenia choćby użycia jakichś wzorców są bez znaczenia, bo co za różnica czy wykorzystasz MVC w tym czy innym frameworku, co za różnica czy postawi REST API ze Spring Bootem czy z Flaskiem, skoro po prostu chce mieć jakieś REST API (o ile już wie, że chce!) i nawet nie jest w stanie sformułować jakichś dodatkowych wymagań, które mogłyby wpłynąć na ostateczny wybór.

0
Silv napisał(a):
LukeJL napisał(a):

My thoughts exactly - jak to się mówi :) Programowanie to sztuka/rzemiosło a nie jakieś ścisłe wytyczne.

Nie zgadzam się. W moim rozumieniu programowanie czasem może być sztuką, ale czasem powinno/musi być być inżynierią. Co do rzemiosła – nie wiem. Ciekawe rozróżnienie zostało podane na Wikipedii: https://pl.wikipedia.org/wiki/In%C5%BCynieria#In%C5%BCynieria,_rzemios%C5%82o_i_sztuka

wg tej definicji na wikipedii to programowanie jest jednocześnie sztuką, rzemiosłem jak i inżynierią:

w inżynierii pierwszoplanową rolę gra wiedza techniczno-naukowa, podczas gdy w rzemiośle najważniejsze jest doświadczenie a w sztuce kreatywność.

W pracy programisty widzę element kreatywny - musisz wymyśleć jak coś zrobić czyli kreatywność (co nie zawsze jest oczywiste, trzeba czasem przemyśleć różne rozwiązania, pogłówkować), jest element doświadczenia (trzeba popróbować różne rzeczy, i wysuwać wnioski na podstawie swoich błędów i sukcesów z przeszłości), jak i gra rolę wiedza techniczno-naukowa (opis algorytmów w książce czy spis wzorców projektowych to przykłady takiej wiedzy).

somedev napisał(a):

Mówienie, że programowanie to sztuka i jak pionierzy rozwiązujemy problemy, jest co najmniej ignorancją.

Jeśli nie rozwiązujesz problemów jako programista, to twoja praca jest w kolejce do zastąpienia przez AI, bo generatory kodu wg ustalonych schematów już są.

0

Ta... generatory kodu to już miały powstać w latach 80. Twoja praca chyba będzie prędzej zastąpiona przez innego programistę, bo nie wiem jak można rak bardzo nie rozumieć tekstu ;) Wszak odnoszę się do pracy juniora. Nikt zdrowy nie zleci juniorowi odkrywczej pracy. Pisałem kilka systemów real time w których trzeba było wymyślić pare sposobów na przetwarzanie live pewnych danych. Samo opracowanie sposobu było odkrywcze i trwało z polowe czasu przeznaczonego na projekt ale potem w kodzie było to z 20% całości a reszte 80% oczywistego kodu też musiał ktoś napisać i potem zintegrować - tutaj wkraczają juniorzy.

1

Sam zmieniłeś kontekst wypowiedzi. Najpierw:

somedev napisał(a):

Mówienie, że programowanie to sztuka i jak pionierzy rozwiązujemy problemy, jest co najmniej ignorancją.

Czyli rozumiem, że mówisz ogólnie o programistach. A potem dopiero napisałeś, że junior:

ale 99% problemów jakie napotyka Junior jest dobrze rozpoznane, ktoś już to robił i jest 1-2 najlepsze sposoby na jego rozwiązanie.

Co do juniorów to jak dla mnie, to też muszą rozwiązywać problemy. Bo nawet odnalezienie tych 1-2 najlepszych sposobów na jego rozwiązanie wymaga np. znalezienia informacji na ten temat w StackOverflow (co nie każdy umie, szukanie informacji to również problem solving).

Powiedzmy, że taki junior może mieć za zadanie wycentrować diva w pionie w CSS. I jest to realny problem do rozwiązania (z którego się nawet ludzie śmieją, że to jeszcze do niedawna był największy problem w CSS). Więc taki junior musi albo wykombinować samemu, albo zajrzeć na Stack Overflow czy poczytać o flexbox itp. ale tak czy siak musi umieć rozwiązać ten problem, bo od tego zależy czy task przejdzie do kolumny Done. Tak więc gdyby nie było żadnych problemów, to ten junior w ogóle nie byłby potrzebny. A jeśli zatrudniają juniora, to widocznie jakieś problemy są do rozwiązania.

2

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ę.

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,

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.

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.

3

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.

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.

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.

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łę.

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ę.

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?

4
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.

2

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

Owszem, ale można też bazować na doświadczeniu innych. Jeśli uczeń u mechanika nie wie, jakim kluczem odkręcić dany element, to może spróbować 20 różnych. Opcje są 2: albo w końcu się uda i będzie wiedział, że do takiego celu nadaje się dany klucz, albo podczas próby numer 7 rozwali odkręcany element i pojawi się problem. Może też zapytać kogoś bardziej doświadczonego, kto od razu powie, jakim narzędziem podejść do tego tematu.

Niekoniecznie doświadczenie trzeba zdobywać w oparciu o własne działania. Równie dobrze można korzystać z wiedzy i doświadczenia innych. Jest takie powiedzenie "człowiek uczy się na błędach" - owszem, ale jeśli można, to lepiej na błędach popełnionych przez innych jakiś czas temu.

5

Ale ja cały czas nie mówię, żeby nie bazować na doświadczeniu innych. Ja mówię, że doświadczenia nie da się transferować, można je tylko zdobywać.

Można komuś powiedzieć, że w zetknięciu z jakimś problemem rozwiązanie X dało nam lepsze efekty niż rozwiązanie Y, ale jeśli ten ktoś nigdy nie zetknął się z takim problemem, to nie zrozumie ani czemu, ani o co w ogóle chodzi.

Przykład, który podałeś to właśnie przykład zdobywania doświadczenia przez własne działania. Uczeń ma problem, bo próbuje odkręcić element. Robi coś, więc doświadcza, z jego doświadczenia wynika, że dany element jest problematyczny. Gdy starszy kolega mu odpowie, którego narzędzia lepiej użyć, to prawdopodobnie zrozumie dlaczego, a być może też czemu na czym polegał jego błąd i z czego wynikało fiasko poprzednich prób.
Abstrahując już od tego, że odkręcanie elementów nie ma żadnego związku z inżynierią.

3
somekind napisał(a):

Można komuś powiedzieć, że w zetknięciu z jakimś problemem rozwiązanie X dało nam lepsze efekty niż rozwiązanie Y, ale jeśli ten ktoś nigdy nie zetknął się z takim problemem, to nie zrozumie ani czemu, ani o co w ogóle chodzi.

Ponadto szukanie gotowych recept i stosowanie ich bezmyślnie prowadzi bardzo łatwo do cargo kultu.

Uczeń widzi niebieski element i pyta mechanika, jakim kluczem go odkręcić. Mechanik wskazuje mu dany klucz. A potem za każdym razem, kiedy uczeń widzi niebieski element, próbuje ją odkręcić danym kluczem (mimo, że kolor śrubki nie będzie mieć znaczenia, po prostu przypadek sprawił, że za pierwszym razem była niebieska - no ale uczeń nie mając doświadczenia, a jedynie mając wyrwane z kontekstu info, że mechanik powiedział, że do niebieskiego elementu pasuje taki i taki klucz).

Podobną sytuację widuję np. wtedy, kiedy ludzie wyczytają jakiś przykład z tutoriala, gdzie był zastosowany wzorzec projektowy X (albo np. została użyta jakaś specyficzna konstrukcja języka) i potem są wielce przekonani, że używając danej biblioteki muszą korzystać z danego wzorca czy konstrukcji języka, bo nie odróżniają tego co faktycznie istotne i niezbędne, od tego co arbitralne.

Jednak właśnie - tutaj właśnie wiele ludzi popełnia błąd, że ucząc się z tutoriala czy podręcznika nie idą dalej i nie podejmują własnych eksperymentów, ale zakładają, że muszą robić kod cały czas w wyczytanym kiedyś tutorialu (bo gdyby eksperymentowali, to sami by odkryli/doszli do tego, że można użyć innego wzorca/konstrukcji językowej niż w tutorialu).

(przykład: wiele ludzi myśli, że reducery w Redux muszą mieć switch/case w środku, bo tak jest w tutorialach...).

3

Nie czytam tych elaboratów wyżej tylko odpowiadam na pytanie:
Nie wolno zwracać null

4

Odnośnie tego co wolno - wolno zmieniać zdanie. Na różne tematy, również te technologiczne. Wspominam, bo to dość niecodzienna cecha, szczególnie u tych bardziej doświadczonych.

2

.Ze swojej strony mogę doradzić:

  • Dokładne sprawdzanie swojego kodu przed commitem na remote branch.
  • Obtestowywanie napisanego przez siebie nowego kodu.
  • To, że coś działa, to nie jeszcze nie znaczy, że nadaje się do implementacji tego w takiej formie do projektu

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