O jakich najgorszych rzeczach niedoświadczeni programiści zapominają myśleć? [Zamknięte]

15

Jako młody programista uważam, że przydatne byłoby uzyskanie porady na temat rzeczy do przemyślenia w celu opracowania aplikacji wysokiej jakości. Na moich kursach uniwersyteckich większość nauczycieli podkreślała walidację danych wejściowych, a niektórzy mówili o obawach związanych z bezpieczeństwem, ale nikt nie zwracał uwagi na znaczenie niektórych innych rzeczy, na przykład rejestrowania.

Jakie błędy popełniają niedoświadczeni programiści, co może prowadzić do frustracji bardziej doświadczonych programistów?

awmckinley
źródło
1
Nie nazwałbym „bezpieczeństwa” czymś, co powinno znaleźć się na „liście kontrolnej” - bezpieczeństwo musi być rozważane na wszystkich poziomach projektu, a nie dodawane jako uzupełnienie. Funkcje bezpieczeństwa! = Funkcje bezpieczne!
Billy ONeal
Może „lista kontrolna” oznacza złą rzecz. Nie szukam listy rzeczy do przemyślenia pod koniec rozwoju; Jestem ciekawy, jakie rzeczy należy wziąć pod uwagę podczas tworzenia aplikacji. Czy masz sugestię, w jaki sposób mógłbym powtórzyć moje pytanie?
awmckinley
@awmckinley: Twoje pytanie brzmi: „jak opracować aplikację” - ale pytanie jest zbyt ogólne, aby można było na nie odpowiedzieć.
Billy ONeal
@Billy ONeal: Właśnie zredagowałem moje pytanie. Czy to ma sens?
awmckinley
1
Ma to większy sens, ale niestety wciąż nie wymaga niczego więcej niż listy najlepszych praktyk. Konstruktywne pytania naprawdę powinny dotyczyć konkretnych problemów, a przynajmniej wymagać odpowiedzi, aby były więcej niż jednoznacznymi opiniami.
Aaronaught

Odpowiedzi:

12

Najważniejszą rzeczą, o której nowi programiści zapominają, jest to, że w prawdziwym świecie często pracują w zespole. To pokazuje się jako ...

  • Sprawdzanie kodu, który psuje kompilację
  • Nie używam kodu, który już tam jest
  • Robienie rzeczy po swojemu, a nie w taki sam sposób jak wszyscy inni - co sprawia, że ​​konserwacja jest droga

Nie oznacza to, że ich kod nie jest do zera w izolacji, ale nie działają już w izolacji.

Garry
źródło
+1: zasadniczo są to problemy, które napotykasz. Młodszy programista może być kiepski w kodowaniu, ale niektórzy doświadczeni też mają słabe kodowanie. Główne rozróżnienie to takie przedmioty.
gbjbaanb
8
  1. Testy
  2. Testy
  3. Więcej testów.
  4. Kontrola źródła
  5. Podatki odpowiednie dla każdego programu, na który celujesz.

W systemie Windows podatki te wynoszą :

  • Radzenie sobie w środowiskach o wysokiej DPI
  • Profile użytkowników mobilnych
  • Szybkie przełączanie użytkowników
  • Pulpit zdalny (np. Nie chcesz używać podwójnego buforowania, gdy działa RDP
  • Dobra gra dzięki Hierarchical Storage Management
  • Wiele monitorów
  • 64-bitowy system Windows

Na prawie każdej platformie będziesz musiał poradzić sobie z:

  • Unicode
  • Lokalizacja
  • Zarządzanie energią
Billy ONeal
źródło
Przepraszam, Billy. Może nie byłem jasny w sposobie, w jaki zadałem moje pytanie: nie szukam aż tyle praktyk programistycznych (takich jak kontrola źródła). Myślę, że zostało to całkiem dobrze omówione w Co dodałeś do tej listy kontrolnej projektu rozwoju oprogramowania? . Sekcja „podatki” jest jednak zdecydowanie pomocna.
awmckinley
3
@awmckinley: Powodem, dla którego przywołuję kontrolę źródła, jest to, że nie będziesz w stanie skutecznie zarządzać wydaniami bez posiadania wielu kierowników rozwoju - nawet jeśli jesteś tylko programistą solo. Musisz pomyśleć o wydaniu n + 1, nawet jeśli pracujesz nad wydaniem n.
Billy ONeal
5

Z mojego doświadczenia wynika, że ​​prawie wszyscy niedoświadczeni programiści nie pamiętają, że (prawie zawsze) pracujesz w środowisku komercyjnym. Twój kod musi być dobry, ale nie idealny. Najważniejszą rzeczą nie jest perfekcja, tylko to, że kod jest wysyłany.

Innymi słowy, dostarczenie idealnego fragmentu kodu trzy miesiące po upadku Twojej firmy nie jest dobre dla nikogo.

Moim zdaniem jest to jeden z najbardziej znaczących sposobów, w jaki rozwój w prawdziwym świecie różni się od rozwoju nauczanego na uniwersytecie.

Simon Whitaker
źródło
3

Naprawdę szerokie pytanie; szczegółowa odpowiedź to ... wiele książek.

Oto ogólna lista kontrolna definicji systemów na początek -

  • Jakie są krytyczne zasoby w systemie i jak mogą się zmieniać ich wymagania?
  • Jakie są możliwości wydajności systemu i jak mogą one potrzebować wzrostu?
  • Które obszary wymagań mogą stać się niepotrzebne i możliwe do usunięcia?
  • Czy istnieje możliwość posiadania różnych wersji systemu o różnych możliwościach?
  • Jakie są konsekwencje dla siły roboczej i zasobów komputerowych, jeśli dojdą do zidentyfikowanych zmian?
  • Jaki wpływ będzie miał nowy system na istniejące systemy operacyjne?
  • Które obszary funkcji mają większą szansę na wymaganie zmiany w świetle doświadczenia z systemem?
  • Kim są przyszli użytkownicy systemu?
  • Jakie są przyszłych opiekunów systemu?
  • Jakie przyszłe ulepszenia mogą rozpoznać przyszli użytkownicy systemu?
  • W jaki sposób system pasuje do ogólnych planów użytkownika i jak ma się rozwijać?
Steven A. Lowe
źródło
1

Czyste odsprzęganie systemu na maszynie programistycznej i maszynie docelowej, dzięki czemu nie kończy się sytuacja „Cóż, działa na moim komputerze”.

A jak szybko możesz zrekonstruować swoją maszynę programistyczną?

  • Czy wiesz, jakich pakietów potrzebujesz?
  • Czy masz rozwiązanie do odbudowy bazy danych za pomocą przycisku?
  • Czy masz rozwiązanie do testowania integralności kodu źródłowego za pomocą przycisku?
ind
źródło
1

Myślę, że prawdopodobnie jest to projekt - tj. Podejście do myślenia o tym, co zamierzasz zrobić, zanim to zrobisz.

Zbyt wielu niedoświadczonych programistów (pamiętaj, kiedy pierwszy raz zacząłeś) lubił wskoczyć i zacząć coś robić, a następnie dodać trochę więcej, dodać trochę reklamy i dodać trochę więcej. Takie podejście może zadziałać, jeśli planujesz zrobić to w ten sposób (w końcu każdy bit można przetestować podczas pracy), ale większość niedoświadczonych programistów skupia się tylko na części, którą piszą ... więc wszystkie dodatki zwykle są zhakowane na górze. Wszyscy widzieliśmy kod, który tak ewoluował!

Następną rzeczą jest organizacja, często są zbyt skoncentrowani na kodzie, który napisali, aby pamiętać, jak to zrobili i co było wymagane. Zapominają więc spakować lub udokumentować wymaganą zależność. Mają też tendencję do umieszczania rzeczy tam, gdzie upadają, w zeszłym tygodniu musiałem skrytykować młodszego, który sprawdził swój kod w katalogu głównym, w tym 3 wsdl, z których 2 to ten sam plik, i zestaw bibliotek DLL innych firm, w których popełnił podkatalog i katalog główny. Kod nie został sformatowany do żadnego standardu, który można wymyślić, i było kilka funkcji, które były obecne, ale nigdy nie zostały wywołane.

Oczywiście sprawił, że działał, ale nie był uporządkowany, co oznaczało, że instalacja i konserwacja byłyby kłopotliwe.

gbjbaanb
źródło
1

Myślę, że największe różnice dotyczą techniki kodowania. Każdy ma nieco inne podejście, ale niedoświadczeni programiści zwykle tworzą kod, który:

  • nie obsługuje przypadków granicznych
  • jest znacznie dłuższy niż to konieczne
  • ma złe parametry wydajnościowe w odpowiednich scenariuszach
  • ma słaby rozdział problemów
  • brakuje technik samoobrony, takich jak użycie const, sealed, readonly itp.
  • dziwne sposoby zwrotu danych i kolekcji danych
    • to bardziej świadczy o braku doświadczenia z platformą
Kevin Hsu
źródło
0

Ponieważ pytałeś o najgorsze rzeczy, moja odpowiedź brzmi następująco:

  1. Zapomniałem pomyśleć o odkażeniu komputera programistycznego przed oprogramowaniem szpiegującym, złośliwym oprogramowaniem i wirusami trojańskimi.
  2. Zapomniałem pomyśleć o tworzeniu regularnej kopii zapasowej zapisywanej w bezpiecznych magazynach, które znajdują się w różnych lokalizacjach geograficznych.
xport
źródło
0

Moim największym jest pamiętanie o planowaniu elastyczności. Na zajęciach wymagania są prawie zawsze określone na początku i nigdy się nie zmieniają. W oprogramowaniu często jest odwrotnie: otrzymujesz niejasny zestaw wymagań, które zmieniają się często (nawet codziennie). Najlepszą rzeczą, jaką możesz zrobić, aby pomóc w tym, jest elastyczne kodowanie: luźne sprzęganie, małe funkcje, które mogą być używane niezawodnie w wielu sytuacjach, i unikanie na tyle sztywnego kodowania.

Z czasem prawdopodobnie dowiesz się: a) jakie rzeczy najprawdopodobniej się zmienią, i odwrotnie, co najprawdopodobniej się nie zmieni, oraz b) jak przewidywać żądania zmian i planować je.

Caleb Huitt - cjhuitt
źródło