Ви просите священний Грааль програмної інженерії, і ніхто ще не має "" відповіді на це питання.
Важливим є те, що ви відстежуєте типи помилок, які ви робите, а потім аналізуєте їх, щоб визначити, чи є загальна тенденція. Аналіз кореневих причин - формальна назва цього типу самоаналізу, і в Інтернеті є багато матеріалів щодо цього.
Професіонали використовують систему відстеження помилок, щоб вони могли (1) знати, що потрібно виправити, а також (2) проаналізувати, що потрібно було виправити після факту. Вам не потрібно бути настільки офіційним - просто ведення обліку в зошиті для вас може бути добре.
Дефекти сценічного дизайну
Якщо ви виявили, що більшість ваших помилок виникають через нерозуміння постановки проблеми, або якщо ви продовжуєте знаходити, що ви вибрали неправильний алгоритм чи шлях для вирішення своїх проблем, у вас проблеми на стадії проектування.
Було б вам потрібно надати більше часу на початку проекту і записати, що саме потрібно зробити і як це робити. Уважно перегляньте цю роботу та перегляньте початкову проблему та визначте, чи справді ви її вирішуєте правильним способом. Додаткова година або три на початку можуть врятувати багато годин в дорозі.
Помилки кодування
Якщо ваш дизайн міцний, але ви постійно боретесь з мовою, якою ви кодуєте, знайдіть собі інструменти, які аналізують ваш код і попереджають вас рано і часто, що ви робите помилки.
Якщо ви програмуєте на C, увімкніть усі попередження компілятора, використовуйте семантичну перевірку, як-от lint, і використовуйте інструмент, як valgrindдля пошуку загальних проблем, пов'язаних з динамічною пам'яттю.
Якщо ви програмуєте на Perl, включіть strictі warningsщоб чути , що він говорить.
Незалежно від того, якою мовою ви користуєтесь, напевно, існує багато інструментів, які допомагають вловлювати поширені помилки задовго до того, як дійти до етапу налагодження.
Дефекти стадії інтеграції
Коли ви розробляєте свій код, дотримуючись належних методів модульності, вам доведеться починати склеювати окремі шматки. Наприклад, різні розділи вашого коду можуть мати відношення до введення користувачем, взаємодії з базою даних, відображення даних, алгоритмів / логіки, і кожен з них побудований відносно незалежно один від одного (тобто ви схильні зосереджуватися на розділі а не турбуватися про інтеграцію з усім іншим).
Ось де дуже зручна тестова розробка (TDD). Кожен модуль вашого коду може мати тести, які підтверджують, що вони працюють відповідно до того, як вони були розроблені. Ці тести повинні бути складені спочатку або дуже рано в процесі, щоб у вас був набір "помічників", щоб зробити вас чесними. Коли ви почнете змушувати все працювати разом, і виявите, що вам потрібно змінити те, як реалізується та чи інше, або взаємодіє з іншою підсистемою, ви можете повернутися до своїх тестів, щоб переконатися, що ви зробили, щоб зробити все це спільно не порушує правильність коду.
І так далі...
Візьміть кілька книг з програмної інженерії та практичних методів кодування, і ви дізнаєтесь багато різних способів зробити розробку менш хаотичною та надійнішою. Ви також знайдете, що просто звичайний досвід - заробити ступінь в школі важких ударів - також приведе вас у форму.
Що майже все зводиться до того, що трохи часу та роботи наперед виплачуються величезними дивідендами пізніше в процесі розробки / випуску.
Те, що ви помітили ці проблеми на початку своєї кар’єри, говорить добре для вашого майбутнього, і я бажаю вам удачі.