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

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?

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.

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ą

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.

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ć?

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?

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.

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ą

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.

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.