Naucz się być dobrym programistą: jakie części możesz pominąć? [Zamknięte]

Do tego czasu postawiłem sobie za cel stać się przyzwoitym programistą w przyszłym roku. Rozumiem przez to pełne doświadczenie cyklu rozwojowego, kilka dobrych aplikacji / witryn / aplikacji internetowych pod moim pasem, a co najważniejsze, że mogę pracować w stałym tempie, nie tracąc godzin z boku przez niektórych, którzy powinni wiedzieć to już technika.

Nie zaczynam od zera. Napisałem dużo html / css, SQL, javascript, python i VB.net i studiowałem inne języki, takie jak C i Java. Wiem o takich rzeczach, jak OOP, wzorce projektowe, TDD, złożoność, lingwistyka obliczeniowa, wskaźniki / referencje, programowanie funkcjonalne i inne sprawy akademickie / teoretyczne. Po prostu nie mogę powiedzieć, że naprawdę zrobiłem te rzeczy.

Chcę więc nabrać rozpędu i chcę wiedzieć, jakie rzeczy mogę zostawić na później. Na przykład studiowanie algorytmów i matematyki za nimi jest interesujące i tak dalej, ale jak dotąd prawie nie musiałem pisać niczego oprócz najbardziej podstawowych zagnieżdżonych pętli. Badanie Zgromadzenia, aby uzyskać wyraźniejszy obraz operacji na niskim poziomie, byłoby fajne ... ale wyobrażam sobie, że rzadko narusza codzienną pracę. Z drugiej strony spojrzenie na funkcjonalny język programowania może pomóc mi pisać programy, które są bardziej zrozumiałe i mniej podatne na ukryte awarie (w tej chwili znajduję największą trudność, gdy złożoność aplikacji przekracza moją zdolność do zrozumienia - na przykład przekazywanie danych było w porządku ... dopóki nie zacząłem robić tego z AJAX, co było bolesnym krokiem naprzód).

Jestem programistą o podstawowych umiejętnościach - na jakich umiejętnościach powinienem się skupić na rozwoju?

(również moje umiejętności uniksowe są bardzo słabe, a także znajomość konfiguracji systemu Windows ... nie jestem pewien, ile czasu powinienem na to poświęcić)

Są to sugestie oparte nie na tym, co zrobiłem, ale na tym, co myślę, że powinienem był zrobić z perspektywy czasu:

1. Pomiń nowe technologie, ponieważ większość z nich zawiedzie. Rób wyjątki dla tych, którzy mają udziały lub biznesplan, ale zawsze mają strategię rezygnacji (technologii zastępczej).
2. Pomiń zostawanie ekspertem w każdym języku programowania i bibliotece. Staraj się zostać ekspertem w dziedzinie stosunkowo niewielu (siedmiu) języków programowania i bibliotek, które płacą za to, co lubisz robić. To powiedziawszy, nigdy nie przegap okazji, aby spróbować zrozumieć niuanse innego języka programowania. Zdobycie kompetencji w nowym języku i standardowych bibliotekach zajmuje około dwóch miesięcy.
3. Pomijaj technologie jednoplatformowe, gdy istnieje obejście tego problemu.
4. Pomiń MS Windows. Ma zbyt wiele wad.
5. Pomiń zostawanie specjalistą, ale wybiórczo pozwól innym myśleć, że właśnie tym jesteś.
6. Jeśli to możliwe, pomiń korporacyjne voodoo („oparta na użytkownikach, architektura komponentów korporacyjnych”). Nigdzie nie prowadzi.
7. Pomiń C ++ (pozwól innym sobie z tym poradzić) i poczekaj na powiązania Pythona.

W rzeczywistości możesz pominąć wszystko, jeśli ufasz swojej zdolności do nauki. Myślę, że lepiej byłoby odpowiedzieć na to, co chciałbyś wiedzieć:

• Wiem o tym i brakuje mi tego . Czego powinienem się nauczyć za rok?
• Lubię mieć projekty, które płacą dobrze, ale co naprawdę lubię jest takie . Czego powinienem nauczyć się w ciągu roku?

Pamiętaj, że dobrzy programiści wiedzą o wszystkim, ponieważ w informatyce rzadko chodzi o samo obliczenie, ale częściej o zastosowanie go do dowolnej dziedziny ludzkiej działalności, czy to fizyki teoretycznej, zachowania ekosystemu czy efektów fotograficznych w Matrycy .

Na koniec zapoznaj się z projektem, abstrakcją, algorytmami i złożonością. Ja, programiści, którzy mnie nauczyli, i programiści, których szanuję, podziękuję wam i docenię za to. Jeśli masz czas na naukę, polecam przeczytanie pierwszego wydania Code Complete .

Wybierz aplikację dla zwierząt. Powinno to być coś, co można rozpocząć w bardzo prosty sposób, ale ma ono złożoność, gdy kopie się głębiej. Powinno to również Cię zainteresować, ponieważ spędzasz z tym dużo czasu. Upewnij się także, że CZY TO ROBI. Nie próbuj teraz pisać frameworku lub usługi sieciowej. Zwykła aplikacja obsługiwana przez użytkownika.

Pobierz git, mercurial lub bazar i dowiedz się, jak utworzyć z nimi repozytorium (to jest bardzo proste).

Teraz zaimplementuj swój projekt zwierzaka przy użyciu dowolnej technologii, najlepiej jak potrafisz. Daj sobie termin, aby mieć pewność, że zostanie on wykonany. Użyj repozytorium kontroli źródła, które utworzyłeś, aby śledzić zmiany. Nie martw się o oddziały i tym podobne, po prostu upewnij się, że możesz wycofać się z błędów.

Po zakończeniu pisania aplikacji oznacz ją etykietą. To jest twoja V1. Spraw, by Michael Feathers efektywnie pracował ze starszym kodem , zwinnymi zasadami tworzenia oprogramowania Boba Martina , wzorcami, praktykami i czystym kodem , a także pragmatycznym programistą Andrew Hunta i Davida Thomasa . Możesz je czytać w dowolnej kolejności, a nawet przeskakiwać między nimi. Wiele pomysłów zostało powtórzonych, ale również wzmocnią twoje zrozumienie, ponieważ są prezentowane z różnych perspektyw. (Prawdopodobnie będziesz chciał sięgnąć po książkę wzorców projektowych GoF w celach informacyjnych)

Czytając książki, spróbuj zastosować zdobyte umiejętności, aby ulepszyć swój projekt. Upewnij się, że używasz kontroli źródła jako dziennika zmian, które wprowadzasz.

Jeśli zrobisz to poprawnie, powinieneś nauczyć się wielu dobrych umiejętności, takich jak: refaktoryzacja, projektowanie oparte na testach, ulepszanie istniejącego kodu oraz jak (i ​​kiedy) stosować wzorce projektowe (między innymi umiejętnościami).

Idealnie byłoby, gdybyś miał mentora, który pomógłby ci ocenić twoje postępy. W razie zainteresowania możesz skontaktować się ze mną (firstinitiallastname w kharasoft dot net), a ja pomogę ci w opracowaniu planu i przedstawię recenzję.

Gratulujemy podjęcia inicjatywy na rzecz dalszej kariery! Z tego wyniknie wiele nagród.

Znasz sekret dobrego dewelopera?

Nie wiesz wszystkiego, ale wiesz, czego nie wiesz i gdzie możesz znaleźć więcej informacji na temat tego, czego nie wiesz, kiedy tego potrzebujesz.

• Znajomość wszystkiego, o czym szczegółowo mówiłeś, nie jest możliwa - zbyt wiele, aby mózg mógł sobie z tym poradzić.
• Zapamiętywanie wszystkiego nie jest możliwe - niewykorzystana wiedza jest usuwana z pamięci
• W większości praktycznych sytuacji i tak nie potrzebujesz tak dużo

Próba osiągnięcia niemożliwego doprowadzi jedynie do niepokoju, bezsenności i utraty pewności siebie.

Myślę, że odpowiedź będzie inna dla każdego programisty, w zależności od tego, w czym on lub ona chce się specjalizować. Polecam następujący algorytm, aby ustalić dla siebie dobrą odpowiedź:

1. Wybierz prosty projekt wykorzystujący umiejętność, którą chcesz się nauczyć.

2. Zaimplementuj go, koncentrując się na tej umiejętności.

3. Zwróć uwagę na to, co lubisz w tym, jak ten projekt się zakończył, a czego nie lubisz.

4. Jeśli chodzi o rzeczy, które lubisz w tym, jak przebiegał projekt, zadaj sobie pytanie: „Czy myślę, że mógłbym się w tym specjalizować, co sprawiłoby mi przyjemność, czy też jest związany z czymś, w czym mógłbym się specjalizować i co by się podobało?”
   za. Jeśli tak, pomyśl o innych umiejętnościach związanych z tą specjalizacją i zapisz je.
   b. Jeśli nie, poklep się po plecach, zanotuj to jako coś, w czym jesteś dobry, i idź dalej.

5. Jeśli chodzi o rzeczy, które nie podobały Ci się w projekcie, zadaj sobie pytanie: „Czy jest to coś, co powinienem wiedzieć (lub chcę wiedzieć, jak to zrobić), czy jest to aspekt rozwoju, który mógłbym i chciałbym pozostawić ogólnie innym? ”
   za. Jeśli uważasz, że chcesz lub powinieneś wiedzieć, jak to zrobić, dodaj go do listy rozpoczętej w kroku 4a. b. Jeśli myślisz, że możesz pozostawić ten aspekt innym, westchnij w melancholijny sposób ponad swoje granice jako istoty ludzkiej, zauważ go jako słabość i idź dalej.

6. Wybierz jedną umiejętność z listy rzeczy, w których mógłbyś się specjalizować oraz rzeczy, które powinieneś wiedzieć z 4a i 5a. Wybierz coś, co uważasz za najważniejsze, aby się rozwijać, aby zbliżyć swoje programowanie do tego, co chcesz.

7. Przeprowadź burzę mózgów w prostych projektach, które możesz wykorzystać przy użyciu tej umiejętności. Wybierz jeden, być może projekt, który pozwoli ci ćwiczyć inną umiejętność, która również znajduje się wysoko na liście, dzięki czemu możesz zabić 2 ptaki jednym kamieniem (chociaż n / 2 ma taką samą złożoność jak n, w ten sposób będzie jeszcze szybciej).

8. Wróć do kroku 2, korzystając z tego projektu.

Powtarzaj tę pętlę przez resztę życia lub do momentu, gdy przestaniesz być dobrym programistą (hej, jeśli chcesz rzucić kodowanie, aby nakarmić głodne sieroty, nie zatrzymam cię!).

Specjalizuję się w testowaniu i aplikacjach sieciowych n-tier. Mój następny projekt będzie ćwiczyć TDD i być może ASP .NET MVC 2. TDD ma na celu zwiększenie siły w testowaniu (jestem SDET, więc TDD dałby mi wgląd w testy jednostkowe, czego generalnie nie robię, z wyjątkiem na moich narzędziach testowych), a także pomoc w słabości dobrego projektu (mam nadzieję), a MVC ma pomóc w mojej słabości w projektowaniu front-end. Moja lista obejmuje takie rzeczy, jak testowanie wydajności, bezpieczeństwo sieciowe i współpraca z projektantem stron internetowych w celu stworzenia dobrej (i dobrze wyglądającej) witryny.

Jeszcze jedna rada, którą otrzymałem wcześnie i która okazała się bardzo przydatna: Specjalizacje mogą być szerokie lub głębokie. Innymi słowy, zagłębianie się we wszystko po trosze jest rodzajem specjalizacji. Pamiętaj o tym, próbując ustalić, na czym polega specjalizacja.

Przepraszam, jeśli chcesz coś wyciętego i wysuszonego. Nie sądzę, że pytanie ma taką odpowiedź.

Od lat programuję od włączenia (odkąd skończyłem 7 lat - mam teraz 30 lat).

Gdybym był na twoim stanowisku, zdecydowanie zasugerowałbym - ale czego nie widzę w większości innych odpowiedzi, jest znalezienie co najmniej jednego innego programisty, który mógłby RAZEM pracować przy określonym projekcie.

Gdy to zrobisz, przeczytaj o programowaniu Agile - SCRUM itp. I pracuj zwinnie i testowo. Pracujcie razem - ale nie pozwólcie, aby jeden z was napisał większość kodu - naprawdę pracujcie nad nim jako para programistów.

A podczas pisania własnej wersji wszystkiego wszystko może być pouczające - najlepsi programiści, których znam, są mistrzami w unikaniu pisania kodu Z WYJĄTKIEM za rzeczy, które absolutnie muszą zrobić sami - tj. Rdzeń tego, co jest unikalne w ich projekcie.

Przez resztę czasu będą ponownie intensywnie wykorzystywać kod - wywoływać interfejsy API, korzystać z projektów typu open source (w stosownych przypadkach), a w skrócie unikać ponownego wymyślania koła (lub warstw dostępu do danych itp.) Tylko po to, aby to zrobić.

A potem, w trakcie robienia tego - zwłaszcza z projektami open source, również wrócą do tych projektów - będą czytać kod, czyścić go, naprawiać błędy, dodawać rozszerzenia itp.

Rozwój w prawdziwym świecie zwykle polega na pracy w zespole - dlatego gorąco zachęcam do zrobienia tego. Jeśli nie znasz innych programistów, którzy chcą z tobą pracować nad konkretnym projektem, sugeruję przejrzenie ponad tysiąca projektów open source i wybranie jednego lub więcej z nich, aby aktywnie zaangażować się - prawdopodobnie możesz znaleźć jeden lub więcej projektów, które podrap osobisty „swędzenie” - i bardzo prawdopodobne jest, że znajdziesz projekt, do którego możesz się przyczynić i znajdziesz innych programistów do pracy.

I osobiście odrzuciłbym radę, że twoje podejście do „pomijania tego, co mogę” jest złe - kiedy zatrudniam programistów, chcę programistów, którzy nie próbują robić wszystkiego sami. Zdecydowanie wolałbym programistów, których pierwszym instynktem nie jest napisanie go sam, ale programistów, których pierwszym instynktem jest sprawdzenie, w jaki sposób mogą spełnić potrzeby i wymagania biznesowe bez pisania kodu (a następnie poprzez pisanie minimalnego potrzebnego kodu).

Przez cały czas testujemy i mocno pamiętamy o wymaganiach biznesowych - i tak, czasami testowanie pokaże, że w rzeczywistości trzeba przepisać jakiś kod lub napisać go samodzielnie (czasem możesz go później wesprzeć, aby ulepszyć projekt).

To po prostu kwestia czytania i uczenia się rzeczy, kiedy ich potrzebujesz.

Jeśli gdzieś utkniesz lub masz wrażenie, że „w moim rozwiązaniu czegoś brakuje” - wtedy powinieneś poświęcić trochę czasu, aby dowiedzieć się więcej na ten temat!

Próba znalezienia bitów do pominięcia nie jest najlepszym podejściem.

To powiedziawszy, możesz skoncentrować się na pewnych obszarach, gdy tylko zorientujesz się, które części bycia deweloperem wolisz.

Być może trzymaj się programowania WWW, na przykład ze szkodą dla deweloperów Windows.

Lubię być waletem wszystkich transakcji, ponieważ czyni mnie to bardziej użytecznym.

W ciągu jednego roku prawdopodobnie nie uda ci się ukończyć „kilku dobrych aplikacji / witryn / aplikacji internetowych”, szczególnie na stromej ścieżce uczenia się. Jedyne, czego się nauczysz, to wypalenie zawodowe.

Zamiast tego skoncentruj się na jednym, który Cię interesuje, i użyj go jako narzędzia do nauki. Nie martw się, że jest to jakość produkcyjna (nie będzie), ale użyj go jako piaskownicy, do której możesz wracać.

Na przykład interesuje mnie baseball fantasy. Z biegiem lat opracowałem wiele rzeczy z tym związanych, od robota zbierającego statystyki, robota zbierającego statystyki, do strony internetowej zawierającej tylko HTML, do pełnej aplikacji internetowej ze skalowalną bazą danych SQL Server, która ją zasila, do ... Moim następnym projektem dla zwierząt domowych może być aplikacja Silverlight w czasie rzeczywistym, która pozwala chłopakom usiąść przy wirtualnym stole, aby wykonać szkic.

Żadne z tych rzeczy nie są tak przydatne poza moim światem. Jednak każdy z nich pomógł mi zostać lepszym programistą i nauczyć się technologii poza moją strefą komfortu.

Pomiń trochę, zastanawiając się, w którym języku zacząć programować.
Po prostu wybierz jeden i idź.
Poświęć czas na zapoznanie się z funkcjami API.

Dlatego:

Który jest lepszy, XUL, SWT Eclipse lub wxWindows? Nie wiem Wszystkie są tak ogromnymi światami, że tak naprawdę nie mogłem ich ocenić i powiedzieć. Nie wystarczy przeczytać samouczki. Musisz pocić się i krwawić z tego przez rok lub dwa, zanim naprawdę będziesz wiedział, że jest wystarczająco dobry lub uświadomisz sobie, że bez względu na to, jak bardzo się starasz, nie możesz sprawić, by Twój interfejs użytkownika smakował jak prawdziwe jedzenie.

Joel Spolsky, „Lord Palmerston o programowaniu” http://www.joelonsoftware.com/articles/LordPalmerston.html

Nie martwiłbym się zbytnio syndromem „powinienem wiedzieć to już”. W tej branży zawsze uczysz się czegoś nowego. Raz lub dwa razy w roku mój szef wysyła mi link do 200-300 stronicowego dokumentu dotyczącego protokołu komunikacyjnego lub układu scalonego, czy czegoś takiego, i wyznacza mnie, bym został ekspertem-rezydentem w zakresie jego zawartości. Nikt nie oczekuje, że dojdziesz do momentu, w którym „skończysz” naukę.

Jeśli chodzi o proces rozwoju, po prostu weź to, jak się da. Naprawdę nie będziesz wiedział, co jest najbardziej przydatne, dopóki nie zrobisz tego źle raz lub dwa razy. Oceń swoją wydajność i dokonaj ulepszeń następnym razem.

Na przykład w ubiegłym roku miałem wiele problemów z niestabilnością kompilacji. Bałam się aktualizować z kontroli źródła, ponieważ wydawało mi się, że za każdym razem robię to, spędzając pół dnia na ponownej kompilacji. Gdybym jednak zbyt długo czekał między aktualizacjami, scalanie na końcu byłoby przerażające. Od czasu do czasu mam też pilne błędy, w których nie mogę odłożyć aktualizacji, co utrudniało śledzenie częściowych zmian, które już wprowadziłem dla nowych funkcji.

Cóż, moja firma pracuje nad poprawieniem tego na ogólną skalę, ale w międzyczasie potrzebowałem czegoś, co mógłbym dla siebie wykorzystać. Przeprowadziłem badania dotyczące stabilności kompilacji, odkryłem rozproszoną kontrolę wersji, eksperymentowałem z niektórymi modelami rozgałęziającymi, a teraz mam bardzo sprawny system hybrydowy, który wykorzystuje lokalnie kilka oddziałów bazaru i scentralizowaną kontrolę źródła w mojej firmie, kiedy muszę się dzielić.

Chodzi mi o to, że dwa lata temu zapytałeś mnie, czego powinienem się dowiedzieć o narzędziach i procesach programowych, nie mógłbym ci powiedzieć. Jeśli nie masz podobnego środowiska pracy do mojego, hybrydowa kontrola źródła jest po prostu dodatkową złożonością bez marginalnych korzyści, ale ogromnie pomogła mojej osobistej produktywności i zdrowiu psychicznemu.

Następnie pracuję nad moimi umiejętnościami oceny, ale nie mam pojęcia, co będzie potem, i na pewno nie wiem, co jakiś nieznajomy w Internecie będzie najbardziej przydatny za rok. Tylko Ty możesz na to odpowiedzieć.

Chciałbym tutaj podzielić się dwoma punktami:

1. Myślenie w kategoriach algorytmu zawsze pomogłoby. Kiedy zaczynałem, zawsze myślałem o rzeczywistych scenariuszach i obecnych algorytmach i zawsze starałem się je optymalizować.
2. Nigdy nie rezygnuj z nauki i rozumienia nowych rzeczy / technologii, w komputerach nie ma nic takiego GURU, zawsze musisz się uczyć i musisz zaakceptować ten fakt z góry i uczyć się dalej.

Nie ma znaczenia, co robisz, dopóki trzymasz się tego i uczysz się robić to dobrze .

Wszystkie pomysły, które opublikowałeś, to dobra rzecz, którą powinieneś wiedzieć i która ci pomoże. Który najbardziej Cię interesuje? Wspomniałeś, że twoje umiejętności uniksowe są słabe. Czy rozważałeś wprowadzenie Linuksa na swoim komputerze? Znajomość języka C już pomogłaby, ponieważ możesz zmoczyć stopy w programowaniu systemów uniksowych bez dodatkowego stresu związanego z nauką nowego języka. Może to być również okazja do zapoznania się ze sterownikami urządzeń, jeśli Cię to interesuje.

Bardzo polecam nauczenie się zasad asemblera i zasad funkcjonalnych na pewnym etapie edukacji deweloperskiej. Oba okazały się bardzo przydatne w mojej „normalnej” roli programisty Java. Nauczyłem się Lisp i Prolog. Osobiście wolę Lisp, ale to kwestia opinii. Asembler uczy, jak myśleć o tym, jak komputer widzi twój program, i myślę, że jest to ważne dla każdego programisty. programowanie funkcjonalne uczy, jak myśleć bardziej deterministycznie, co w moim przypadku pomogło mi napisać kod, który można przetestować i jest bezpieczny dla wątków.

Wybierz coś, co ci się podoba i spędź z tym kilka miesięcy. Będziesz dla niego lepszy i może okazać się to krokiem naprzód do następnego projektu w twojej samokształceniu. O tak, i cokolwiek robisz, nie przestawaj się uczyć. W drugim momencie zaczynasz stagnować.

Przestań próbować nauczyć się być porządnym programistą za rok. Naucz się być dobrym programistą za 10 lat.

Z powiązanego artykułu:

Kluczem do sukcesu jest celowa praktyka: nie tylko powtarzanie tego od nowa, ale także stawianie czoła wyzwaniu, które wykracza poza twoje obecne możliwości, próbowanie go, analizowanie wydajności podczas i po wykonaniu oraz poprawianie błędów. Następnie powtórz. I powtórz jeszcze raz. Wydaje się, że nie ma prawdziwych skrótów: nawet Mozart, który był cudownym muzykiem w wieku 4 lat, potrzebował jeszcze 13 lat, zanim zaczął produkować muzykę na światowym poziomie.

Za rok nadal będziesz hazardem. Nic nie możesz na to poradzić. Dobre firmy postrzegają juniorów jako inwestycję. To, czego szukają, nie jest dobrą obecną umiejętnością, ale potencjalną umiejętnością, dobrym zrozumieniem podstaw i entuzjazmem. Musisz zdobyć te cechy podczas rozmowy kwalifikacyjnej, aby uzyskać pracę na poziomie podstawowym.

Ile programujesz w swoim czasie? Będzie to prawdopodobnie kluczowy czynnik przekonujący potencjalnego pracodawcę, że zamierzasz szybko poprawić. Jakie projekty ukończyłeś ? Zrealizowane projekty wykazują poświęcenie.

Byłem zatrudniony tylko w 2 różnych firmach, ale każda z nich miała własną technologię wewnętrzną, której musiałem się nauczyć, zanim będę mógł być produktywny. Ta początkowa nierówność nie zmniejszy się znacznie z tym, ile masz doświadczenia. Dobrzy pracodawcy oczekują początkowego okresu nauki.

Przestań się martwić i przejdź do programu. :RE

Chciałbym tylko przekazać wam moje kroki inspirujących lektur i jak dotąd najbardziej zwrotne momenty.

W mojej karierze programowej było kilka chwil „WOW”. Poszli w następujący sposób:

Head First Design Patterns - To naprawdę otworzyło dla mnie świat OOP / OOD, absolutną podstawę.

Robert C. Martin - Clean Code - Nie spałem od wielu dni z podniecenia! Choć jest to tak proste, chłopiec, że zapomniałem, co to znaczy mieć czysty kod, co przywróciło mnie do normy.

Robert C. Martin - Zwinne wzorce i praktyki - Teraz żyję karierą programistyczną w oparciu o te zasady. Słowo SOLID przychodzi mi na myśl do każdego kodu, który piszę. To w połączeniu z Clean Code tak bardzo mnie dotknęły, że przekonałem wówczas mojego pracodawcę, aby pozwolił mi uczyć go całej firmie około 15 programistów. Nie byłem nawet starszy, dobry w prezentacjach, ale mój entuzjazm sprawił, że tak się stało.

Moją ostatnią chwilą „WOW” było odkrycie TDD. Swoje realizacje podzieliłem się z 2 innymi bliskimi przyjaciółmi, którzy również mieli ten sam efekt „WOW”. Wszyscy byliśmy zafascynowani i teraz ćwiczymy to tak często, jak to możliwe i zawsze omawiamy znaczenie testowania w cyklu życia oprogramowania - lepiej mieć kod weryfikujący siebie niż zespół znacznie wolniejszych ludzi, którzy przeprowadzą testy dla ciebie;).

Ostatni punkt ode mnie, który wydaje mi się bardzo bliski mojemu sercu, jest taki, że jeśli kiedykolwiek chcesz prawdziwie fundamentalnego zrozumienia technologii, takiej jak parser skryptów, biblioteka REST, środowisko testowe itp., To napisz jedną! Dla żartu! Nie tylko sprawi ci to przyjemność, ale odkryłem, że próba napisania rzeczy, których jeszcze w pełni nie rozumiem, daje mi większy szacunek i znacznie głębsze zrozumienie, i zmusza mnie do dokładnego zrozumienia.

Przepraszam, właśnie zdałem sobie sprawę, jak bardzo mogłem odejść od pytania. To, o czym wspomniałem powyżej, było moim absolutnym rdzeniem. Żaden z powyższych materiałów mnie nie opuścił i nie dał mi tak wielkiego abstrakcyjnego myślenia, że ​​nauka stała się szersza i łatwiejsza. Tak więc, odpowiadając na twoje pytanie, staraj się nie pomijać podstawowych zasad pisania kodu i projektowania oprogramowania. Inne konkretne narzędzia do rozwiązywania określonych problemów nie są tak ważne.

Uczenie się i gromadzenie wiedzy jest jak budowanie budynku, każda cegła stoi na innym, polega na swoich fundamentach.

Jeśli zaczniesz omijać rzeczy, pędzić przez nie, skończysz z rozklekotanymi faktami, wspieranymi na antenie. Nie ważcie się ich używać w obawie, że upadną i tak zrobią. Fakty mogą być fałszywe, jeśli nie są powiązane z rozumem, ponieważ musisz znać ich granice.

Szczególnie niepokoi mnie to, że chcesz pominąć podstawy, matematykę, algorytmy i ich krewnych. Bez mocnego zrozumienia tutaj nigdy nie będziesz w stanie zrobić „niczego oprócz najbardziej podstawowych zagnieżdżonych pętli” .

Nie spiesz się, praca trwa wiecznie, nie ma czasu na nieprzerwane uczenie się. Naucz się wszystkiego, co możesz, w takiej kolejności, w jakiej potrzebujesz, nigdy nie pozostawiaj luki bez połączenia.

Jak sugeruje Jeff O, jeśli chcesz być dobrym programistą, nigdy nie przestaniesz się uczyć.

Musisz zdać sobie sprawę, że jest tak wiele rzeczy, których możesz się nauczyć, związanych z programowaniem, że jeśli chcesz to wszystko wiedzieć i być w tym dobry, będziesz tam przez miliony lat. Skup się więc na tym, co uczyni twoje życie dobrym. Niezależnie od tego, czy jest to czysta przyjemność, pieniądze, wysiłek naukowy czy jakakolwiek mieszanka powodów, wybór należy do ciebie i na co należy zainwestować swój czas i sen.

Zadaj sobie pytanie, czym jest przyzwoity programista i zrób to: ćwicz swoją sztukę w rzeczywistych projektach, które doprowadzą Cię do zapomnienia o aktualnej godzinie.

Dla mnie bycie porządnym programistą obejmuje zrozumienie, jak uzyskać i napisać dobre wymagania, jak zarządzać projektem, jak testować, jak prezentować wyniki, jak oceniać, kto może mi pomóc, a kto nie (rekrutacja), jak współpracować z innymi, jak zadowolić szefa i klienta.

Na poziomie technicznym bycie dobrym programistą to dla mnie umiejętność projektowania, recenzowania, kodowania, debugowania, testowania, pisania przydatnych instrukcji użytkownika, komentowania kodu innym programistom w znaczący sposób, zarządzania wersjami, symulacji i zawsze znajdowania rozwiązanie do codziennej poprawy produktywności, do automatyzacji zadań (testowania, debugowania, analizy danych w celu prognozowania obciążenia lub cokolwiek innego). Oznacza to możliwość szybkiego i brudnego kodu, gdy jest to potrzebne lub uzasadnione, ale także umiejętność wykonania czystego, dobrze przemyślanego kodu.

Wszystko to nabywa się nie poprzez naukę dla samego siebie, ale przez naukę w celu zaspokojenia potrzeb, które tam masz. Uczenie się dla dobra jest dobre, aby dać ci solidne podstawy, ale uczenie się w określonym celu jest dobre dla urzeczywistnienia.

Dobry programista jest w końcu tym, który jest w stanie wybrać to, co jest wymagane do wykonania zadania.

Wygląda na to, że jesteś wszędzie. Myślę, że ludzie uczą się najwięcej, kiedy koncentrują się na konkretnym obszarze i naprawdę kopią, ponieważ kiedy to robisz, niezmiennie napotykasz pewne problemy, które wymagają nauki innego narzędzia. W ten sposób możesz rozwijać swój zestaw umiejętności w sposób organiczny i ściśle ze sobą powiązany, abyś nie stracił zdobytej wiedzy, ponieważ każdy nowy pomysł lub narzędzie, które zostanie włączone do mentalnego zestawu narzędzi, pozwoli ci znacznie łatwiej nauczyć się innych.

Wybierz dobry projekt Open source, który Cię interesuje, i zacznij uczyć się jego kodu oraz przyczyniać się do poprawiania błędów i nowych funkcji. To coś powinien zrobić każdy programista.

Rozpocznij projekt już teraz, jedynym sposobem na naukę jest znalezienie rozwiązania prawdziwego problemu. Jeśli niczego nie budujesz, nie masz jeszcze problemu do rozwiązania.