Prosisz o Świętego Graala inżynierii oprogramowania i nikt nie ma jeszcze „odpowiedzi” na to pytanie.
Istotne jest, aby śledzić rodzaje popełnianych błędów, a następnie analizować je, aby ustalić, czy występuje wspólny trend. Analiza przyczyn pierwotnych to formalna nazwa tego rodzaju introspekcji, a na jej temat znajduje się mnóstwo materiałów w Internecie.
Specjaliści używają systemu śledzenia błędów, aby mogli (1) wiedzieć, co należy naprawić, ale także (2) analizować, co trzeba naprawić po fakcie. Nie musisz być tak formalny - po prostu zapisywanie notatników w notatniku może być dla Ciebie w porządku.
Wady etapu projektowania
Jeśli okaże się, że większość błędów wynika z niezrozumienia opisu problemu lub jeśli ciągle znajdujesz, że wybrałeś niewłaściwy algorytm lub ścieżkę rozwiązywania problemów, masz problemy na etapie projektowania.
Opłaca się poświęcić więcej czasu na początku projektu i napisać dokładnie, co należy zrobić i jak to zrobić. Dokładnie zapoznaj się z tą pracą i wróć do pierwotnego problemu i ustal, czy naprawdę rozwiązujesz go we właściwy sposób. Dodatkowa godzina lub trzy na starcie mogą zaoszczędzić wiele godzin na drodze.
Błędy kodowania
Jeśli Twój projekt jest solidny, ale ciągle walczysz z językiem, w którym kodujesz, zdobądź narzędzia, które przeanalizują Twój kod i ostrzeżą cię wcześnie i często, że popełniasz błędy.
Jeśli programujesz w języku C, włącz wszystkie ostrzeżenia kompilatora, użyj narzędzia sprawdzania semantycznego linti użyj narzędzia, na przykład, valgrindaby wychwycić typowe problemy związane z pamięcią dynamiczną.
Jeśli programowania Perl, włącz stricti warningsi Uważajcie, co mówi.
Bez względu na to, jakiego języka używasz, prawdopodobnie istnieje wiele narzędzi, które pomagają w wykrywaniu typowych błędów na długo przed osiągnięciem etapu debugowania.
Wady etapu integracji
Gdy rozwijasz swój kod zgodnie z dobrymi praktykami modułowości, musisz zacząć sklejać poszczególne elementy. Na przykład różne sekcje kodu mogą mieć związek z wprowadzaniem danych przez użytkownika, interakcją z bazą danych, wyświetlaniem danych, algorytmami / logiką, a każda z nich jest zbudowana względnie niezależnie od siebie (to znaczy koncentrujesz się na danej sekcji zamiast martwić się integracją ze wszystkim innym).
Tutaj bardzo przydaje się rozwój oparty na testach (TDD). Każdy moduł twojego kodu może mieć testy, które sprawdzą, czy działają zgodnie z tym, jak zostały zaprojektowane. Testy te powinny być napisane jako pierwsze lub na bardzo wczesnym etapie procesu, abyś mógł mieć zestaw „pomocników”, aby zachować uczciwość. Kiedy zaczniesz wszystko działać razem i okaże się, że musisz zmienić sposób, w jaki to lub to jest implementowane lub współdziała z innym podsystemem, możesz cofnąć się w swoich testach, aby upewnić się, że to, co zrobiłeś, aby zrobić wszystko działa razem, nie psuje poprawności kodu.
I tak dalej...
Wybierz kilka książek na temat inżynierii oprogramowania i praktycznych technik kodowania, a nauczysz się wielu różnych sposobów zmniejszania chaosu i zwiększenia niezawodności programowania. Przekonasz się również, że zwykłe, stare doświadczenie - zdobycie dyplomu ze szkoły trudnych uderzeń - również sprawi, że będziesz w formie.
Prawie wszystko sprowadza się do tego, że trochę czasu i pracy z góry opłaca się w postaci ogromnych dywidend później w procesie rozwoju / wydania.
Fakt, że zauważyłeś te problemy na wczesnym etapie kariery, dobrze świadczy o twojej przyszłości i życzę powodzenia.