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

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.

4

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

3

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, botów: 0