Co każdy programista powinien wiedzieć o programowaniu?

52

Proszę pozostać w kwestiach technicznych , unikać zachowań, problemów kulturowych, zawodowych lub politycznych.

experience  self-improvement  programming-practices 
— bigown
źródło
7
— pramodc84
Takie pytanie naprawdę mnie denerwuje. Może wypłynąć z umysłu kogoś, kto widzi świat w kategoriach czarno-białych. Nie każdy programista ma tę samą pracę i jeśli jest to najmniejszy wspólny mianownik, którego szukasz, poniższe odpowiedzi pokazują, że po prostu kończy się lista zwierząt domowych.
— Captain Sensible

Odpowiedzi:

92

  1. Błąd jest w swoim kodzie, a nie kompilator lub bibliotek uruchomieniowych.

  2. Jeśli zobaczysz błąd, który nie może się zdarzyć, sprawdź, czy poprawnie zbudowałeś i wdrożyłeś swój program. (Zwłaszcza jeśli używasz skomplikowanego środowiska IDE lub kompilacji, która próbuje ukryć przed tobą bałagan, lub jeśli twoja kompilacja wymaga wielu ręcznych kroków.)

  3. Programy współbieżne / wielowątkowe są trudne do napisania i trudniejsze do prawidłowego przetestowania. Najlepiej przekazać jak najwięcej do bibliotek współbieżnych i struktur.

  4. Pisanie dokumentacji jest częścią pracy programisty. Nie zostawiaj tego dla „kogoś innego”.

EDYTOWAĆ

Tak, mój punkt 1 jest zawyżony. Nawet najlepiej zaprojektowane platformy aplikacji mają swój udział w błędach, a niektóre z mniej dobrze zaprojektowanych platform są z nimi związane. Ale nawet tak, należy zawsze podejrzewać, kod najpierw , a dopiero zaczynają obwiniać błędów / bibliotek kompilatora kiedy masz wyraźne dowody, że kod nie ponosi winy.

W czasach, gdy tworzyłem C / C ++, pamiętam przypadki, w których rzekome „błędy” optymalizatora okazały się być spowodowane tym, że ja / jakiś inny programista zrobił rzeczy, które według specyfikacji językowej miały nieokreślone wyniki. Dotyczy to nawet rzekomo bezpiecznych języków, takich jak Java; np. rzuć okiem na model pamięci Java (rozdział 17 JLS).

— Stephen C.
źródło
17
Wolę powiedzieć: „Błąd jest prawdopodobnie w twoim kodzie”, ponieważ kilka razy natrafiłem na błędy w bibliotekach wykonawczych. Jednak jeszcze nie natknąłem się na błąd kompilatora. W każdym razie +1.
— Chinmay Kanchi,
29
Jeśli nigdy nie znalazłeś bona fide błędu w kompilatorze, nie jesteś wystarczająco ryzykowny z kodowaniem. ;)
— Mason Wheeler,
8
@Chinmay, @ spudd86, @Mason - tak ... i znalazłem również swój udział w kompilatorach i błędach bibliotecznych przez ponad 30 lat programowania. Ale z mojego doświadczenia wynika, że ​​ponad 99% błędów jest (przynajmniej częściowo) wina mojego kodu. Moja odpowiedź celowo przecenia to, aby dojść do wniosku, że zawsze powinieneś podejrzewać swój kod jako pierwszy.
— Stephen C
5
Nie odczuwam irracjonalnego strachu, jaki ludzie odczuwają przy programowaniu wielowątkowym. Podejrzewam, że ludzie, którzy utrwalają ten pogląd, nie programują wiele wielowątkowego kodu. To po prostu nie takie trudne. +1 za wszystko inne.
— Steven Evers,
4
Jeśli pracujesz na kompilatorze, błąd prawdopodobnie znajduje się zarówno w kodzie, jak i kompilatorze;)
— Legooolas
84
  • Jak czytać kod innych osób.
  • Kod nie istnieje, jeśli nie jest sprawdzany w systemie kontroli wersji.
— pramodc84
źródło
8
+10000 gdybym mógł za komentarz kontroli wersji. Rejestrowanie historii i zmian jest absolutnie niezbędne i dlatego powinieneś wszystko od początku kontrolować.
— Legooolas,
2
... a repozytorium zostało zsynchronizowane z co najmniej jedną inną lokalizacją. Ważne z DVCS, ale także ze scentralizowanym VCS.
W tym przypadku kod nie istnieje, chyba że istnieje element pracy, który upoważnia programistę do napisania go.
— Jesse C. Slicer,
2
Dodam jeden za naukę czytania kodu innych osób. To trudniejsze niż większość z nas zdaje sobie sprawę, ale jest to niezbędny element udanego programowania.
— bogeymin
plus jeden do nauki czytania kodu innych osób.
— itsaboutcode
76

Obliczenia zmiennoprzecinkowe nie są precyzyjne.

— Chinmay Kanchi
źródło
22
— Adam Paynter
Jeśli ktoś nie wie o czym mówię, przeczytaj link @ Adama. To doskonałe podsumowanie pułapek obliczeń zmiennoprzecinkowych.
— Chinmay Kanchi,
1
A jeśli nie wiedzą, mogą należeć do grona osób, które codziennie pytają o przepełnienie stosu.
— Brian R. Bondy
1
@Brian: Tak prawda. Chciałbym, aby istniał sposób na identyfikację pytań wyjaśnionych przez arytmetykę zmiennoprzecinkową. Możesz stworzyć aplikację stosu, która wyświetla codziennie inne pytanie zmiennoprzecinkowe!
— Adam Paynter,
63

Nie przestawaj się uczyć.

— systempuntoout
źródło
1
Powiązane: Nie przestawaj wierzyć.
— Fishtoaster,
3
Powiązane: Nie przestawaj myśleć o jutrze.
— ocodo
7
Powiązane: Nie zatrzymuj muzyki.
— adamk
1
Powiązane: Nie przestawaj się ruszać! To twoje życie, ruszaj się, rób to dobrze, musisz mieć rację!
— ocodo
44

Najważniejszą rzeczą, którą możesz zrobić, aby poprawić jakość i łatwość konserwacji kodu, jest ZMNIEJSZENIE POWIELANIA.

— Chris Holmes
źródło
4
OSUSZANIE, tak! Jak mogę zapomnieć? ;-)
— Maniero
To bardzo ważne, że odpowiedziałem ponownie .
Wolę powiedzieć: ZMNIEJSZ WARUNKI. Za każdym razem, gdy / if / for jest potencjalnym błędem.
— zvrba
1
Wiesz, zabawne jest to, że DRY powtarza się wszędzie. :) +1
— Billy ONeal 16.01.11
39

Rozwiązywanie problemów i umiejętności debugowania

Prawie nie spędzają czasu na tym temacie na żadnym kursie programistycznym, który wziąłem, i z mojego doświadczenia jest to jeden z największych wyznaczników wydajności programisty. Czy ci się to podoba, czy nie, spędzasz o wiele więcej czasu w fazie konserwacji aplikacji niż w nowej fazie programowania.

Współpracowałem z bardzo wieloma programistami, którzy debugują przez losowe zmienianie rzeczy bez strategii znalezienia problemu. Rozmawiałem kilkadziesiąt razy.

Inny programista: Myślę, że powinniśmy spróbować sprawdzić, czy to naprawia.
Ja: OK, zakładając, że to naprawia. Co to mówi o tym, gdzie jest źródło problemu?
Inne Programator: Nie wiem, ale musimy spróbować czegoś .

— JohnFx
źródło
2
Już miałem to opublikować. Tyle pracy programisty polega na naprawianiu błędów, a wiele osób jest niezdolnych do tego (szczególnie w kodzie innych).
— Dow
+1 Przeszedłem z javascript / php do C # i zakochałem się w przechodzeniu przez kod. Chciałbym, aby dynamicznie pisane języki lepiej sobie z tym poradziły.
— Evan Plaice,
Innym dziwnym zachowaniem jest programista, który nalega, aby każda część jego programu była poprawna, a wynik - jeśli jest wadliwy. „-Nie musisz drukować tablicy na konsoli, aby sprawdzić, czy jest posortowana, ponieważ powyższa linia to array.sort ().” „-Cóż ... wiesz, to nie działa. Coś musi być nie tak. W tym momencie nie możesz po prostu bronić swojego kodu!”
— gawi
2
Myślę, że sens debugowania, aby zweryfikować swoje założenia w całym programie. Czasami musisz poszukać wskazówek. Trzeba to robić systematycznie. Wypróbowanie czegoś, co może ci powiedzieć coś nowego, jest całkowicie poprawne . Robię to często.
— gawi
37
  1. Nie bądź mądry; bądź jasny.
  2. Użyj przed ponownym użyciem.
  3. Nazwy mają znaczenie.
  4. Funkcja robi 1 rzecz i robi to dobrze.
  5. Małe jest lepsze niż duże.
— KevBurnsJr
źródło
2
Czy możesz wyjaśnić „Użyj przed ponownym użyciem”. Nie słyszałem tego wcześniej.
— Tjaart
34

Podstawy. Obecnie programiści uczą się technologii, a nie pojęć. To jest źle.

— grudki
źródło
Tak i nie. Brzmisz jak każdy profesor, którego kiedykolwiek miałem na uniwersytecie ... wszyscy oni nigdy nie zrobili oprogramowania przez całe życie. Wiedza bez umiejętności jest bezużyteczna w naszym zawodzie.
— Steven Evers,
4
+1, więc prawda. Tak, to jest coś, co lubią mówić wieże z kości słoniowej, ale nie czyni to mniej prawdziwym dla reszty z nas w okopach.
— MAK
2
Podstawy jak pisownia? Its wrongpowinno być it's wrongna przykład.
— Konerak
2
Nie, podstawom jak nie obchodzi literówka, ale problemy programistyczne.
— clrod
5
Łatwo jest nauczyć się kroków, aby coś zrobić i często trudno jest ustalić, kiedy należy go użyć, a co ważniejsze, kiedy można go użyć, ale nie należy. Podręczniki są szczególnie kiepskie w pokazywaniu, jak, ale nie dlaczego (i dlaczego nie).
— HLGEM
27

Każdy programista powinien wiedzieć, że cały czas stawia założenia w kodzie, np. „Ta liczba będzie dodatnia i skończona”, „ten kod będzie mógł połączyć się z serwerem przez cały czas w mgnieniu oka”.

I powinien wiedzieć, że powinien się przygotować na załamanie się tych założeń.

— LennyProgrammers
źródło
6
konkretnie określ tych z assert()- wszędzie. assert()pomoże ci udokumentować twoje założenia i uratować cię, gdy się pomylisz.
— Dustin
@Dustin +1 Nie ma mowy, żebyś po prostu zapamiętał wszystkie swoje założenia - dokumentuj je programowo, a dowiesz się dokładnie, kiedy okażą się one błędnymi założeniami.
— Skilldrick
1
... chyba że skompilowane z NDEBUG.
17

Naucz się pojęć . Możesz Google składnię.

— pramodc84
źródło
Dobra w teorii, z tym wyjątkiem, że Google nie potrafi znaleźć konkretnej składni: wyszukiwanie terminów takich jak „odwołanie do obiektu” lub „to”, biorąc pod uwagę wyniki gazillionu, i wyszukiwanie wyrażeń takich jak „$?” nie dają żadnych wyników.
— l0b0
14

Testów jednostkowych. To świetny sposób na skodyfikowanie założeń dotyczących sposobu użycia kodu.

— btlog
źródło
13

To trudniejsze niż myślisz.

Choć łatwo jest (ish) złożyć coś, co działa, gdy jest używane normalnie, radzenie sobie z błędnymi danymi wejściowymi, wszystkimi przypadkami krawędzi i narożników, możliwymi trybami awarii itp. Jest czasochłonne i prawdopodobnie będzie najtrudniejszą częścią pracy.

Następnie musisz sprawić, by aplikacja również wyglądała dobrze.

— ChrisF
źródło
3
myślę, że jest to źródło starego powiedzenia „90% pracy zajmuje 90% czasu. ostatnie 10% zajmuje pozostałe 90% czasu ”
— GSto
Myślę, że wiele osób konsekwentnie nie docenia złożoności. „Jak twardy może być X?” - słynne ostatnie słowa: /
— Roman Starkov
@GSto Nie chcę pracować 180% czasu, 100% jest dla mnie w porządku!
— adamk
13

Znajomość domen Specyfikacja nigdy nie jest w 100%; znajomość faktycznej domeny, dla której się rozwijasz, ZAWSZE podniesie jakość produktu.

— Steven Evers
źródło
11

Wskaźniki, oczywiście. :)

— Laurynas Biveinis
źródło
3
Wskaźniki są naprawdę potrzebne tylko w podzbiorze języków dla małego podzbioru zadań. W przypadku większości zadań możesz (i powinieneś być w stanie) programować tak, jakby koncepcja wskaźnika nie istniała.
— Chinmay Kanchi,
14
@Chinay Kanchi Nie. Wskaźniki powinny być zrozumiałe dla wszystkich.
— alternatywny
5
To naprawdę zależy od tego, co rozumiesz przez wskaźnik. Jeśli masz na myśli wskaźniki w stylu C, którymi możesz manipulować (co zakładałem), argumentowałbym, że programista Java / C # / Python nie musi nic o nich wiedzieć. Jeśli masz na myśli wskaźnik jak w „referencjach” Javy, tj. Wskaźnik, którego nie można manipulować, to tak, pewna wiedza na ich temat jest konieczna, choćby po to, aby zapobiec poślizgnięciu się.
— Chinmay Kanchi,
@mathepic Będziesz wstrząśnięty do samego rdzenia, jeśli chcesz dowiedzieć się, ilu studentów CS kończy studia każdego roku, którzy nie rozumieją pierwszej rzeczy na temat wskaźników. Gdybym nie robił wszystko, aby co roku odbywać praktyki, nie zostałbym nawet nauczony o wskaźnikach w C lub referencjach w Javie ...
— Mike B
5
@Chinmay: Programator w języku Python / Java / C #, który nie rozumie pojęcia wskaźników, został utracony. L = [[]] * 2; L[0].append(42) Różne języki używają różnych nazw, ale pośrednictwo jest niezbędne wszędzie.
11

Code Complete 2 - od deski do deski

— Kyle Ballard
źródło
naprawdę powinieneś o tym wiedzieć, zanim zaakceptujesz pieniądze na program. Jeśli znajdziesz w nim coś, czego nie wiedziałeś, rozważ zmianę kariery lub intensywny okres samodzielnej nauki, aby przejść przez to wszystko. A potem przeproś swoich współpracowników. I obejmuje tylko podstawy programowania.
— Tim Williscroft,
11

Dane są ważniejsze niż kod.

Jeśli twoje dane są inteligentne, kod może być głupi.

Głupi kod jest łatwy do zrozumienia. Podobnie inteligentne dane.

Prawie każdy smutek algorytmiczny, jaki kiedykolwiek miałem, był spowodowany tym, że dane znajdowały się w niewłaściwym miejscu lub zostały naruszone ich prawdziwe znaczenie. Jeśli twoje dane mają znaczenie, umieść to w systemie typów .

— Gonzales
źródło
2
Miałeś mnie przez cały czas, aż powiedziałeś „system pisania”.
10

Który język i środowisko jest najbardziej odpowiednie do pracy. I nie zawsze jest to twój ulubiony.

— Dan Diplo
źródło
10

Dziel i rządź. Jest to zwykle najlepszy sposób na rozwiązanie dowolnego praktycznego problemu, od planowania do debugowania.

— Rick Minerich
źródło
8

Prawdziwa umiejętność znajduje odzwierciedlenie w umiejętności dobrego wykonania prostego projektu, a nie w umiejętności wykonania skomplikowanego projektu.

Ta umiejętność pochodzi z większego opanowania podstaw, a nie z opanowania magii. Programiści wysokiego kalibru nie są zdefiniowani przez ich zdolność do kodowania tego, czego inni nie potrafią (za pomocą funkcji wyższego poziomu, zaawansowanego programowania funkcjonalnego, what-have-you), ale raczej przez ich zdolność do udoskonalenia doskonale przyziemnego kodowania. Wybór odpowiedniego rozkładu funkcjonalności między klasami; budowanie w solidności; stosowanie defensywnych technik programowania; i przy użyciu wzorców i nazw, które prowadzą do większej samokokumentacji, to chleb powszedni programowania na wysokim poziomie.

Kluczowe znaczenie ma napisanie dobrego kodu, do którego ty lub ktoś inny możesz wrócić w ciągu tygodnia, miesiąca lub roku i zrozumieć, jak używać, modyfikować, ulepszać lub rozszerzać ten kod. Oszczędza czas i wysiłek umysłowy. Smaruje koła produktywności, usuwając blokady, na które wcześniej się potknąłeś (być może przerywając tok myślenia, a może zabierając godziny lub dni wysiłku z dala od innej pracy itp.) Ułatwia koncentrację na trudnych problemach , a czasem sprawia, że ​​trudne problemy znikają.

Jednym słowem: elegancja. Każda klasa, każda metoda, każdy warunek, każdy blok, każda nazwa zmiennej: dąż do elegancji.

— Klin
źródło
8

Nigdy nie obwiniaj użytkownika za to, co można naprawić dzięki lepszej obsłudze lub lepszej dokumentacji. Często programiści automatycznie zakładają, że użytkownik jest idiotą, który nie może nic zrobić dobrze, gdy problemem jest ogólne złe doświadczenie lub brak komunikacji. Programy mają być używane, a traktowanie użytkownika z pogardą oznacza przede wszystkim pominięcie sensu programowania.

— 8
źródło
6

Każdy programista powinien wiedzieć, jak używać debuggera, i wiedzieć, jak z niego korzystać również .

— Brian R. Bondy
źródło
4

Jak dokładnie oszacować, ile czasu zajmie wdrożenie danej funkcji. Co ważniejsze, jak przekazać, że nie przesadzasz, kiedy przesyłasz tę prognozę.

— pszenica
źródło
2
lub dowiedz się, jak dobrze gościć i przekazywać, że nie jesteś gościnny ...;)
— Billy Coover
4

Styl kodowania ma znaczenie:

  • spójne wcięcie ma znaczenie,
  • konsekwentne korzystanie z białych znaków (np. wokół operatorów) ma znaczenie,
  • konsekwentne umieszczanie spraw {},
  • ważne są dobrze dobrane identyfikatory,
  • itp.

... i dobre wzornictwo ma znaczenie.

Idealnie, programista uczy się tych rzeczy przed (lub podczas) swojej pierwszej recenzji kodu. W najgorszym przypadku programista uczy się, gdy szef każe mu szybko wprowadzić jakieś nietrywialne zmiany w okropnym kodzie.

— Stephen C.
źródło
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.