Co każdy programista powinien wiedzieć o programowaniu?

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

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).

• Jak czytać kod innych osób.
• Kod nie istnieje, jeśli nie jest sprawdzany w systemie kontroli wersji.

Obliczenia zmiennoprzecinkowe nie są precyzyjne.

Nie przestawaj się uczyć.

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

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ś .

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.

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

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ń.

Każdy programista powinien wiedzieć o testowaniu.

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

Myślenie krytyczne i logiczne. bez tego nie możesz zrobić nic dobrego.

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

Absolutne minimum Każdy programista absolutnie, pozytywnie musi wiedzieć o Unicode i zestawach znaków (bez wymówek!) .

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.

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

Notacja Big O i jej implikacje.

Kilka przydatnych odniesień

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Wskaźniki, oczywiście. :)

Code Complete 2 - od deski do deski

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 .

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

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

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.

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.

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

Struktury danych

Jak korzystać z Google

Ocena zwarć, chociaż jest to jedna z pierwszych rzeczy, których uczą o operatorach boolowskich.

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

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.