Вы просите Святого Грааля разработки программного обеспечения, и пока никто не имеет «ответа» на этот вопрос.
Важно, чтобы вы отслеживали типы ошибок, которые вы делаете, а затем выполняли анализ этих ошибок, чтобы определить, есть ли общая тенденция. Анализ первопричин является формальным названием для этого типа самоанализа, и в Интернете есть много материала относительно этого.
Профессионалы используют систему отслеживания ошибок, чтобы они могли (1) знать, что необходимо исправить, а также (2) анализировать то, что должно быть исправлено после факта. Вам не нужно быть таким формальным - просто ведите счет в тетради.
Дефекты стадии проектирования
Если вы обнаружите, что большинство ваших ошибок происходят из-за неправильного понимания формулировки проблемы, или если вы продолжаете обнаруживать, что выбрали неправильный алгоритм или путь, по которому следует идти в решении своих проблем, у вас есть проблемы на этапе проектирования.
Вам следует уделить больше времени в начале проекта и написать, что именно нужно сделать и как он должен это делать. Внимательно просмотрите эту работу, вернитесь к первоначальной проблеме и определите, действительно ли вы ее решаете. Дополнительный час или три в начале могут сэкономить вам много часов в будущем.
Ошибки кодирования
Если ваш дизайн надежный, но вы постоянно боретесь с языком, на котором пишете код, приобретите себе инструменты, которые будут анализировать ваш код для вас и предупреждать вас рано и часто, что вы делаете ошибки.
Если вы программируете на C, включите все предупреждения компилятора, используйте семантическую проверку, например lint, и используйте инструмент, подобный valgrindдля обнаружения общих проблем, связанных с динамической памятью.
Если вы программируете на Perl, включите strictи warningsи внимайте , что он говорит.
Независимо от того, какой язык вы используете, вероятно, существует множество инструментов, которые помогут выявить типичные ошибки задолго до того, как вы достигнете стадии отладки.
Дефекты стадии интеграции
По мере того, как вы разрабатываете свой код, следуя хорошим правилам модульности, вы должны начать склеивать отдельные части вместе. Например, различные разделы вашего кода могут иметь отношение к пользовательскому вводу, взаимодействию с базой данных, отображению данных, алгоритмам / логике, и каждый из них построен относительно независимо друг от друга (то есть вы склонны концентрироваться на данном разделе). а не беспокоиться об интеграции со всем остальным).
Вот где разработка, управляемая тестами (TDD), оказывается очень полезной. Каждый модуль вашего кода может иметь тесты, которые проверяют их работу в соответствии с тем, как они были разработаны. Эти тесты должны быть либо написаны первыми, либо в самом начале процесса, чтобы у вас был набор «помощников», чтобы вы были честны. Когда вы начинаете заставлять все работать вместе и обнаруживаете, что вам нужно изменить то, как то или другое реализовано или взаимодействует с другой подсистемой, вы можете вернуться к своим тестам, чтобы убедиться, что то, что вы сделали, чтобы сделать все это работает вместе, не нарушает правильность кода.
И так далее...
Возьмите несколько книг по разработке программного обеспечения и практическим методам кодирования, и вы узнаете много разных способов сделать разработку менее хаотичной и более надежной. Вы также обнаружите, что просто старый опыт - получение степени в школе сильных ударов - также поможет вам обрести форму.
Практически все сводится к тому, что немного времени и начальная работа окупаются огромными дивидендами позже в процессе разработки / выпуска.
Тот факт, что вы заметили эти проблемы в начале своей карьеры, говорит о вашем будущем, и я желаю вам удачи.