Jakie * są * koncepcje programowania, które powinienem opanować, aby mieć głębokie zrozumienie mojego rzemiosła (programowania)? [Zamknięte]


13

W kolejności ważności, jeśli jest to możliwe, a może nie być, jakie są najważniejsze podstawy umiejętności programowania. Algorytmy, iteracja, rekurencja itp.?

Zwróć uwagę, że to, gdzie umieszczam itp., Jest moim pytaniem. Niedawno przeczytałem post internetowy, w którym napisano, że 9 na 10 programistów nie może wstrzymać programu!

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Chcę mieć głęboką wiedzę na temat tego, co tak naprawdę staram się osiągnąć podczas programowania, oraz wyczerpujące zrozumienie podstawowych narzędzi, którymi dysponuję. Zasadniczo chcę być w stanie malować wszystkimi kolorami wiatru.


3
Wpis Jeffa Atwooda nie dotyczy tak naprawdę głębokiej wiedzy programistycznej ... Chodzi o rzeczywistość, w której wielu ludziom brakuje podstawowych, podstawowych spostrzeżeń na temat programowania oraz tego, jak brak tych podstawowych spostrzeżeń uniemożliwia im rozwinięcie znaczących umiejętności programowania.
Robert Harvey

2
Nie rozumiem, dlaczego to pytanie zostało zamknięte. To pytanie zostało 5 razy oznaczone gwiazdką i zawiera wiele pomocnych odpowiedzi. Jest to rodzaj informacji, na którą chcę się natknąć - tylko dlatego, że nie ma prostej odpowiedzi, nie oznacza, że ​​informacja nie ma dobrej wartości, być może programiści.stackexchange.com musi ponownie ocenić swoje kryteria zamykania pytań.
Rocklan

@LachlanB Głosowałem, aby ponownie otworzyć ... potrzebuje 4 dodatkowych głosów, aby odnieść sukces
Michael Brown

Myślę, że to dobre pytanie, ale jakakolwiek rozsądna odpowiedź będzie zbyt długa dla formatu tej strony. Każdy dobry program uniwersytecki obejmie te koncepcje, a fakt, że taki program zajmuje kilka lat poświęconych na naukę i praktykę, a następnie dodatkowe lata pracy nad prawdziwymi projektami, powinien wyjaśnić, dlaczego odpowiedź nie pasuje tutaj.
Giorgio

Odpowiedzi:


18

Ta lista to początek ... zadajesz wielkie pytanie!

  • Jak wyjaśnić i zapisać, czego oczekują klienci („wymagania”). To jest sztuka sama w sobie. Jeśli możesz to zrobić, Twoje zadanie programistyczne będzie znacznie lepsze.
  • Jak oszacować i zaplanować projekt. Ludzie będą prosić o wycenę, bądź przygotowany.
  • Jak konstruktywnie przejrzeć kod innych osób.
  • Wzorce projektowe. Ten jest duży. Ale nie używaj ich nadmiernie ze względu na to.
  • Poznaj różnicę między żądaniami błędów, problemów i funkcji
  • Bądź na bieżąco z frameworkami / bibliotekami. Nie musisz ich używać, ale musisz wiedzieć, co robią i jakie są ich zalety / wady. Jeśli coś wydaje się zbyt trudne, prawdopodobnie (prawdopodobnie) istnieje znacznie łatwiejszy sposób robienia rzeczy.
  • Jak udokumentować skomplikowane algorytmy na schemacie blokowym lub po prostu napisać je po angielsku. Nie spodziewaj się, że ktoś spędzi 2 dni próbując odtworzyć kod.
  • Jak zorganizować strukturę kodu, aby każdy mógł go zrozumieć
  • Jak skomentować swój kod
  • Jak pisać testy jednostkowe
  • Dowiedz się, co się dzieje pod maską. Np. Dzwonienie do serwisu internetowego - co on właściwie robi?
  • Jak wydzielić logikę na klasy.
  • Jak refaktoryzować kod
  • Poznaj istotę kilku języków programowania. Byłbyś zaskoczony, czego możesz nauczyć się z innych dziedzin
  • Jak powiedzieć innym programistom, co mają napisać.
  • Jak wyjaśnić kierownictwu, co robisz i dlaczego.
  • Jak powiedział Peter, jak debugować. Zgadzam się ze wszystkim, co mówi, prawdziwi programiści debugują, nie tylko zgadują.
  • Jak pracować z maniakami. Tam jest ich dużo.
  • Jak ZROBIĆ STUFF. Cała teoria na świecie nie pomoże ci, jeśli nie możesz zrobić rzeczy.

Odpowiedziałem na inne pytanie o podobnej treści (o podobnej treści) tutaj:

wskazówki, wytyczne, punkty do zapamiętania przy renderowaniu profesjonalnego kodu?


1
+1: ZRÓB STUFF! Kilka lat temu opublikowałem zdanie, które mówiło, że to była cecha charakterystyczna inżyniera - robią wszystko. Czasami to nie jest ładne, a czasem będziesz musiał wrócić i powtórzyć, ale pod koniec dnia robią rzeczy!
Peter Rowell,

@PeterRowell: może Cię to zainteresować: brandonsavage.net/when-to-write-bad-code
Marjan Venema

Niestety, pytanie nie jest tak naprawdę zgodne z filozofią pytań i odpowiedzi oraz formatem strony, ale nie minimalizuje to wartości twojej odpowiedzi. Jeśli zechcesz go rozwinąć i dodać trochę wyjaśnień do każdego punktu, będzie to świetny post na naszym blogu społecznościowym .
yannis

@MarjanVenema: Tak, całkowicie się z nim zgadzam. W latach 80-tych miałem za zadanie napisać specyfikację dla nowego edytora, która ma zostać zatwierdzona przed rozpoczęciem kodowania. Przez ponad tydzień wpatrywałem się w ten cholerny pusty ekran, próbując wymyślić, jak opisać coś, czego nie rozumiem. Mój kierownik wyraził niezadowolenie z mojego braku postępów. Po 3-dniowym weekendie miał przeciąg na biurku. Zapytał, co się stało, a ja powiedziałem, że napisałem edytor w weekend, a potem po prostu napisałem specyfikację tego, co miałem do pracy. Przepisałem trochę kodu, ale był to głównie refaktor / czyszczenie.
Peter Rowell,

1
@YannisRizos - Chciałbym napisać blog na ten temat. Czy chcesz mi wysłać e-mail z wszelkimi wytycznymi, czy powinienem coś napisać?
Rocklan

22

Pod nagłówkiem „ itp. ” Znajduje się coś, co z łatwością może zająć 50% lub więcej czasu.

Dowiedz się, jak debugować.

Oznacza to naukę metody naukowej . Mam na myśli naprawdę się go uczyć. A potem stosuję go z brutalną uczciwością . Naucz się, jak dokładnie określać, co wiesz, że jest prawdą, co wiesz, że nie jest prawdą, i te rzeczy, których nie znasz. Za każdym razem, niechlujnie przypisać element do niewłaściwej kategorii, właśnie się twoje życie dużo trudniejsze.

Naucz się mówić „myślę” zamiast „wiem”. Możesz powiedzieć „wiem” tylko wtedy, gdy „myślisz”, że coś jest prawdą (lub fałszem), a potem to udowodnisz!

Wiele błędów jest trywialnych, ale mogą być trudne do zobaczenia, ponieważ „wiesz”, jaki powinien być kod ... z wyjątkiem tego, że nie. Znajdź przyjaciela, aby to wyjaśnić. Poproś ich, aby byli „ekspertem idioty”: kimś, kto nie zna twojego kodu, ale kogo wiesz, że nie możesz zdmuchnąć BS. Nie zdziw się, jeśli w trakcie opisywania ich nagle zatrzymasz się i powiesz: „abyś mógł ... zobaczyć ... zobaczyć to ... cholera. Dzięki.”

Nietrywialne błędy wymagają arsenału technik. Klasykiem, który może szybko wykryć większość błędów niezwiązanych z czasem, jest Wolf Fence na Alasce. Gdzieś na Alasce jest wilk; zbuduj ogrodzenie przecinając państwo na pół. Po której stronie jest wilk? Przetnij tę stronę na pół. Spłucz, spłucz, powtórz. Wykonanie tego 20 razy w dobrze wybranych miejscach w kodzie zmniejsza obszar, w którym błąd (wilk) może wynosić do 1/1048576. Zabij tego wilka.

Wskazówka: szukaj fal ręcznych - fizycznych, umysłowych lub innego rodzaju. Gdy tylko Ty (lub Twój kolega) wzdrygniesz się / przekierujesz / zminimalizujesz uwagę poświęconą części kodu, idź całkowicie wściekły . Ponieważ obszar, w którym po prostu znasz błąd, nie może istnieć, mimo że spędziłeś godziny / dni na szukaniu d * mn i wciąż nie możesz go znaleźć ... to jest największe prawdopodobieństwo błędu. Nikt nie dostaje „do widzenia” , nikt (w tym maszyna, system operacyjny, kompilator lub ty ) nie otrzymuje żadnego „należnego szacunku”. Jest błąd. Kropka. Koniec zdania. A teraz idź zabij to d * mn.

Nie znam żadnej szkoły, która sama uczy debugowania. IMNSHO, może to być jeden z najbardziej rażących dowodów na to, że oni (uniwersytety / profesorowie) nie uczą cię bycia programistą, zamiast tego uczą cię bycia ... takim jak oni? Szorstki? Być może. Prawdziwe? Zdecyduj się. Teraz to udowodnij.


Możesz być zainteresowany Saff Squeeze , techniką opisaną przez Kent Beck, która wykorzystuje testy i refaktoryzację do debugowania: Hit 'em High, Hit' em Low : Test regresji i Saff Squeeze przez Kent Beck, Three Rivers Institute (streszczenie: To skutecznie izoluj defekt, zacznij od testu na poziomie systemu i stopniowo dołączaj i przycinaj, aż uzyskasz możliwie najmniejszy test, który wykaże defekt.) Brzmi bardzo podobnie do twojego Wolf Fence, przy użyciu Testów i możliwości Refaktoryzacji IDE.
Jörg W Mittag

1
Świetna odpowiedź - każdy może pisać kod, debugują prawdziwi programiści.
Rocklan

@ JörgWMittag: Jestem wielkim fanem automatycznych testów regresji. Po raz pierwszy użyłem go w projekcie wyszukiwarki w połowie lat 80-tych i byłem zszokowany (zszokowany) rzeczami, które wypadłyby po czymś, co wydawało się „drobną” zmianą w jakiś niewinnie wyglądający fragment kodu. (Uwaga: było to ponad 200 000 SLOC C, a problemy z zarządzaniem pamięcią były zmorą naszego istnienia).
Peter Rowell,

3

Obawiam się, że jest to dość duże pytanie, na które każdy może udzielić jednoznacznej lub autorytatywnej odpowiedzi, szczególnie biorąc pod uwagę, że chcesz mieć listę priorytetową. Jest wielu programistów, którzy pracują nad bardzo różnymi rzeczami - jasne, podstawy pozostają takie same, ale to, czego potrzebujesz, aby zachować aktywność w pamięci, może być naprawdę różne i rzeczywiście jest wiele zadań, w których możesz pozostać ładnym wysoki poziom bez wchodzenia głębiej.

Wygląda jednak na to, że naprawdę martwisz się tym, jak być lepszym programistą, a nie tylko jednym oszustem. Uważam to za godne podziwu i mogę podzielić się niektórymi rzeczami, które pomogły mi nauczyć się programować.

Niemal całe programowanie sprowadza się do algorytmów i struktur danych. Są one z kolei przykładami większego pytania - w jaki sposób modelujemy rzeczy i procesy ze świata rzeczywistego w taki sposób, aby komputer mógł je zrozumieć. Jeśli dopiero zaczynasz, przydatne może być użycie języka programowania wyższego poziomu (takiego jak Java, Python itp.), Aby zapoznać się z implementacją struktur danych i algorytmów.

W pewnym momencie, po zabawie ze strukturami danych i algorytmami, możesz zacząć zadawać to dręczące pytanie „ale jak przejść od mówienia komputerowi, co ma robić, do komputera, który to robi?”. Następnie możesz sprawdzić, jak komputer faktycznie oblicza - jak pamięć i procesor współpracują ze sobą w celu wykonania instrukcji, jak systemy operacyjne abstrakują sprzęt, aby można było napisać program, który, powiedzmy, otwiera plik, bez kodowania do określonego niskiego poziomu interfejs dysku twardego.

Jest to prawdopodobnie dobry moment na rozpoczęcie - w jaki sposób algorytmy i struktury danych modelują problemy z rzeczywistego świata i jak komputer faktycznie wykonuje obliczenia. Znajomość tego ostatniego jest bardzo przydatna w opanowaniu języków niższego poziomu, takich jak C, które wykorzystują znacznie mniej dymu i kopii lustrzanych niż języki OO i języki skryptowe :)


2

YAGNI : „Zawsze wdrażaj rzeczy, kiedy naprawdę ich potrzebujesz, nigdy, gdy tylko przewidujesz, że ich potrzebujesz”.

Z mojego doświadczenia wynika, że ​​„programiści” często przewidują wiele przypadków w przyszłości i próbują „ulepszyć” kod, dodając kody, aby je przewidzieć! W większości przypadków dodany przez nich kod po prostu powoduje jego rozdęcie i zwiększa złożoność kodu.


1

Najważniejszą rzeczą, którą należy wiedzieć o byciu programistą, jest to, że pisanie kodu jest grindem, a robotnicze podejście „niebieskiego kołnierza” do produkowania tego, za co otrzymujesz wynagrodzenie, prowadzi cię dalej niż jakiekolwiek ezoteryczne nauki.

Naucz się dostać do strefy. Rozumiem przez to stan psychiczny, kiedy koncentrujesz się tylko na swoim zadaniu i możesz zacząć trzymać w głowie wiele rzeczy i to, jak one współdziałają jednocześnie. Kiedy będziesz miał zwyczaj wchodzenia do strefy do woli, zacznij się martwić resztą. Dopóki nie będziesz w stanie wydobyć kodu jak jakiegoś kodu wybijającego coś, reszta jest praktycznie bezużyteczna.

EDYTOWAĆ:

Jeśli w to nie wierzysz i zlekceważyłeś mnie, uważam, że nie wiesz, czy masz na to ochotę przez 20 lat. Wiem, że tak, ponieważ to akceptuję. ;)


0

Ostatnie pytanie, w jakiś sposób powiązane z tym, i Odpowiedź zawiera link do tego bloga, który omawia ten sam problem z innej perspektywy.

Prawdopodobnie najważniejszą koncepcją dla każdego dewelopera jest „pokora” ... Gdy zaakceptujesz, nie wiesz wszystkiego, jesteś otwarty na poszukiwanie rozwiązań. Większość ludzi, którzy piszą blogi o programowaniu, są w najwyższym percentylu, a problemem jest to, że wielu musi jeszcze kontrolować swoje narcystyczne tendencje ... dlatego blogują ... Musisz nauczyć się rozpoznawać tych blogerów i zignorujcie tam ranty

Powiązany blog jest naprawdę niczym innym, jak tylko rantem - w każdej branży narzekanie na to, że niedawni absolwenci są bezużyteczni, jest powszechne, że potrzeba wielu lat, aby stały się użyteczne i produktywne. Być może problemem jest to, że ci samozwańczy guru faktycznie oczekują zbyt wiele i zapomnieli, że kiedyś nie byliby w stanie rozwiązać FizzBuzz. Nie każdy może być w pierwszej dziesiątce, z definicji połowa programistów jest poniżej średniej ......


Zgadzam się, że ludzie dużo gadają, ale myślę, że celem postów, które podłączyłeś powyżej, jest to, że ludzie, którzy nie wiedzieli, jak rozwiązać FizzBuzz, starali się o pracę programistyczną , co różni się od bycia początkującym i potrzebującym twoja głowa wokół programowania idiomów. Zgadzam się jednak z tobą co do pokory i wydaje się, że wielu ludzi nie wie, co to jest.
RuslanD
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.