Czy w miarę zdobywania doświadczenia programowanie staje się łatwiejsze do czytania, pisania i rozumienia? [Zamknięte]


80

Jestem początkującym programistą i czytam książki, studiuję, czytam artykuły i tak dalej. Osiągam świetne wyniki, odkąd zacząłem uczyć się programowania, a kiedy byłem początkujący, myślałem, że wiem wszystko o programowaniu, ale gdy dowiedziałem się więcej, zdałem sobie sprawę, jak trudne jest to pole (w rzeczywistości wszystkie pola są trudne, ale nie o to chodzi).

Obecnie napisałem funkcjonalne oprogramowanie i nauczyłem się PODSTAWY 3 języków i jestem średnio zaawansowany tylko w jednym języku. Kiedy patrzę na zaawansowane rzeczy, takie jak MYSQL, programowanie OpenGL, a nawet kod Visual Studio C ++, to mnie boli, a nawet podczas wizualizacji kodu źródłowego HTML wielu stron internetowych (większość kodów źródłowych na stronach internetowych, widzianych przez Google Chrome, wydaje się bardzo niechlujna i niezorganizowana ) sprawia, że ​​jestem zdezorientowany do samego końca mojego mózgu. Na początku wszystko wydaje się proste, ale patrząc na te zaawansowane rzeczy zastanawiam się, jak można się tak wiele nauczyć.

Krótko mówiąc, pytanie brzmi, czy programista staje się jaśniejszy w miarę postępów w swojej karierze. Czy skomplikowane tematy, jak wymienione powyżej (OpenGL, MySQL, zaawansowane witryny HTML) stają się łatwiejsze do czytania, pisania i rozumienia w miarę, jak się uczysz, czy stają się coraz bardziej skomplikowane w miarę upływu czasu? Jak możesz walczyć z poczuciem, że jesteś mrówką w świecie programowania, a te rzeczy mają wkrótce cię zmiażdżyć?


24
Sugeruję przeczytanie tego: norvig.com/21-days.html
James P.

Jak wszystko inne, tak. Dopóki technologia Cię nie zmieni. :-)
MathAttack,

3
Tak długo, jak twoje „doświadczenie” nie czyta w kółko tych samych rzeczy. Rozciągnij się dzięki nowym rzeczom.
JeffO

mała wskazówka, do analizy złożonych stron HTML, warto użyć Firebug Firefoksa lub Inspect Element w Chrome.
Lie Ryan,

6
„kiedy byłem początkujący, wydawało mi się, że wiem wszystko o programowaniu”. Byłem tam i im więcej się uczę, tym bardziej zdaję sobie sprawę, jak mało wiem.
Lieven Keersmaekers,

Odpowiedzi:


134

Krótka odpowiedź: nie.

Długa odpowiedź:

Tak, czytanie kodu innych ludzi staje się łatwiejsze. Ale tylko czytanie. W miarę zdobywania doświadczenia i umiejętności rosną Twoje osobiste wymagania jako programisty.

  • Nie chcesz po prostu pisać kodu. Chcesz napisać piękny kod .

  • Nie zakładasz, że Twój kod działa w idealnych warunkach . Zaczynasz myśleć o wszystkich złych rzeczach, które mogą się zdarzyć podczas uruchamiania kodu, radzić sobie z wyjątkami, myśleć o problemach sprzętowych, opóźnieniach w sieci, a problem narasta wraz ze wzrostem umiejętności.

  • Nie czytasz i nie piszesz kodu w jedynym znanym języku. Jako zręczny programista wiesz, że aby rozwiązać ten konkretny problem, który masz teraz, programowanie funkcjonalne jest znacznie lepszą alternatywą , dlatego musisz teraz czytać i pisać kod w funkcjonalnym języku programowania.

  • Nie ograniczasz się do małego zestawu bibliotek, które znasz. Jeśli kodujesz w języku C #, chcesz poznać i wykorzystać pełną moc wielu bibliotek .NET Framework.

  • Nie używasz już notatnika. Potrzebujesz potężnego IDE i chcesz wiedzieć, jak testować jednostkowo kod, o czym są dane kodu i jakie są znaczenie setek opcji i okien, które IDE może ci pokazać.

  • Nie chcesz skromnie ograniczać się do podstawowego zestawu narzędzi udostępnianych przez język . W języku C # chcesz używać ogólnych, kontraktów kodu, refleksji, programowania opartego na zdarzeniach, aspektów funkcjonalnych z LINQ, rozszerzeń Reactive i mnóstwa innych rzeczy, których się nauczyłeś - wszystko w jednym projekcie, jeśli te rzeczy pomogą ci lepiej pisać kod.

  • Nie zaczynasz pisać kodu . Spędzasz od 80 do 90% swojego czasu na gromadzeniu wymagań , tworzeniu architektury aplikacji, pisaniu testów jednostkowych, pisaniu dokumentacji itp., A tylko 10 do 20% swojego czasu na pisanie rzeczywistego kodu .

  • Dbasz o bezpieczeństwo . Znasz problemy prawne, które mogą wynikać z danych przetwarzanych przez twoje aplikacje. Wiesz, co to jest ITIL . Znasz niektóre normy ISO i stosujesz je codziennie w swojej pracy.

Tak, zdobywasz doświadczenie i umiejętności, a dzięki zdobytej wiedzy i zdolnościom intelektualnym łatwiej jest rozwiązać dany problem. Ale problemy, które musisz rozwiązać, rosną i nie jesteś podekscytowany rozwiązywaniem problemów na poziomie tych, które rozwiązałem, kiedy zacząłeś programować.

Zdobywając umiejętności, zyskujesz także wgląd w złożoność tworzenia oprogramowania, poznajesz aspekty, których nawet nie wyobrażałeś sobie, kiedy zacząłeś uczyć się programowania, i chcesz i musisz stosować wszystkie rzeczy, których się uczysz codziennie.

W skrócie:

  1. Pierwszego dnia, kiedy zaczynasz uczyć się programowania, zadanie wyliczenia wszystkich liczb od 1 do 100 podzielnych przez dwa jest bardzo złożone: właśnie nauczyłeś się tworzyć pętle i wyświetlać liczby na ekranie, ale nie masz pojęcia, jak sprawdzić, czy liczba jest podzielna przez dwa.

  2. Dziesięć lat później to samo ćwiczenie wydaje się niezwykle proste. Ale także dziesięć lat później piszesz aplikacje, które muszą wykorzystywać transakcje, są hostowane na kilku serwerach i muszą poprawnie obsługiwać stan sesji między serwerami oraz przechowują dane konta bankowego twoich klientów, ze wszystkimi wynikającymi z tego aspektami bezpieczeństwa i prawnymi.

  3. ... A ty zastanawiasz się: „Jak mógłbym to zrobić?” dokładnie tak samo, jak dziesięć lat temu, kiedy trzeba było wyświetlać liczby na ekranie z pętlą.

Kiedy wszystko staje się dla ciebie łatwe w domenie, oznacza to, że albo osiągnąłeś perfekcję w tej dziedzinie, albo po prostu już cię to nie obchodzi.

Osiągnięcie doskonałości w tak wielkiej dziedzinie, jak tworzenie oprogramowania, jest niemożliwe, bez względu na to, jak jesteś inteligentny.


36
Chodzenie po wodzie i tworzenie oprogramowania ze specyfikacji jest łatwe, jeśli oba są zamrożone (pokazuje, że „Nie zaczynasz pisać kodu. Spędzasz miesiące na gromadzeniu wymagań” - to trochę nierealne)
jfs

9
„programowanie funkcjonalne jest znacznie lepszą alternatywą ” jest dyskusyjne.
jfs

15
Z pewnością mam nadzieję, że bit „programowania funkcjonalnego” jest tylko przykładem „używania odpowiedniego narzędzia do pracy”, a nie sugerowania, że ​​programowanie funkcjonalne jest rzeczywiście lepsze do ogólnego użytku.
Ben Brocka,

7
Zauważę również, że „miesiące gromadzenia wymagań” bez rozwoju będą miały miejsce jedynie w zasadniczo wyidealizowanym modelu wodospadu. Jeśli nie wykonujesz iteracji, zabijasz siebie i projekt.
Ben Brocka,

8
„Nigdy nie jest łatwiej, po prostu jedziesz szybciej”. / Greg LeMond /
daGrevis

20

Jako dziecko uczysz się mówić, a następnie czytać swój język ojczysty. Zwykła mechanika tego jest początkowo walką, ale w pewnym momencie przychodzi płynnie. Jednak wciąż masz nieskończoną ilość książek, których nie przeczytałeś, a na niektóre tematy musisz najpierw poszerzyć swoje słownictwo, aby móc zrozumieć książkę.

To samo dotyczy programowania komputerowego. W pewnym momencie sam język przestaje być językiem obcym, ale wciąż jest wiele rzeczy napisanych w tym języku, których jeszcze nie znasz. Ale wszystko jest dostępne dla ciebie z pewnym wysiłkiem.

Niektóre zadania programistyczne są bardzo powtarzalne, w zasadzie ponowna implementacja bardzo podobnego oprogramowania dla różnych klientów. W tych zawodach możesz poczuć się jak na płaskowyżu nauki. W innych pracach cały czas robisz coś nowego i wyjątkowego i nigdy nie przestajesz uczyć się nowych rzeczy.


18

Jest już kilka naprawdę dobrych odpowiedzi, ale pomyślałem, że mogę dodać jeszcze kilka krótkich punktów:

gdy byłem początkujący, wydawało mi się, że wiem wszystko o programowaniu, ale gdy się dowiedziałem, zdałem sobie sprawę, jak trudna jest ta dziedzina

Nazywa się to efektem Dunninga-Krugera . Jest to niezwykle powszechne wśród początkujących programistów, aw rzeczywistości początkujących w wielu dziedzinach.

Większość kodów źródłowych na stronach internetowych, widzianych przez Google Chrome, wydaje się bardzo niechlujna i niezorganizowana

Czy osoby, które napisały te strony internetowe chciały, abyś je rozumiał? Prawdopodobnie nie. W ich interesie leży, aby kod był trudny do zrozumienia.

po prostu zastanawiam się, jak można się tak wiele nauczyć.

Przez specjalizującą się . Jestem ekspertem w niezwykle wąskiej dziedzinie: projektowaniu i implementacji analizatorów semantycznych kompilatora C #. Gdybym spędził piętnaście lat studiując OpenGL, XML, HTML lub cokolwiek innego, byłbym w tym ekspertem i mistyfikowany przez analizatory semantyczne. Ale tego nie zrobiłem i dlatego mam bardzo podstawową wiedzę na temat OpenGL, XML i HTML.

Krótko mówiąc, pytanie brzmi, czy programista staje się jaśniejszy w miarę postępów w swojej karierze.

Tak, ponieważ zaczynasz widzieć większe wzory. Weźmy na przykład OpenGL. Prawdopodobnie widziałeś kilka „bibliotek API” - dużych kawałków pokrewnego kodu, w których sposób, w jaki komunikujesz się z kodem, polega na wywołaniu szeregu nazwanych funkcji z określonymi argumentami. Podstawową wiedzę na temat OpenGL można uzyskać po prostu dzięki zrozumieniu, że jest to interfejs API.

Gdy zdobędziesz więcej doświadczenia i zobaczysz wiele różnych technik programowania, zdajesz sobie sprawę, że pozornie niepowiązane technologie - powiedzmy, OpenGL i LINQ w języku C # - mają cechy wspólne. Oba są interfejsami API, w których budujesz przepływy pracy, które przepływają wokół danych, i które możesz uruchamiać optymalizatory i inne transformacje w przepływie pracy w bogaty i interesujący sposób. Gdy masz już tę koncepcję w swoim zestawie narzędzi, nagle staje się o wiele łatwiej wykorzystać pełną moc dowolnego interfejsu API korzystającego z tego wzorca.

Czy skomplikowane tematy, jak wymienione powyżej (OpenGL, MySQL, zaawansowane witryny HTML) stają się łatwiejsze do czytania, pisania i rozumienia w miarę, jak się uczysz, czy stają się coraz bardziej skomplikowane w miarę upływu czasu?

Stają się zarówno łatwiejsze, jak i bardziej skomplikowane. Łatwiej, ponieważ, jak powiedziałem, zaczynasz rozpoznawać większe wzorce myślowe, które leżą u podstaw projektu systemu, co pozwala na bardziej efektywne korzystanie z systemu. Bardziej skomplikowane, ponieważ teraz możesz użyć systemu do rozwiązania bardziej skomplikowanych problemów , a następnie zaczniesz napotykać ograniczenia systemu.

Jak możesz walczyć z poczuciem, że jesteś mrówką w świecie programowania, a te rzeczy mają wkrótce cię zmiażdżyć?

Jesteś mrówką; wszyscy jesteśmy mrówkami. Ale to nie stopa cię przygniata; to świat, w którym możesz odkrywać, żyć, czerpać korzyści i ulepszać. Ty, mrówka, możesz odkryć tylko niewielką jego część. Wybierz część, którą lubisz, w której możesz dodać prawdziwą wartość i stać się ekspertem w tej dziedzinie.


2
Bardzo dziękuję za tę odpowiedź, jest ponad resztą, ponieważ nie tylko odpowiada na moje główne pytanie, ale także otwiera moje oczy na pewne rzeczy. +1
Bugster,

@Eric: Co powiedziałbyś osobie w tego rodzaju tematach, w której mówi: „specjalizacja dotyczy owadów, a nie ludzi”?
Joan Venge

@JoanVenge Czy ktoś tak powiedziałby? Zwykle ludzie chcą się specjalizować i być wyjątkowi, a tym bardziej, jeśli czują potrzebę odróżnienia się od zwierząt (lub owadów).
Matthew

1
źle rozumiesz, jaki efekt Dunninga-Krugera definiuje się jako niezdolność niewykwalifikowanego do rozpoznania własnej nieudolności i dokładnej oceny własnych umiejętności . Jeśli nie możesz rozpoznać, nie wiesz wszystkiego, nigdy nie możesz nauczyć się niczego nowego. Jeśli potrafisz to rozpoznać, nie jest to DKE.

+1 za Wybierz część, którą lubisz, w której możesz dodać prawdziwą wartość i stać się ekspertem w tej dziedzinie.
Akshay Khot

14

Krótka odpowiedź, tak.

Biorąc pod uwagę czas i ekspozycję, rzeczy te stają się łatwiejsze do zrozumienia.

Pamiętaj, że kiedy przeglądasz strony z narzędzi programistycznych w przeglądarce, często są one generowane przez framework. Niech to będzie dowolna liczba rzeczy ... ASP.NET, JSP, RoR, Django, ... kto wie. Niektóre z tych frameworków generują czystszy kod niż inne.

Na zakończenie ... narażenie prowadzi do biegłości. Nie ma sposobu, aby stłumić to uczucie. Po prostu doświadczenie i nauka. Zajmuje trochę czasu, aby się wprowadzić, zdobyć wiedzę na temat domen i nauczyć się umiejętności, z których korzysta środowisko.


1
Jest w tym trochę prawdy, o ile osoba, która napisała kod, stosowała dobre praktyki i zwyczajowe idiomy zarówno w języku, jak i ogólnie w programistach. Nieprawidłowe kodowanie i / lub celowe zaciemnianie może spowalniać cię do indeksowania. Spróbuj upuścić przez CodeGolf.SE . Nawet wersje „w jasnej” formie mogą być trudne, ponieważ dobre praktyki zostały poświęcone przy zmianie metryki konkursu.
dmckee,

@dmckee Nawet zły kod staje się znacznie łatwiejszy do odczytania z doświadczeniem. Zauważam to szczególnie w C ++ (i musiałem przeczytać wiele złego kodu). Oczywiście jest to ekstremalna przeszkoda, ale jednak staje się znacznie łatwiejsza, gdy zaczniesz dostrzegać wzorce złego projektu i typowych błędów. Tworzą one także rodzaj idiomu, którego się nauczysz.
Konrad Rudolph

2

Zgadzam się z niektórymi odpowiedziami już udzielonymi, ale myślę, że są one również podstawą, o której nie dyskutowano o czytaniu kodu. Kiedy po raz pierwszy zacząłem patrzeć na jakiś kod open source, wydawało się to przytłaczające i ogromne. Ale zgadnij co? zawsze będzie ogromny. W pewnym momencie zdajesz sobie sprawę, że jesteś lepszy w wydobywaniu tego, co konkretnie chcesz wiedzieć i kontynuowaniu.

Jednym z podanych przez ciebie przykładów było jednak przeglądanie kodu HTML:

Dlaczego patrzysz na kod HTML? Prawdopodobnie nie dlatego, że chcesz nauczyć się HTML całej witryny. Istnieje pewna konkretna sztuczka, którą masz nadzieję wybrać. W takim przypadku po prostu znajdź odpowiedni kod HTML za pomocą narzędzia takiego jak Firebug.

Jeśli naprawdę chcesz się dowiedzieć, jak powstaje cała witryna, zdałeś sobie sprawę, że renderowany HTML nie jest dobrym sposobem. Lepiej byłoby spojrzeć na projekt open source wykorzystujący podobną technologię. Jednak próba nauczenia się kodu całego projektu nie jest tak opłacalna, jak się wydaje. Jest nudny, czasochłonny, łatwo zapomnieć o tym, czego się nauczyłeś, a na koniec nie masz nic do pokazania. Mniej nauczysz się czytając kod innych ludzi w nieskończoność, a znacznie więcej, używając konkretnych, interesujących fragmentów do pisania wtyczek, dodatków do funkcji lub jako rusztowań i porad dla własnych projektów.

Spróbuj nauczyć się absolutnego minimum, aby zdobyć coś własnego. Wróć do punktów odniesienia tylko wtedy, gdy utkniesz lub chcesz nauczyć się konkretnej nowej rzeczy. Jest to sprzeczne z konwencjonalną mądrością, że musisz wszystko zrozumieć lub programujesz w ciemności. Ale w końcu zdajesz sobie sprawę, że ten cel jest niemożliwy i uczysz się równoważyć cele polegające na poznaniu wszystkiego i cel faktycznego ukończenia tego, nad czym pracujesz.


2

Krótka odpowiedź brzmi TAK, ale wiele z nich zależy od tego, jak zdefiniujesz doświadczenie.

Myślę, że są co najmniej 3 części do opracowania. Gdy stajesz się lepszy w każdym segmencie, pewne rzeczy stają się wyraźniejsze.

  1. Zrozumienie wymagań BIZNESOWYCH . To daje lepszy widok aplikacji z lotu ptaka. Im lepiej zrozumiesz, jakie są reguły biznesowe, tym szybciej dowiesz się, dlaczego pewne rzeczy są wykonywane w określony sposób. Np. Twoi klienci muszą przestrzegać przepisów rządowych X, dlatego muszą przygotować dokument Y, dlatego potrzebują przechowywanych pozornie bezużytecznych informacji.

  2. Zrozumienie wymagań technicznych . To jest jak # 1, z wyjątkiem tego, że bardziej rozumie dlaczego na poziomie technicznym. Niektóre narzędzia i technologie mają swoje dziwactwa, dopóki nie poradzisz sobie z nimi, zanim trudno będzie zrozumieć, dlaczego rzeczy są wykonywane w określony sposób. Jest to bardziej widoczne w przypadku starszych systemów. Np. Aplikacja używa określonej magistrali usług, która pobiera tylko XML.

  3. Zrozumienie wymagań JĘZYKA . Jak wspomnieli inni, im bardziej masz doświadczenie w posługiwaniu się językiem, tym szybciej możesz przeczytać, co próbował osiągnąć oryginalny program kodujący. Jednak bez # 1 i # 2 przekonasz się, że ta zwiększona zdolność osiąga szczyt dość szybko.

Staraj się angażować w wiele aspektów rozwoju, ponieważ tak naprawdę nie jest to łatwiejsze, dopóki nie wykonasz wszystkich obszarów przynajmniej kilka razy.

Pamiętaj, że doskonałość (i cel) w czyimś kodzie zawsze zależy od # 1 i # 2. Są to główne czynniki określające, dlaczego kod jest w stanie, w jakim się znajduje. Częste zmiany w tych dwóch obszarach są największym powodem, dla którego cały czas otrzymujemy kod spaghetti. Więc jeśli nie jesteś biegły w czytaniu wymagań biznesowych i technicznych, zadaniem czytania kodu zawsze będzie królewska PITA.


2

To staje się łatwiejsze i bardziej skomplikowane w tym samym czasie!

Poznanie innych to mądrość;
Poznanie siebie jest oświeceniem.
Opanowanie innych wymaga siły;
Opanowanie siebie wymaga siły;
Ten, kto wie, że ma dość, jest bogaty.
Wytrwałość jest znakiem siły woli.
Ten, kto zostaje tam, gdzie jest, trwa.
Umrzeć, ale nie zginąć, musi być wiecznie obecny.

przetłumaczone na Software Development

Znajomość wielu technologii to mądrość. (Wszystko pochodzi od ALGOL)
Wiedza o tym, czego nie wiesz, to oświecenie. (LISP)
Opanowanie wielu języków, ram i platform wymaga dużego wysiłku. (Java)
Opanowanie tylko tego, co musisz wiedzieć i tylko to wymaga siły. (i Google lub stackoverflow.com)
Wiedząc, kiedy przestać kodować i dostarczyć coś, musisz wiedzieć, kiedy jest wystarczająco dobry. (Bez paraliżu analizy lub złocenia)
Pracuj dalej nad tym, co próbujesz osiągnąć, wymaga skupienia i siły. (Wszystko ciągle się zmienia, nigdy nie jesteś skończony)
Trzymaj się jednej lub dwóch technologii, a wytrzymasz. (COBOL nadal dobrze się płaci, podobnie jak C)
Rezygnacja z programowania i przejście do zarządzania to wieczna obecność. (lub pozostaw dziedzictwo oprogramowania FOSS, z którego wszyscy będą nadal korzystać po śmierci).


Więc zamiast być mrówką powinieneś być karaluchem i po prostu wstać, gdy cię zmiażdży, prawda? :-P
Bugster

„Analiza paraliżu”! = „Wiedzieć, kiedy przestać kodować”. To więcej „wiesz, kiedy zacząć kodować”.
Ben Voigt,

0

Krótko mówiąc, pytanie brzmi, czy programista staje się jaśniejszy w miarę postępów w swojej karierze. Czy skomplikowane tematy, jak wymienione powyżej (OpenGL, MySQL, zaawansowane witryny HTML) stają się łatwiejsze do czytania, pisania i rozumienia w miarę, jak się uczysz, czy stają się coraz bardziej skomplikowane w miarę upływu czasu? Jak możesz walczyć z poczuciem, że jesteś mrówką w świecie programowania, a te rzeczy mają wkrótce cię zmiażdżyć?

Zamierzam zająć nieco inne podejście niż inni respondenci; Wierzę, że czytanie i pisanie kodu staje się łatwiejsze, gdy robisz to więcej, i pokażę to za pomocą prostej analogii.

Pomyśl o tym, kiedy zacząłeś uprawiać sport. Na początku pierwszego sportu, którego się nauczyłeś, podstawowa koordynacja prostych zadań jednego sportu prawdopodobnie wydawała się bardzo trudna. Gdy nabrałeś trochę doświadczenia, zacząłeś opanowywać proste zadania, abyś nie musiał o nich więcej myśleć, i zauważyłeś, że istnieją bardziej złożone zadania, na które możesz zwrócić uwagę (jak oglądanie innych graczy w celu przewidzenia ich zachowanie).

Potem, kiedy próbowałeś swoich sił w innym sporcie, prawdopodobnie odkryłeś, że nie byłeś tak daleko w tyle, kiedy zaczynałeś. Złapanie koszykówki jest czymś zupełnie innym niż złapanie baseballu, ale ktoś, kto opanował jednego z nich, będzie miał znacznie łatwiej złapać innego niż osoba, która nigdy wcześniej tego nie robiła. Dzięki swojemu doświadczeniu w uprawianiu drugiego sportu odkryłeś, że pierwszy sport dał ci zarówno konkretne, jak i ogólne umiejętności. Określone umiejętności (łapanie piłki do koszykówki) są przydatne tylko w ich dziedzinie, ale umiejętności ogólne (śledzenie szybko poruszającego się obiektu zbliżającego się w trójwymiarowej przestrzeni i opracowywanie planu radzenia sobie z nim) sprawiają, że jesteś lepszy we wszystkich powiązanych domenach.


Co to ma wspólnego z programowaniem? Pierwszy wiersz kodu, który czytasz, wystawia cię na świat zbudowany na określonych zasadach. Nauczyłeś się tych zasad (składni i idiomów tego języka) jako konkretnych umiejętności, ale nauczyłeś się także kilku cennych umiejętności ogólnych: rozumienie, w jaki sposób komputery działają wewnętrznie i jak wyrażać swoje intencje w sposób, który komputer może zrozumieć. Każdy nowy język, którego się uczysz, daje ci nowe specyficzne umiejętności, ale także wzmacnia twoje ogólne umiejętności i pomaga zobaczyć wzory wystrzeliwane we wszystkich językach komputerowych, takich jak złoża minerałów ułożone wzdłuż ściany kanionu. Kiedy naprawdę zaznajomisz się z kilkoma różnymi językami, zaczniesz rozpoznawać „kształt” większości dowolnego kodu, jeśli wybaczysz niejasność, nawet jeśli nie wiesz nic o języku, w którym jest napisany.

Na przykład wszystkie trzy wymienione przez Ciebie języki (MYSQL, OpenGL, C ++) mają kilka wspólnych cech:

  • Możliwe jest osobne obliczenie małych części algorytmu i skomponowanie ich później w kompletne rozwiązanie
  • Komputer zwykle wymaga pewnego przygotowania ogólnego, aby można było rozpocząć pracę nad konkretnym problemem (utworzenie tabeli, zainicjowanie obszaru roboczego lub załadowanie wspólnych bibliotek)
  • Wcześniejsze instrukcje mają pierwszeństwo i wpływają na późniejsze instrukcje, tzn. Komputer zaczyna się na górze kodu i działa w dół

Im więcej programujesz, tym bardziej zdajesz sobie sprawę, że bez względu na kształt kuli, wciąż jest to tylko piłka zbliżająca się do Ciebie i wiesz, co z nią zrobić, nie zastanawiając się nad tym zbyt wiele. Całe programowanie polega na próbie wyrażenia swoich intencji w sposób zrozumiały dla komputera; naucz się wystarczająco, a zaczniesz być w stanie odczytać zamiary zamiast kodu.

PS - Za każdym razem, gdy w końcu zaczynasz czuć się tak, jakbyś się nauczył, napotykasz coś, co absolutnie łamie ci mózg i sprawia, że ​​czujesz się jak początkujący rangę. Właśnie to kochamy w tej pracy, zawsze jest coś nowego do nauczenia się.


0

Krótka odpowiedź: Tak , ogólnie

Jednak nie staniesz się specjalistą, jeśli uogólnisz. Stanie się specjalistą oznacza również uświadomienie sobie wszystkiego, czego nie wiesz: może to być przytłaczające uczucie.

W miarę upływu czasu zdobywasz doświadczenie.

W miarę upływu czasu inne języki / wzorce itp. Rozwijają się równolegle z twoim rozwojem.

Inną zmienną w twoim pytaniu jest to, czy zdobywasz znaczące doświadczenie w branży, ponieważ porusza się ona również w tym samym stałym czasie. Przemysł technologiczny jest ruchomym celem i w przeciwieństwie do większości innych branż.

Dobrym pytaniem może być również to, czy rozpościerasz się za cienki czy za gruby na jakiś język.


0

To niekończące się źródło zachwytu (i niepokoju), ile jest języków komputerowych i zakres, w jakim ciągle się zmieniają. Dodaj do tego liczbę różnych frameworków w każdym języku i dla każdej frameworki, szeroką gamę dostępnych bibliotek i wtyczek. Dodaj do tego liczbę edytorów kodu i IDE.

Wszystkie te odmiany mają dwa wymiary złożoności.

  1. Ich słownictwo i składnia jest inna.
  2. Abstrakcje (pojęcia wysokiego poziomu), które obsługują, są różne.

Mają też jedną wspólną cechę. Kompletność Turinga. Przy wystarczającym wysiłku programisty można je wszystkie wykorzystać do rozwiązania wszystkich problemów! Jeśli więc zaczniesz od języka takiego jak C (mały słownictwo, złożona składnia i prawie żadnych abstrakcji), na pewno poczujesz, że możesz zrobić wszystko (całkiem słusznie).

Następnie przełącz się na „łatwe rzeczy”, takie jak CSS, HTML, JavaScript, a może także frameworki, takie jak Bootstrap i React, a twój mózg się usmaży - podobnie jak Albert Einstein. Ludzie myślą „znam francuski, więc nauka niemieckiego powinna być łatwa”. Nie!

Wiele abstrakcji programowych można się nauczyć z wzorców oprogramowania . Istnieje kilka książek poświęconych temu tematowi. Wzory są wszędzie, są niezależne od języka i można je raz nauczyć . Jeśli znasz swoje wzorce, możesz używać ich w dowolnym języku i rozpoznawać je po wbudowaniu w języki, a częściej w różnych ramach.

Większość ludzi potrzebuje 1-2 lat, aby biegle posługiwać się nowym językiem, o czym wiedzą pracodawcy. Dlatego nie zatrudniają osób, które nie mają doświadczenia w swoim języku, ponieważ nowy pracownik będzie spędzał dużo czasu zmagając się z tym językiem, a zbyt mało czasu na rozwiązywanie problemów biznesowych.

Podsumowując, zasady / abstrakty informatyczne, wzorce oprogramowania i rodzaj napotkanych problemów biznesowych - wszystko zmienia się powoli. Możesz nauczyć się raz i stopniowo gromadzić nową wiedzę. I odwrotnie, języki komputerowe, frameworki, tak zwane „ekosystemy” i biblioteki komponentów zmieniają się bardzo szybko, podobnie jak wszystkie otaczające je narzędzia. Tutaj oczekuj, że tempo nauki będzie wolne i czasochłonne!


-1

Czy skomplikowane tematy, jak wymienione powyżej (OpenGL, MySQL, zaawansowane witryny HTML) stają się łatwiejsze do czytania, pisania i rozumienia w miarę, jak się uczysz, czy stają się coraz bardziej skomplikowane w miarę upływu czasu? Jak możesz walczyć z poczuciem, że jesteś mrówką w świecie programowania, a te rzeczy mają wkrótce cię zmiażdżyć?

Kiedy poczyni się jakikolwiek postęp, uczymy się i uczymy na nowo tego, co myśleliśmy wcześniej. - Henry David Thoreau

Jest historia mistrza Zen i przepełnionego filiżanki .

Czasami musimy porzucić nasze z góry przyjęte pojęcia i opinie z przeszłości, abyśmy mogli nauczyć się nowych pojęć.

Pamiętaj: jeśli czujesz się przytłoczony nową koncepcją, musisz poszukać wielu nauczycieli.

Ostatnio, kiedy otrzymałem zadanie aktualizacji oprogramowania wewnętrznego firmy, które korzystało z języka skryptowego, nie znałem go. Na początku było bardzo stresujące. Jednak po zmianie nastawienia zacząłem szukać zasobów wyjaśniających składnię i podstawowe pojęcia. Ukończyłem projekt i teraz używam tego języka skryptowego jako jednego z moich narzędzi do wykonywania większej liczby zadań.

Twoje nastawienie robi różnicę.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.