Мы, программисты, часто шутим, что наша ежедневная работа — нагадить гору дерьма. Есть лучшее название для этой горы дерьма — технический долг.

Как возникает технический долг

Я участвовал во многих различных проектах, и практически каждый проект имеет в той или иной степени исторический долг. На самом деле, команд, готовых предоставить ресурсы для урегулирования исторических долгов, еще меньше.

Быстрая итерация бизнес-функций часто означает отсутствие долгосрочного планирования и проектирования, а об архитектурной эволюции и итерациях не может быть и речи. Мы всегда жалуемся, что гадим на гору дерьма, но реальная ситуация со многими проектами такова, что их жизненные циклы очень короткие, и бизнес может быть ликвидирован до того, как он станет стабильным.

В таких обстоятельствах образование технического долга неизбежно, и каждая написанная нами строка кода может стать историческим долгом. Поскольку наш бизнес постоянно основан на методах проб и ошибок и итерациях, проекты постоянно меняются и развиваются. Не существует уникального технического решения, и наиболее подходящее техническое решение неизбежно будет меняться вместе с проектом.

Даже если нам повезет столкнуться с проектами с длительным жизненным циклом, мы неизбежно будем заняты набором функций, когда бизнес быстро растет. Технические изменения необходимы только тогда, когда стоимость обслуживания существующей архитектуры станет слишком высокой и повлияет на последующие функциональные итерации.

Когда необходимо изменить архитектурный проект и внедрить новые технологии, прошлые программные проекты могут легко стать историческими долгами. Это неизбежный процесс.

Хотя технического долга невозможно избежать, когда технологии меняются, мы можем использовать некоторые методы, чтобы заставить их генерировать меньше долгов.

Предварительное исследование технических решений

В последние годы интерфейсные технологии очень быстро изменились, и многие люди будут внедрять новые технологии в проекты, чтобы добиться более высокой эффективности разработки или производительности. Кроме того, я также видел внедрение многих технологий просто для того, чтобы не отставать от нового стека технологий или для экспериментов с бизнес-кодом.

Самое страшное - это внедрение технологий с целью репортажа. В своей работе я видел бесчисленное количество насильственно построенных колес или внедрение новых технологий ради продвижения и защиты. Пройдя защиту, они часто продолжают покорять очередную «техническую изюмину», оставляя после себя груды технического долга. Конечно, в этом нельзя винить людей, оставивших долг. Зачастую они просто пытаются получить больше льгот в рамках правил.

Что ж, когда мы сталкиваемся с необходимостью внедрения нового Архитектурного дизайн или техническое время, вы можете провести более детальное Предварительное исследование технических решений,Чтобы попытаться избежать увеличения технического долга. Обеспечивает оптимизацию технических решений.,Это позволяет избежать проблем, возникающих в процессе разработки, которые необходимо отменить и переделать.,Также можно заранее оценить ожидаемый эффект и то, как введенный технический долг решит проблему.

Для технического предварительного исследования можно рассмотреть несколько аспектов:

1. Анализ статуса/болевых точек проекта.
2. Исследование/выбор отраслевых решений.
3. Масштабируемость архитектуры.

1. Статус проекта/анализ болевых точек

При проведении исследования технических решений нам необходимо сначала проанализировать предысторию, существующие болевые точки и текущие проблемы собственного проекта. Только выяснив, где находятся проблемы проекта, мы сможем решить эти проблемы более точно и основательно.

Когда многие люди получают незнакомый проект, их первой реакцией часто является его рефакторинг. Честно говоря, хорошо выполнять рефакторинг зачастую неблагодарно. В связи с этим я лично предлагаю разработать и поддерживать его в течение определенного периода времени. После того, как вы узнаете фактическую ситуацию с проектом в сочетании с будущим планированием бизнеса, вы сможете подумать, необходимы ли работы по реконструкции или локальной оптимизации. Если бизнес стабилен и новые функции не будут использоваться, если только не будет слишком много ошибок, которые нужно исправить, нет необходимости вкладывать сюда слишком много энергии.

Каковы болевые точки проекта? Грубо говоря, это то, на что мы жалуемся каждый день, а также то, что нам кажется неинтересным, например: плохой исторический код, скучная и однообразная работа по разработке, низкая эффективность разработки, вызванная историческим долгом и т. д. Вместо того, чтобы каждый день жаловаться, мы можем потратить некоторое время на решение проблем, чтобы у нас было больше времени на рыбалку каждый день (нет.

В большинстве случаев существующий дизайн проекта не может поддерживать быструю итерацию последующих функций.

Мы можем активно искать проблемы и болевые точки в проекте и пытаться их решить. Разные проекты или разные периоды одного и того же проекта будут сосредоточены на разных технических моментах. Для внешнего проекта техническая ценность часто отражается на производительности системы, стабильности, ремонтопригодности, повышении эффективности и т. д., например:

2. Исследование/выбор отраслевого решения

Болевые точки проекта можно трансформировать в целевое направление, например:

После того, как мы определим цели, мы сможем провести исследование и выбор отраслевых решений.

Например, код проекта уже очень велик, отношения вызовов между модулями слишком запутаны, количество состояний модуля слишком велико, что усложняет модификацию и мониторинг и т. д. Затем, в этом случае, нам необходимо внедрить в проект новые технологии или архитектурные решения, например, использование внедрения зависимостей для управления зависимостями между модулями и использование инструментов управления состоянием для поддержания статуса каждого модуля приложения и глобального.

Специально для разработки интерфейсных страниц существует множество инструментов управления статусом внешнего интерфейса, включая vuex, redux, которые поставляются с каждой структурой, и популярный mobx. Конкретное введение может быть основано на собственной ситуации в проекте, например. используемая структура и технология проекта и т. д., чтобы сделать выбор.

Кроме того, иногда мы сталкиваемся с проблемами, когда некоторые существующие инструменты с открытым исходным кодом невозможно напрямую использовать в проекте. В это время нам часто приходится «изобретать велосипед», то есть обращаться к зрелым техническим решениям в отрасли и корректировать реализацию на их основе. о реальной ситуации в проекте. Например, возьмем решение по внедрению зависимостей. Среди известных проектов с открытым исходным кодом Angular и VsCode реализовали среду внедрения зависимостей, но не существует инструментов, которые можно было бы использовать напрямую. Мы можем проанализировать их идеи и реализацию, изучив связанные с ними методы кода. используйте его в своих проектах.

3. Масштабируемость архитектуры

Лично я считаю, что при внедрении новой архитектуры или новой технологии следует учитывать два важных момента:

1. Сможет ли новая архитектура/технология поддержать будущее планирование бизнеса.
2. Насколько тщательно это введение и не оставит ли оно новых технических долгов?

Разные проекты или разные периоды одного и того же проекта будут сосредоточены на разных технических моментах. На ранних стадиях проекта основное внимание часто уделяется быстрым пробам и ошибкам, а также функциональной итерации. В стабильный период проекта затраты на обслуживание проекта постепенно будут уделять больше внимания.

Когда мы внедряем новые технологии или архитектуры, нам также необходимо учитывать последующий план развития проекта. Например, когда мы вводим внедрение зависимостей в проект, предполагая, что мы знаем, что проект должен поддерживать функции встроенных приложений в будущем, мы можем рассмотреть возможность использования SDK в качестве измерения для внедрения зависимостей, чтобы избежать существования двух SDK в одном проекте. то же самое приложение позже. Управление внедрением зависимостей сбивает с толку.

Проблема технического долга, вызванная техническими изменениями, также требует детальной оценки в ходе разработки программы. Например, трансформация архитектурного проектирования часто приводит к огромной рабочей нагрузке. Существуют ли эффективные решения такой рабочей нагрузки, такие как внедрение автоматизированных процессов, добавление новой человеческой поддержки и т. д. Если хорошего решения проблемы нет, то внедрение новой технологии неизбежно приведет к увеличению технического долга. В этом случае нужно тщательно взвесить, стоит ли оно того.

Что касается исследований технических решений, связанных,До Я написал более подробную статьюизстатья：«Процесс исследования и проектирования технических решений»,Заинтересованные друзья также могут посмотреть.

на самом деле,Анализ проекта также может стать хорошим способом решения проблемы оставшегося технического долга.,В то же время вы можете избежать повторения тех же ошибок.,До«Почему проверка проекта важна»Также представлено в статье。

Заключение

Неважно, как вы проживаете свою жизнь, вы будете проживать ее изо дня в день, хорошие или плохие дни у вас, но если у вас будет немного больше требований и ожиданий к себе, ваша жизнь может становиться лучше с каждым днем~