Zróbmy listę złotych rad jakie byście dali komuś kto chce być dobrym programistą. Mogą być podstawowe i bardziej zaawansowane. Rady ode mnie: - Zanim zadasz pytanie sprawdź czy może na nie odpowiedzieć: google, chatgpt, dokumentacja - Gdy skończysz pracę nad commitem, zadaj sobie pytanie czy możesz dopisać jakieś testy - Dokumentuj błędy na które natrafiasz, ich rozwiązania i generalnie rozwijaj dokumentację - Jeżeli często wykonujesz jakąś instrukcję, żeby na przykład zbudować projekt, staraj się zrozumieć co robi każda komenda. W przyszłości łatwiej będzie ci debuggować problemy z tym związane.
@cordianss tego chatagpt to sobie w tyłek wsadź. Próbowałem, zawsze musisz sprawdzać, prawie zawsze poprawiać, często daje błędne odpowiedzi, algorytm który robi nie to co powinien, itd. do programowania to tylko github copilot.
@cordianss: - staraj sie rozwijac, nie stoj w miejscu z technologiami, czytaj dokumentacje jak nie mozesz wieczorem zasnac ( ͡°͜ʖ͡°) zawsze sie dowiesz czegos ciekawego co potem wykorzystasz - nie boj sie optymalizowac swoich narzedzi pracy. Nowy edytor, theme, komputer? To pomaga sie nie zanudzic - nie spiesz sie, zastanow sie czy czegos nie da sie zrobic czysciej, od razu dobrze zeby potem do tego
@MacDada: to czy piszesz testy przed czy po implementacji nie wpływa na ich jakość. TDD powstało żeby opychać szkolenia i żeby crudziarze i enterprisowcy mieli nowy dogmat. Sam fakt, że uncle bob optuje za TDD jest argumentem, żeby tego nie używać
@cordianss: Ship it. Długo byłem skupiony w karierze na pokryciu testami (firma wymagała 90% co doprowadzało do wielu absurdów), ddd, tdd - nie ma to znaczenia. Płacą nam za dowożenie, i to nie taskow w jirze tylko łącznie z ownershipem i rozumieniem produktu.
to czy piszesz testy przed czy po implementacji nie wpływa na ich jakość.
@afuera: Najwyraźniej zdania są tu podzielone. W podlinkowanym przeze mnie artykule Wujo Bob argumentuje czemu pisanie testów przed implementacją daje większą szansę na wyższą jakość testów.
TDD powstało żeby opychać szkolenia i żeby crudziarze i enterprisowcy mieli nowy dogmat.
@MacDada zapoznać się można i wypada, ale traktować jako słowo od boga każdą z wypowiedzi boba nie przystoi, bezkrytyczne przyjmowanie jego książek, które się mocno zdezaktualizowały przez ten czas nie jest wskazane
zapoznać się można i wypada, ale traktować jako słowo od boga każdą z wypowiedzi boba nie przystoi, bezkrytyczne przyjmowanie jego książek, które się mocno zdezaktualizowały przez ten czas nie jest wskazane
@inxsswm: 100% zgody. Aczkolwiek ciekawe, bo ja osobiście nie spotkałem się z jakimś bezkrytycznym uwielbieniem UB -> za to spotkałem się z automatycznym hejtem (raczej świeże zjawisko, które obserwuję od jakiś 3-4 lat).
@MacDada: Bo po latach aplikowania CleanCode w projektach okazało się, że wcale z tym kodem nie pracuje się dużo łatwiej, a często te dodatkowe abstrakcje i wzorce OOP są stosowane źle i tylko utrudniają zmiany. Czyli dokładnie odwrotnie niż miało być. No i pewnie niejeden z nas spotkał na swojej drodze takiego denerwującego typka, co dawał -1 na review, bo w jakiejś książce (zapewne
Rady ode mnie:
- Zanim zadasz pytanie sprawdź czy może na nie odpowiedzieć: google, chatgpt, dokumentacja
- Gdy skończysz pracę nad commitem, zadaj sobie pytanie czy możesz dopisać jakieś testy
- Dokumentuj błędy na które natrafiasz, ich rozwiązania i generalnie rozwijaj dokumentację
- Jeżeli często wykonujesz jakąś instrukcję, żeby na przykład zbudować projekt, staraj się zrozumieć co robi każda komenda. W przyszłości łatwiej będzie ci debuggować problemy z tym związane.
#programowanie #programista15k
@cordianss: testy pisze się przed napisaniem implementacji ヽ(☼ᨓ☼)ノ
@Volantie: ?
- staraj sie rozwijac, nie stoj w miejscu z technologiami, czytaj dokumentacje jak nie mozesz wieczorem zasnac ( ͡° ͜ʖ ͡°) zawsze sie dowiesz czegos ciekawego co potem wykorzystasz
- nie boj sie optymalizowac swoich narzedzi pracy. Nowy edytor, theme, komputer? To pomaga sie nie zanudzic
- nie spiesz sie, zastanow sie czy czegos nie da sie zrobic czysciej, od razu dobrze zeby potem do tego
@MacDada: i najważniejsza rada: nie przyjmuj bezkrytycznie wszystko co piszą eksperci. w IT nie ma zasad, które należy stosować wszędzie i zawsze.
- naucz się miękkich skilli jak np negocjacje
@afuera: Najwyraźniej zdania są tu podzielone. W podlinkowanym przeze mnie artykule Wujo Bob argumentuje czemu pisanie testów przed implementacją daje większą szansę na wyższą jakość testów.
@afuera: #teoriespiskowe
@afuera:
@inxsswm: 100% zgody. Aczkolwiek ciekawe, bo ja osobiście nie spotkałem się z jakimś bezkrytycznym uwielbieniem UB -> za to spotkałem się z automatycznym hejtem (raczej świeże zjawisko, które obserwuję od jakiś 3-4 lat).
@MacDada: Bo po latach aplikowania CleanCode w projektach okazało się, że wcale z tym kodem nie pracuje się dużo łatwiej, a często te dodatkowe abstrakcje i wzorce OOP są stosowane źle i tylko utrudniają zmiany. Czyli dokładnie odwrotnie niż miało być.
No i pewnie niejeden z nas spotkał na swojej drodze takiego denerwującego typka, co dawał -1 na review, bo w jakiejś książce (zapewne