Хотя на эту тему, безусловно, есть хорошие статьи, ни одна из них не является заменой реального опыта.
Ремонтопригодность - это не то, что вы можете планировать прямо, кроме очень маленьких проектов Это то, о чем вам нужно заботиться в течение всего проекта. На самом деле, если заранее создать множество классов и кода инфраструктуры, можно получить код, который еще сложнее понять, чем наивный спагетти-код.
Поэтому я советую очистить существующие проекты , постоянно их рефакторинг. Посмотрите на детали, которые было трудно изменить, и стремитесь к более простым решениям, которые легче понять и отрегулировать. Если код слишком плох для этого, попробуйте переписать его с нуля.
Не начинайте новые проекты и не ожидайте, что они будут успешными, просто потому, что вы прочитали еще несколько статей или использовали новый фреймворк. Вместо этого определите сбои ваших существующих проектов и исправьте их определенные проблемы. Всякий раз, когда вам нужно изменить свой код, спросите себя, как реструктурировать его, чтобы поддержать подобные изменения в будущем. Это то, что вам нужно сделать в любом случае, потому что будут аналогичные изменения в будущем.
Выполнив эти рефакторинги, вы наткнетесь на различные конкретные вопросы , о которых вы можете задать и прочитать статьи. Таким образом, вы узнаете больше, чем просто задавая общие вопросы и читая общие статьи об обслуживании и фреймворках.
Начните убирать свой код сегодня . Не откладывайте это на ваши будущие проекты.
(То же самое относится и к документации. Первые документы у всех были очень плохими. Через несколько месяцев они оказываются слишком многословными и заполненными неважными вещами. Поэтому дополните документацию решениями, которые вы действительно имел, потому что велики шансы, что в следующем году вы столкнетесь с подобной проблемой. Этот опыт улучшит ваш стиль письма больше, чем любое руководство по стилю "как писать хорошо".)