Przeczytałem wiele książek dla różnych języków programowania, Java, Python, C itp. Rozumiem i znam wszystkie podstawy języków oraz rozumiem algorytmy i struktury danych. (Odpowiednik, powiedzmy, dwóch lat zajęć z informatyki)

ALE nadal nie mogę zrozumieć, jak napisać program, który robi coś pożytecznego.

Wszystkie książki programistyczne pokazują, jak napisać język, ale NIE, jak go używać! Wszystkie przykłady programowania są bardzo proste, takie jak zbudowanie katalogu kart do biblioteki lub prostej gry lub użycie algorytmów itp. Nie pokazują, jak tworzyć złożone programy, które faktycznie robią coś pożytecznego!

Patrzyłem na programy open source na SourceForge , ale nie mają one dla mnie większego sensu. W każdym programie znajdują się setki plików i tysiące linii kodu. Ale jak się tego nauczyć? W żadnej książce, którą mogę kupić na Amazon, nie ma nic, co dałoby mi narzędzia do napisania dowolnego z tych programów.

Jak przechodzisz od czytania wstępu do języka Java lub programowania w języku Python lub C Programming Language itp. Do faktycznego stwierdzenia, że ​​mam pomysł na program X? Czy tak to robię?

Wygląda na to, że pisanie programu wymaga o wiele więcej niż można się nauczyć w książce lub na zajęciach. Czuję, że coś jest.

Jak mogę ustawić właściwy tor?

Tworzenie bardziej złożonych programów wiąże się z doświadczeniem. Kiedy programowałem po raz pierwszy, myślałem, że mam się dobrze, jeśli ma ponad 25 linii (i musiałem użyć paska przewijania). Teraz piszę setki linii dziennie przez lata w tej samej aplikacji projektowej.

Ta strona może być dla Ciebie interesująca „Naucz się programowania w ciągu dziesięciu lat” http://norvig.com/21-days.html

BTW: Bardzo trudno jest uruchomić program. Pisarz może nazwać to „blokiem pisarzy”. Zamiast tego sugeruję, abyś zaczął pisać kod i go poprawiał. Nie bój się usuwać dużych sekcji, które nie robią tego, czego potrzebujesz. Zacznij od nowa, tym razem napiszesz z lepszym wyobrażeniem o tym, co robisz. Zacznij od nowa, a przekonasz się, że nie potrzebujesz połowy tego, co napisałeś ostatnim razem. Kiedy autor pisze historię, zajmuje dużo czasu, dużo pisania i przepisywania itp., Wiele recenzji i opinii, a kończy się dopiero, gdy musi zostać opublikowana (wydana)

Zawsze byłem przytłoczony także bardzo dużymi projektami, takimi jak te, które można znaleźć na SourceForge lub GitHub. Zastanawiałem się, jak ktokolwiek, a nawet zespół, może zrozumieć, co się dzieje w plikach 10 lub 100 plików, z tysiącami wierszy kodu.

Nikt tego nie robi. Przynajmniej na początku.

Projekty to rzeczy organiczne. To, co zaczyna się jako naprawdę prosty pomysł, może szybko przerodzić się w ogromną pracę. To, moim zdaniem, główny powód rozwoju iteracyjnego zamiast klasycznego podejścia do wodospadu.

Pomyśl o budowie samochodu. Z zewnątrz wygląda to dość prosto, ale zagłębiając się w ciebie, odkrywasz, że istnieje ogromna liczba rozważań, kompromisów i niewinnych spraw, które należy rozwiązać.

Przykład:

W przypadku częściowo dużego projektu często zaczyna się od małego. „Chcę zbudować serwer pamięci podręcznej”. Więc spędzasz kilka dni na hakowaniu i dochodzisz do czegoś, co działa, ale można go znacznie poprawić. Więc dodajesz pojęcie wątków.

Następnie napotykasz problemy z współbieżnością z powodu tego wątkowania. Naprawiasz to, zmieniając na współbieżne struktury danych.

Teraz proces zwolnił. Zmieniasz więc współbieżne struktury danych na zwykłe, ale udostępniasz mechanizmy blokujące do synchronizacji.

Wydaje się, że wszystko działa poprawnie, z wyjątkiem użytkowników, którzy zaczynają narzekać, że operacje nie są atomowe, a dane ulegają uszkodzeniu.

W ten sposób dodajesz klasyczne operacje atomowe, takie jak zwiększanie i zapisywanie. To działa, a twoi użytkownicy są zadowoleni. Ale ktoś otwiera bilet z pytaniem, czy można wykonać operacje na liście.

Więc spędzasz tydzień lub dwa budując tę ​​funkcję. Mniej więcej w tym czasie przyjaciel decyduje się ci pomóc. Pracujesz nad tym razem, uzupełniasz i wypuszczasz.

Dwa bilety otwarte. Podczas przetwarzania listy występuje błąd i zdarzają się rzadkie przypadki zakleszczenia.

Twój przyjaciel pracuje nad błędem przetwarzania listy, podczas gdy ty radzisz sobie z impasem. Zdajesz sobie sprawę, że konieczne jest dość znaczące ponowne zapisanie do operacji atomowych.

... i tak to idzie.

Wydaje się to dość typowe dla rozwoju projektu. Około 10 plików właśnie wzrosło do 20 w ciągu kilku tygodni. Dodano nowe funkcje, które nie różniły się od pierwotnego planu. Dodawane są skomplikowane poprawki błędów, które zwiększają nienaturalnie duży kod.

Moja rada:

Nie przytłocz się. Jeśli masz pomysł, zaimplementuj elementy funkcjonalności. Jeśli po tym warto kontynuować, dodaj krok po kroku. Pozwól, aby Twój projekt rozwijał się naturalnie.

Nawet największy program zaczyna się od pomysłu i jest zapisywany pojedynczo.

Najlepszym (być może jedynym) sposobem nauczenia się pisania programów w świecie rzeczywistym jest rozpoczęcie robienia tego. Gdy napotykasz problemy, przeszukujesz Internet lub pytasz tutaj o rozwiązania tych problemów. W końcu zdobędziesz doświadczenie i będziesz musiał rzadziej pytać.

Są jednak pewne rzeczy, o których powinieneś wiedzieć od samego początku:

• Obecnie prawie żadna duża aplikacja nie jest napisana całkowicie od zera. Możesz zrobić znacznie więcej w znacznie krótszym czasie, jeśli użyjesz istniejących wysokiej jakości bibliotek i frameworków. Rozpoczęcie pracy z nimi często wydaje się frustrujące i wymaga więcej pracy niż samodzielne robienie tego, ale prawie nigdy tak naprawdę nie jest.
• Staranne myślenie o tym, jak ustrukturyzujesz swój program (jak go zaprojektować) jest bardzo ważne, gdy twoje programy się powiększą. Poświęć na to trochę czasu i przeczytaj książki o projektowaniu (szczególnie polecam „Clean Code”) i inżynierii oprogramowania, a także o podstawach technicznych.

Mówisz o inżynierii oprogramowania niż o programowaniu. To trochę architektura, trochę „najlepszych praktyk” i „wzorców projektowych”, trochę praca z innymi. Chociaż istnieją książki, które mogą pomóc, większość z nich pochodzi z doświadczenia. Nikt nie zaczyna pisać, powiedzmy, Microsoft Word.

Pomyśl o dużym, „prawdziwym” programie, który chciałbyś napisać. Pomyśl teraz o różnych elementach, które musisz zbudować, aby działały tak, jak chcesz. Na przykład w nowoczesnej grze pierwszoosobowej potrzebujesz silnika graficznego 3D, sztucznej inteligencji postaci innej niż gracz, modułu muzycznego / dźwiękowego, silnika fizyki i modułu najwyższego poziomu, który egzekwuje reguły gry (wie „mapa”, sposób interakcji różnych postaci itp.). A potem jest grafika i projekt postaci oraz muzyka, z których żaden nie jest kodem, ale jest niezbędny do ukończenia gry.

Teraz: Które z nich zbudujesz sam, a które dostaniesz gdzie indziej? Większość dużych projektów oprogramowania nie jest programowana od zera. Być może użyjesz gotowego silnika 3D i modułu muzyki / dźwięku i zaprogramujesz tylko te rzeczy, które czynią twoją grę wyjątkową. OK, więc musisz dowiedzieć się, jakich modułów innych firm będziesz używać, co będzie wiązało się z takimi czynnikami, jak koszt, języki, z którymi pracują, jakie funkcje mają, jak zaprojektowano ich interfejs API (czyli jak go skompletować to, jak dobrze pasuje do twojego osobistego stylu programowania itp.). Być może napiszesz „proof of concept” lub testujesz programy z wykorzystaniem jednego lub dwóch kandydatów do różnych modułów innych firm, aby upewnić się, że zrobią wszystko, czego potrzebujesz i będą łatwe w użyciu.

Również kod, który sam chcesz napisać, może być zbyt wielkim zadaniem, abyś sam mógł go ukończyć w przewidzianych ramach czasowych. Ilu innych programistów potrzebujesz do pracy nad projektem? Jak podzielisz pracę? Jak zostaną zaprojektowane różne moduły, aby wszystkie pasowały do ​​siebie, mimo że zostały napisane przez różnych ludzi? Jak wszyscy będziecie pracować na tym samym kodzie źródłowym bez wymazywania sobie nawzajem zmian (odpowiedź: kontrola wersji, co jest niezwykle przydatne, gdy pracujesz solo, ale jest niezbędne, gdy pracujesz z innymi).

Kiedy już zorientujesz się, jakie moduły chcesz napisać wewnętrznie, wykonasz ten sam proces. Wymyśl elementy każdego modułu, jak powinny się do siebie pasować, i które sam napiszesz, a które dostaniesz gdzie indziej. Kontynuuj rozkładanie rzeczy, aż każdy kawałek będzie wystarczająco mały, abyś mógł pamiętać w myślach: „tak, mógłbym to napisać!” A potem zrób to. Gdy to zrobisz, napotkasz nieprzewidziane przeszkody w sposobie łączenia różnych elementów programu. Będą to frustrujące, ale są okazją, aby dowiedzieć się więcej o swoim rzemiośle i powinny być postrzegane w ten sposób.

Początkowo będziesz w stanie przechowywać w pamięci tylko bardzo małe fragmenty swojego programu - powiedzmy, poszczególne funkcje - i będziesz musiał wiele zepsuć, zanim zaczniesz kodować. Jak można zdobyć doświadczenie, będziesz myśleć w funkcji zamiast konieczności myśleć o funkcjach i zacząć myśleć o obiektach. A potem będziesz myśleć w obiektach i myśleć o większych modułach. Wreszcie będziesz myśleć w modułach i myśleć o całych, dużych, prawdziwych programach.

A potem odkryjesz, że wciąż musisz się wiele nauczyć ... ale i tak się dzieje. Jeśli jako programista przestaniesz się uczyć, jesteś przestarzały i zostaniesz zastąpiony nowszym modelem.

W każdym razie, nie bój się i nie martw się, jeśli to zabrzmi ... okropnie lub niemożliwie, a tak naprawdę nie chcesz być programistą. To nie jest dla wszystkich. Uwielbiam muzykę i desery, mogę trochę grać na klawiszach i gotować niektóre potrawy, ale nie jestem skłonny poświęcać czasu, aby stać się wielkim muzykiem lub mistrzem kuchni.

Jeśli okaże się, że nie chcesz być programistą piszącym duże, prawdziwe aplikacje komputerowe, istnieją inne rodzaje zadań programistycznych. Możesz na przykład zostać wbudowanym programistą. Istnieją pewne interesujące wyzwania związane z pisaniem programów osadzonych i wykonujesz użyteczną pracę, ale zwykle programy są raczej mniejsze niż aplikacje komputerowe. Lub możesz pisać aplikacje internetowe. W Internecie łatwo jest skleić ze sobą trochę funkcji, dzięki czemu można napisać (np.) System komentarzy internetowych i byłby użyteczny, nawet jeśli nie jest to cała aplikacja internetowa. Łatwo jest również stopniowo ulepszać rzeczy w Internecie, dzięki czemu możesz zacząć od (powiedzmy) podstawowego klienta poczty internetowej i z czasem przekształcić go w coś takiego jak Gmail. (Ale nie rób tego, bo wtedy będziesz konkurować z Gmailem).

Jeśli w ogóle nie chcesz być programistą, ale nadal chcesz pracować z komputerami, możesz przejść do informatyki lub innej dziedziny techniki. W takich przypadkach wiedza o tym, co już programujesz, jest bardzo przydatna, ponieważ twoi rówieśnicy mogą nawet nie mieć tak dużo. Lub, wiesz, zostań muzykiem, jeśli to przemawia, ponieważ (podobnie jak większość dziedzin) dotyczy dziś komputerów. Napisz małe programy, które manipulują plikami audio lub MIDI na różne sprytne sposoby, dzięki czemu będziesz lepszym muzykiem. Przekonasz się, że wszelkie posiadane umiejętności programowania można zastosować w wielu dziedzinach, aby poprawić swoją pracę.

Nie dowiesz się, jak programować, chyba że staniesz przed prawdziwym zadaniem. Żadna teoria nigdy nie zastąpiłaby prostego zadania w świecie rzeczywistym. Przed rozpoczęciem pracy nad scenariuszami rw naiwnie czytałem mnóstwo książek ze wszystkimi przykładami, ale kiedy napotkałem prawdziwy problem, po prostu nie mogłem zebrać całej mojej wiedzy teoretycznej, aby ukończyć zadanie. Jeśli dopiero zaczynasz, polecam ci wykonywanie zadań z dowolnego miejsca. Nie myśl, że są bezużyteczne, chyba że je rozwiązałeś. W pierwszej kolejności spróbuj rozwiązać problemy ze strukturą danych, takie jak sortowanie połączonej listy, wykonywanie DFS, BFS na drzewach, wykresach itp. Nie tylko poprawi twoje umiejętności kodowania, ale co ważniejsze, poprawi twoje umiejętności analityczne i algo , które mi ufają to cenna wiedza. Następnie, gdy będziesz wiedział, że możesz kołysać za pomocą wskaźników, rekurencji,

Dolna linia. Chodzi o praktykę. Po prostu kop i kod, kod, kod.

Zacznij od gier komputerowych, tak jak wszyscy inni. Dobra gra jest wyzwaniem zarówno programistycznym, jak i projektowym, wymaga starannego przemyślenia struktury wewnętrznej i korzysta z bibliotek systemowych w sposób, który dużo uczy, ale nie psuje rzeczy i nie wymaga „dobrego powodu z dobrym wynikiem” tak jak robi to „przydatne” oprogramowanie.

Ogólna zasada jest taka, że ​​po napisaniu wystarczającej ilości rzeczy nieuchronnie nastąpi jakieś oświecenie.

Dobrym punktem na początek (jeśli masz ochotę na C) jest http://gamedev.net/ , szczególnie http://nehe.gamedev.net/ . Na początek jest także wiele innych dobrych punktów: D

Patrzysz na cały ogromny program i wydaje się to niemożliwe. Ale cała sprawa składa się z małych głupich programów, takich jak te, o których mówisz: „nie rób nic przydatnego”.

Potrzebujesz doświadczenia dzielącego ogromne, złożone zadania na małe, proste zadania. To jest rdzeń wszelkiego programowania. Reszta to tylko semantyka.

Podobnie jak jazda samochodem lub gotowanie, programowanie jest czymś, czego nauczysz się robić. Praktyka jest niezastąpiona.

Jeśli przykłady z podręcznika są już dla ciebie zbyt proste, to świetnie! Czas przejść na coś bardziej złożonego - a już możesz samodzielnie wymyślić kilka trudnych ćwiczeń.

Lub, jeśli masz na myśli konkretny pomysł, podziel go na strzępy. Najpierw rozwiąż mały podzbiór problemu. Następnie rozwiń. Gdy integracja nowego kodu z istniejącym kodem staje się trudna, przeprojektowujesz wszystko.

Napisz 200-wierszowy skrypt. Następnie zacznij go poprawiać.

Featuritis sprawi, że w jednej chwili znajdziesz 100 plików źródłowych i kilkaset KLOC :)

„Nie pokazują ci, jak tworzyć złożone programy, które faktycznie robią coś pożytecznego!”

Bez definicji „użytecznej” naprawdę niewiele możemy zrobić, aby doprowadzić Cię na „właściwą” ścieżkę.

Nie wiemy, jak się nie udaje lub co się dzieje. Nie możemy powiedzieć, na jakim torze się znajdujesz.

Jakoś masz w głowie pojęcie, że się nie komunikujesz.

Oprogramowanie - programowanie - polega na wydobyciu z głowy pojęcia w jakimś języku (Python, Java, angielski, cokolwiek innego).

Jednym ważnym krokiem w programowaniu (i zadawaniu pytań) jest zdefiniowanie terminów. Co rozumiesz przez „robienie czegokolwiek przydatnego”? Bądź bardzo jasny, bardzo kompletny i bardzo precyzyjny.

Cały czas zadaje mi to pytanie, np. Jak zacząć. To naprawdę proste. Oto krok po kroku.

1. Wyjść z pomysłem. Wygląda na to, że już to masz.
2. Uprość swój pomysł do jego podstawowego rdzenia - czegoś, co Twoim zdaniem może być w stanie rozwiązać
3. Ułóż interfejs na kawałku papieru lub serwetce, cokolwiek.
4. Spróbuj i ułóż interfejs użytkownika w środowisku programistycznym.
5. Jeśli napotkasz trudności, google, google, google, zadawaj pytania na temat przepełnienia stosu, użyj żywej badzi z zasobów internetowych, aby uzyskać pomoc. Poproś znajomych i współpracowników, którzy są programistami, o pomoc w określonych sytuacjach. Wróć do kroku 4.
6. Zacznij pisać logikę swojej aplikacji. Jeśli napotkasz trudności, przejdź do poprzedniego kroku i spróbuj ponownie.
7. Już niedługo coś będzie działać.

Stwórz coś małego. Nie przejmuj się, że Twój program będzie 1000.

Jakieś pomysły:

• zegar (najpierw cyfrowy, potem analogowy),
• automatyczny twórca labiryntu,
• wyświetlanie struktury katalogów,
• lista albumów mp3,
• itp.

Wybór platformy, narzędzia są częścią zadania.

Ok, zacznijmy od twojego pomysłu na program X, który robi coś pożytecznego i podzielmy to:

• Użyj układu papierowego, mapowania myśli lub oprogramowania do tworzenia diagramów, aby uporządkować logiczny przepływ / przepływy programu.

• Ponieważ dopiero zaczynasz, wybierz JEDEN z tych przedmiotów (najlepiej na początku) i rozbić go jeszcze bardziej.

• Najpierw napisz swój kod i wykorzystaj go, aby na nim budować

Czy program X musi otworzyć plik, manipulować nim i utworzyć plik wyjściowy? Sprawdź, czy możesz otworzyć i powtórzyć plik jako pierwszy krok. Chcesz ładny interfejs użytkownika? Zbuduj taki, który będzie mógł uruchamiać program echa plików itp. Będziesz nie tylko budował kod, którego będziesz mógł używać w swoim złożonym programie krok po kroku, ale także będziesz budował swoją znajomość języka, gdy będziesz musiał wyszukiwać i wyszukiwać informacje.

Jak mówi przysłowie - Gnome nie został zbudowany w jeden dzień :-)

(odpowiedział już powyżej w komentarzach. Sugerowano, aby przesłać to jako odpowiedź po ponownym otwarciu pytania).

Zaczynasz od problemu - czegoś, co chcesz rozwiązać - bez względu na to, jak skomplikowany uważasz. Następnie bierzesz ten problem i zapisujesz go i zaczynasz rozkładać na mniejsze problemy. Następnie załamujesz te mniejsze problemy itp., Aż będziesz mieć coś prymitywnego, który już wiesz, jak rozwiązać lub z pewnym wysiłkiem. Zaczynasz kodować każdy z tych elementów i organizować je w różne funkcje lub różne klasy itp.

Następnie pracujesz nad kolejnym podproblemem. Pracując nad każdym problemem, możesz napisać małe przypadki testowe i zobaczyć, jak postępujesz. Po drodze zawsze będą wyzwania, ale w żadnym momencie nie będzie to postrzegane jako coś zbyt kolosalnego, aby nawet podejść (z tym, co wydaje się teraz mieć do czynienia). Dotyczy to programowania i wielu wyzwań życiowych. Kluczem do sukcesu jest jego zerwanie.

Co do tego, co robić - pomysł. Możesz spróbować wymyślić coś nowego, ale możesz także wziąć coś, co może Cię pasjonować i już istnieje, ale po prostu spraw, aby było lepiej, a nawet inaczej. W wolnym czasie piszę aplikację tunera gitarowego na Androida. Wiem, że istnieje już wiele innych aplikacji do strojenia gitar, ale pomyślałem, że będzie to zabawny i wymagający projekt, więc podjąłem się tego. Na początku wydawało się to prawie niemożliwe, ale po tym, jak złamałem problem na mniejsze kroki, właściwie ładnie się ze sobą łączy. Dziel się, podbijaj i bądź wytrwały w realizacji swoich celów.

Jedną z najtrudniejszych rzeczy dla początkujących jest ustalenie realistycznych celów, które ćwiczenie „jak mogę ulepszyć” powinno zawierać na obecnym poziomie.

Dlatego sugerowałbym, abyś ćwiczył rozwiązywanie małych, zadanych ćwiczeń, ponieważ umiejętność ukończenia programu zgodnie z podaną specyfikacją jest bardzo cenną rzeczą dla każdego, kto programuje na życie.

Proponuję przyjrzeć się bliżej stronie http://projecteuler.net/, która zawiera wiele ćwiczeń i zautomatyzowany system „sprawdzania odpowiedzi”, umożliwiający pracę we własnym tempie. Ćwiczenia są dobrze sformułowane, ale mogą wymagać myślenia. Niektórzy mogą nawet wymagać od ciebie dużo myślenia, ale nawet jeśli ich nie rozwiążesz, nauczy cię czegoś pożytecznego.

Pełne sformułowanie problemu 1 brzmi:

Jeśli podamy wszystkie liczby naturalne poniżej 10, które są wielokrotnościami 3 lub 5, otrzymamy 3, 5, 6 i 9. Suma tych wielokrotności wynosi 23.

Znajdź sumę wszystkich wielokrotności 3 lub 5 poniżej 1000.

Myślisz, że możesz to rozwiązać? Więc zrób to!

Potrzebujesz prawdziwego doświadczenia !! . Żadna książka cię tego nie nauczy!

Musisz nauczyć się czytać inne kody, jak je utrzymywać, jak ich nienawidzić (zarówno kod, jak i koder), jak je ulepszać, jak myśleć, że możesz to zrobić lepiej, a kilka miesięcy później krzyczeć głośno : Zabiję, kto kiedykolwiek napisał ten fragment kodu !!! Tylko po to, by dowiedzieć się w kontroli wersji źródłowej, to byłeś ty!

Musisz zrozumieć, że książki są bardzo specyficzne i czasami dla ludzi, którzy już wiedzą, jak tworzyć oprogramowanie.

Proponuję więc znaleźć pracę programistyczną. W razie potrzeby ubiegaj się o najbardziej podstawowy poziom wejścia. Prawdopodobnie nie zarobisz tyle, ile uważasz, że na to zasługujesz, ale wykorzystaj kilka miesięcy, aby dowiedzieć się, jak oprogramowanie jest tworzone w świecie rzeczywistym (i nie zawsze jest tak idealne i przy wszystkich tych pięknych najlepszych praktykach, które czytamy w Internecie , wielokrotnie jakość kodu jest bardzo niska, w zależności od tego, gdzie pracujesz, ale to część doświadczenia)

Czytaj dalej swoje książki, a przekonasz się, że każdego roku rozumiesz nieco więcej (lub inaczej) ten sam temat, ponieważ możesz to zobaczyć przy lampce doświadczenia.

Jeśli uda ci się znaleźć pracę u utalentowanych programistów, znacznie lepiej. Ucz się od nich, nie bój się popełniać błędów.

Dopóki nie będziesz musiał naprawić pierwszego pilnego błędu produkcyjnego na żywo, nie będziesz wiedział, co to jest błąd oprogramowania!

:)

Wypróbuj projekt open source, sprawdź, czy możesz się zmieścić. Zacznij od pobrania źródła i sprawdź, czy możesz odebrać jakieś bilety

Kiedy chcę nauczyć się nowego języka, zwykle próbuję zaimplementować jakiś graf fraktalny. W ten sposób będziesz mieć natychmiastową informację zwrotną, czy to działa i jest bardzo satysfakcjonujące. Istnieje wiele sposobów na ulepszenie fraktala. Naiwna implementacja mandelbrota jest powolna jak diabli.

Nie jest to zbyt przydatne, ale dużo się uczysz i pięknie się na niego patrzy.

Programowanie polega na rozwiązywaniu problemów i komunikacji, a nie pisaniu dużej ilości kodu. Kod jest po prostu koniecznością, zwykle powinieneś próbować pisać mniej kodu, a nie więcej.

Jeśli nie wiesz od czego zacząć, być może nie masz żadnych problemów!

Spójrz na Linux i inne systemy uniksopodobne: wszystkie składają się z wielu małych aplikacji, które robią tylko jedną rzecz, ale robią to dobrze .

Kiedy potrzebowałem skryptu, aby znaleźć 10 największych plików w folderze na moim komputerze, nie czytałem książek. Właśnie googlowałem i skorzystałem z jednego z istniejących rozwiązań. Czy napisałem jakiś kod? - Nie. Czy problem został rozwiązany? - Tak. Czy ten program jednowierszowy jest przydatny? - Pewnie, ze tak.

Programy zawierające tysiące linii kodu są zwykle pisane przez więcej niż jednego programistę. Nie będziesz mógł pisać samych całych systemów operacyjnych i nie musisz. Często używają także kodów, takich jak kontrola wersji i testy jednostkowe .

Dziel i rządź.

To takie proste lub trudne.

Kiedy zaczynałem programować, uwielbiałem gry komputerowe. Zacząłem więc pisać własne gry, gdy tylko miałem do dyspozycji jakieś narzędzia.

Oczywiście moja pierwsza gra była przygodą tekstową. Podobnie możesz zacząć od quizu, czegoś w rodzaju gry w zgadywanie.

Możesz też zacząć od czegoś takiego jak automat do gier (tak naprawdę nie potrzebujesz animacji, a nawet zdjęć. Wystarczy użyć A = jabłko, L = cytryna, S = start, P = Śliwka itp.).

Nauczy Cię podstaw obsługi niektórych danych wejściowych użytkownika, utrzymywania stanu gry i generowania odpowiednich wyników.

Ruszyłem tą drogą dość daleko. Stopniowo nauczyłem się, jak odczytać stan klawiatury lub myszy, jak korzystać z kodu graficznego. Dowiedziałem się więcej o samym języku (zacząłem od PASCAL) i wykorzystałem to do ulepszenia moich istniejących gier lub właśnie zacząłem coś nowego.

Myślę, że gry są naprawdę świetne do nauki programowania. Nawet przy niewielkim doświadczeniu możesz tworzyć małe rzeczy, które dają ci chwile dumy. Ponieważ coś tworzysz, to zabawne. Budowanie rzeczywistych aplikacji jest dość bezcelowe, ponieważ stworzenie czegoś, co jest naprawdę przydatne, zajmuje dużo pracy, podczas gdy zaskakująco proste jest stworzenie małej gry, która okazuje się uzależniająca.

Możesz rzeczywiście użyć języka edukacyjnego (w moim przypadku był to PASCAL, a retrospektywnie wydaje mi się, że był to całkiem dobry wybór). Wiele z nich ma na celu tworzenie gier i tym podobnych.

Tworzenie aplikacji to coś więcej niż tworzenie algorytmów. Musisz zaprojektować funkcje, musisz uporządkować i ustrukturyzować swój kod na różnych warstwach i modułach. W przeciwieństwie do raczej „atomowych” problemów, które napotykasz na uniwersytecie, aplikacje najlepiej czasem rozwijać w sposób przyrostowy. Zaczynasz od czegoś i dodajesz rzeczy na wierzchu. Zatem mając już coś na początek (tak jak w niektórych językach wymienionych w artykule na Wikipedii), oszczędzasz sobie dużo frustracji i od razu zaczynasz coś tworzyć. (Mój kolega zaczął programować od napisania quake 2 modów). W pewnym momencie odkryjesz ograniczenia tych łatwych w użyciu narzędzi, ale do tego czasu będziesz mieć dużo więcej wglądu i zrozumienia. Prawdopodobnie wystarczy

Na studiach istniała klasa zwana praktyką programowania, która zasadniczo uczyła tej rampy. Na początku otrzymałeś interfejs użytkownika do podstawowej aplikacji zakupowej i musiałeś zakodować backend, ostatni miesiąc to Tetris od zera. Myślę, że około 50% nowych uczniów (nie przystępujących do klasy) poniosło porażkę, ponieważ przechodzenie od małych do dużych jest niezwykle trudne.

Sugerowałbym jedną lub więcej z następujących czynności:

• Pobierz projekt open source i dodaj coś. Nie musi to być przydatne ani dobre, ale musisz spojrzeć na strukturę, która da ci wyobrażenie o tym, jak zbudowany jest duży projekt.

• Wystarczy zaprojektować swój projekt końcowy na papierze, ze strzałkami określającymi zależności. Jeśli robisz węża, możesz mieć głowę węża, ogon węża, jedzenie, pustą przestrzeń, ścianę, tablicę, aktualny kierunek itp. Może ci pomóc, jeśli twój projekt jest znacznie większy, niż myślisz.

• Podejmij podstawowy projekt i powiększ go. Prawdopodobnie zrobisz dużo refaktoryzacji i mam nadzieję, że nauczysz się robić mniejsze projekty, które można łatwo dodać.

• Jeśli znasz kogoś, kto go doświadczył, powiedz mu o swoim projekcie i poproś, aby napisał twoje zajęcia + kilka ważnych metod, prawdopodobnie zajmie to około godziny. W ten sposób możesz po prostu wypełnić metody i zawsze wiedzieć, co musisz zrobić dalej.

Wreszcie, cokolwiek zrobisz, prawdopodobnie powinieneś użyć podstawowego wzorca projektowego MVC (Model, Widok, Kontroler). Bez wchodzenia w szczegóły, umieść widok (UI) w klasach 1+, kontroler (dane wejściowe, wyjściowe itp.) W klasach 1+, a model (Logika, dane, w zasadzie wszystko inne) w kilku klasach. Jest to łatwy sposób na uzyskanie podstawowej organizacji.

Pamiętaj, że ten krok jest trudny. To prawda, że ​​niektórzy ludzie po prostu nie mogą programować, ale prawdopodobnie utknąłeś na tym etapie. Powodzenia!

Po pierwsze, już spełniasz wymagania, biorąc udział w zajęciach, czytając materiały referencyjne, przeglądając projekty open source i pozostając ciekawy pytaniami. Podkreślam to, ponieważ osobiście spotkałem się z podobnymi pytaniami, zanim dana osoba wykonała jakąkolwiek pracę nóg z ich strony (w szczególności osoby omijające zajęcia i mające nadzieję na skróty). Teraz wracam myślami do czasów, kiedy mieliśmy laboratoria na temat maszyn Turinga i tego, jak wtedy czułem, że to nie było prawdziwe programowanie. Są to doświadczenia, których nie zapomnisz.

• Zapisz się na projekty studenckie. Zaangażowałem się w (CSUA) grupę podobnie myślących studentów, aby w ubiegłym roku zbudować grę na stoisku karnawałowym. Jeśli nadal ci się to podoba i myślisz, że chcesz zwiększyć swoje zaangażowanie, naprawdę skorzystaj z zasobów. Dowiedz się o projektach, porozmawiaj z kolegami z klasy, profesorami i stażem.

• Usiądź z doświadczonym programistą. W mojej historii było około trzy razy, kiedy oglądałem program innej osoby, który był naprawdę inspirujący. Dla nich po prostu pisali kod i myśleli na głos. Bez przesady, czułem się, jakbym pochłonął ich słuchanie bardziej niż samemu sobie przez lata. Jeśli spotkasz więcej, jesteś o wiele bogatszy. Mamy szczęście, że jesteśmy w wieku, w którym możemy oglądać filmy, sprawdzać kompletne repozytoria źródłowe i natychmiast przeszukiwać ogromny sklep z wiedzą. Nie zastępuje to osobistego doświadczenia, ale pod nieobecność mentora jest to znacząca poprawa w stosunku do tradycyjnego materiału. Jednak samo patrzenie na surowy kod przez innych może do niczego nie prowadzić. Będziesz chciał mieć coś na myśli i dobry debugger, aby wkroczyć w logikę. Jednym z moich ulubionych momentów było stworzenie modu Quake i to nie sam mod miał coś niezapomnianego. Widział logikę Carmacka w grze. Mod był dla mnie tylko powodem do nurkowania.

• Przećwicz wyjaśnianie i odpowiadanie na pytania postawione przez twojego partnera w laboratorium. Zgłaszaj się na ochotnika, aby pomóc uczyć. Może stwórz grupę analityczną i poproś, aby każdy członek został ekspertem w temacie zajęć. Następnie grilluj tę osobę i pozwól jej grillować ciebie. Kiedy będziesz zmuszony odpowiedzieć na pytania, będziesz zobowiązany do samodzielnego poznania odpowiedzi. Kiedy potrafisz jasno wyjaśnić pojęcia innym, wzbogaciłeś swoje zrozumienie do tego stopnia, że ​​jesteś w stanie przekazać je poza książką i swoimi myślami.

• Na koniec nie bój się uczyć na własnej skórze, brudź sobie ręce, popełniaj błędy. Można to również nazwać doświadczeniem. Jako bardziej praktyczny przykład w odniesieniu do pytania dotyczącego projektów z nieporęczną bazą kodu i dużą liczbą plików, wykonaj następujące ćwiczenie: użyj jednego pliku do swojej pracy. Naprawdę nie żartuję. To samo pytanie pojawiło się w mojej obecnej i poprzedniej firmie. Tutaj inny programista zauważył, że wolę przechowywać jeden plik dla każdej klasy. Wydawało mu się to obce i, w powiązanej sprawie, nie lubił także zajęć częściowych. Tak więc jednym ze sposobów, aby dowiedzieć się, kiedy i gdzie należy podzielić logikę na osobne pliki, byłoby rozpoczęcie od jednego pliku. Po przećwiczeniu reguły jednego pliku w wielu projektach, miejmy nadzieję, że będzie ona coraz bardziej złożona, możesz natknąć się na projekt, w którym masz tak wiele klas w jednym pliku, że masz trudności z czytaniem lub z powodu kontroli wersji staje się trudny do współpracy. W tym momencie chcesz utworzyć osobne pliki, aby pogrupować różne klasy. Biorąc pod uwagę swoje preferencje, możesz wcześnie zdecydować, że podoba Ci się wszystkie klasy danych w jednym pliku. Z drugiej strony, być może później, możesz zdecydować, że lubisz osobne pliki, nawet między klasami danych jako grupą.

Nie musisz mieć świetnego pomysłu, aby zacząć programować. Zacznę od łatwej części. Jak program, którego już używasz. Spróbuj zrobić coś, co już wiesz, jak to działa. Staw czoła swoim problemom, dzięki czemu nauczysz się szybciej. Gdy zdobędziesz więcej doświadczenia, zaczniesz mieć dobre pomysły na programy, które ułatwią Ci życie podczas programowania, lub po prostu dobry program do robienia czegoś, o czym nigdy wcześniej nie pomyślałeś. Programuję Javę od prawie roku, a inne języki od kilku lat. Zajęło mi trochę czasu, aby zacząć robić to, co naprawdę chciałem zrobić. Właśnie zacząłem robić własne rzeczy. Dzięki StackOverflow. Nie wiedziałem o tym wcześniej.

Jest więc mnóstwo odpowiedzi, więc wybacz mi, jeśli powtórzę wiele z tego, co już powiedziano, ale oto moje 2 centy.

Najpierw wybierz pomysł. Każdy pomysł będzie w porządku, coś prostego prawdopodobnie byłoby lepsze niż duże. Zakres projektów bardzo szybko rośnie (niektórzy nazywają to pełzaniem).

Następnie zrób szkielet projektu. Będzie to wymagało odrobiny wiedzy o architekturze i projektowaniu i prawdopodobnie pomylisz się przy pierwszych dziesięciu próbach - zrobiłem. Po prostu ułóż porządną strukturę plików i być może mały szkielet kodu, który pokazuje ważne części systemu.

Uratuj szkielet w swoim VCS (wybierz z niego swoją truciznę i poczekaj, aż doprowadzi to do świętej wojny). Gdy zaczniesz używać VCS, ciągłe używanie go do drobnych zmian staje się drugą naturą, ale pamiętaj, aby zacząć.

Teraz wybierz małą, ale ważną funkcję dla systemu i zrób to. Nie martw się o to, aby upewnić się, że wszystko jest idealnie zamknięte i że ma „najlepszy” projekt (który będzie ewoluował wraz z systemem). Po prostu zdobądź coś, co zadziała. Otrzymanie również niektórych testów jednostkowych pomoże upewnić się, że wiesz, co się stało, gdy coś się psuje, jeśli przeprowadzasz testy regularnie.

Zbuduj swój system. Byłby to również dobry czas na uzyskanie automatycznego systemu kompilacji i ciągłej integracji. Jeśli nie wiesz, czym one są, albo naucz się tego i spróbuj, albo po prostu kontynuuj na własne ryzyko; tak czy inaczej, działaj dalej.

Teraz wybierz inną funkcję i powtórz i powtórz i powtórz.

Gdy pomyślisz, że działa dobrze, pokaż to znajomemu. Przyjaciel nie musi wiedzieć, jak programować, ani nawet wiedzieć, co robi program. Ten, w którym będziesz czuć się dobrze, pokazując komuś, a dwa pomogą ci dokładnie wiedzieć, co robi system.

Jeśli dojdziesz do punktu, w którym jesteś bardzo pewny, co zrobiłeś, wypuść go online i spróbuj uzyskać opinie. Centrum repozytorium lub podprogram redakcyjny programistów może dać ci konstruktywną krytykę. Spróbuj znaleźć profesora CS / SE i popatrz na niego. Może zapytaj profesjonalnego programistę. Po prostu uzyskaj opinię innego programisty.

Po zakończeniu (lub prawdopodobnie wcześniej) zdasz sobie sprawę, że kod, który napisałeś na początku, jest znacznie gorszy niż ten, który napisałeś ostatnio. To jest całkowicie naturalne i przytrafia się nam wszystkim. Teraz musisz znaleźć nowy projekt i nauczyć się czegoś nowego - być może nowej strategii testowania lub korzystania z architektury zorientowanej na usługi.

Coś, co może pomóc, to pomyśleć o prostym problemie, który masz na co dzień, w którym coś, co możesz zrobić ołówkiem i papierem, można zastąpić programem.

Daje to stosunkowo prosty problem z dość znanym rozwiązaniem, które wymaga jedynie poziomu automatyzacji. Pamiętaj, że nie musi to być następny MS Word / WordPad / NotePad; tylko coś, co rozwiązuje (prosty) problem.

Na przykład problemem, który ciągle wdrażam podczas pracy z nowym językiem, jest prosta aplikacja mierząca czas. Aplikacja służy do śledzenia rozliczanych godzin do różnych projektów w ciągu dnia. Dość prosty program z mnóstwem małych problemów, takich jak sposób przeprowadzania restartów w środku dnia lub dodawanie / usuwanie elementów z listy.

Myślę, że część problemu polega na tym, że kiedy czytasz książki o programowaniu, one po prostu uczą cię języka. Nie wspominają, że aby zaprogramować prawie wszystko, potrzebujesz dostępu do programowania BIBLIOTEK i SDKS itp. Znajomość języka niestety nie wystarczy.

Wydaje mi się, że twój problem wynika z: 1. konfliktu między teorią a praktyką, a także tego, że ... 3. nie możesz kodować czegoś, jeśli nie masz pojęcia, co możesz zrobić. 4. Znasz połowę trudności

1. Znajomość języka teoretycznie nie oznacza, że ​​go „mówisz”: to różnica między czytaniem angielskiego a mówieniem nim. Również duża liczba różnych narzędzi dostępnych do kompilowania, linkowania, edytowania kodu źródłowego sprawi, że zaczniesz kręcić głową.

2. kiedy uczysz się programować, najbardziej, jeśli terminal jest używany do wprowadzania / wyprowadzania tekstu, ponieważ jest to najprostszy sposób radzenia sobie z programowaniem. W rzeczywistości programiści używają bibliotek (takich jak Qt), frameworków (jak sądzę django) i innych kodów skrótów, aby być produktywnymi. Oczywiście, jeśli uważasz, że możesz napisać własne koło, nie wymyślaj go na nowo i czytaj książki o projektowaniu kompilatora i jądra: jest wiele do nauczenia się w tym: może uważasz, że głupota jest dezaktualizować aplikacje, które nie wymagają wiele techniki.

3. Wynaleźć coś ! Oczywiście możesz zrobić edytor tekstu, grę itp. Chodzi o to, że nie zrobisz tego, jeśli nie widzisz żadnego powodu: te programy będą dla ciebie bezużyteczne, jeśli wszystko, o czym myślisz, zostało już zrobione . Osobiście wciąż marzę, aby móc kodować zdalnie scentralizowany protokół p2p na Facebooku za pomocą czatu, wiadomości offline itp. W jednym, aby można go było używać z urządzeniami bezprzewodowymi. Internet daje wiele możliwości, nie zapomnij o tym pomyśleć.

4. W rzeczywistości teoria jest niezbędna do ćwiczenia, ale to nie wszystko: algorytmy i techniki nie są częścią teorii programowania, istnieje wiele paradygmatów i inny „standardowy” sposób tworzenia kodu: wzorce projektowe, listy połączone, itd itd.

Może mógłbyś wybrać język skryptowy na początek. Zacząłem programować w języku C. Moim zdaniem język C jest łatwy do rozpoczęcia, ale potrzeba dużo więcej czasu, aby poznać algorytm i coś o systemie operacyjnym. I za każdym razem, gdy ćwiczę, jest po prostu z graficznym interfejsem DOS, co wprawia mnie w depresję.

Później wybrałem język skryptowy o nazwie ActionScript. Język skryptowy jest językiem obiektowym i może kontrolować zachowanie filmu Flash. Język skryptowy jest łatwy do wykonania pracy zbliżonej do domeny problemowej , tak jak trace("HelloWorld")w ActionScript, aby wygenerować ciąg znaków. I ma potężne IDE, które pozwala sprawdzić, czy twój program działa dobrze.

Jednym słowem, jeśli chcesz rozpocząć programowanie w szybki sposób powstaje język skryptowy może być dobry wybór :-)

Napisz specyfikację. Co chcesz zrobić w swoim programie? Ekrany (jeśli jest to program oparty na interfejsie użytkownika) logika, dane wejściowe / wyjściowe itp. Ogranicz zakres do tego, co możesz zrobić w rozsądnym czasie (jeden tydzień? Jeden miesiąc?).

Następnie zbuduj to. Trzymaj się specyfikacji, spraw, aby działała zgodnie z wymaganiami specyfikacji. Na pewno natkniesz się na rozrywkę, na pewno będziesz musiał przeprowadzić badania, ponieważ nigdy wcześniej nie napotkałeś żadnego konkretnego problemu, ale zbudujesz coś, co chciałeś zbudować. Różni się to od budowania czegoś, co można po prostu „zbudować”.

Po zakończeniu przebuduj kod, spróbuj zwiększyć jego wydajność. Następnie, jeśli uważasz, że twój program nadal nie jest gotowy, zacznij od nowa, popraw specyfikację, popraw kod i kontynuuj to.

Pamiętaj, że większość komercyjnych programów rozwiązuje potrzebę. Bardzo ważne jest zdefiniowanie potrzeby i rozwiązanie tej potrzeby przed faktycznym rozwiązaniem problemu. A wraz ze wzrostem potrzeby Twoje oprogramowanie będzie rosło z czasem!