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

Вот пример простого и наивного метода запроса IP-адреса на компьютере с Linux.

Шаг 1. Запрос IP-адреса

Это простая программа, которая запрашивает IP-адрес в Linux. Обратите внимание, как мы запускаем UNIX-команду подпроцесса и анализируем логику вручную на основе возвращаемой строки.

Предполагая, что этот запрос ip addr работает должным образом, он должен вернуть что-то вроде этого:

➜  ~ python temp.py
162.242.245.193

Вот несколько моментов, о которых я хочу, чтобы вы подумали.

  1. У вас есть строгие сроки и куча других функций, которые необходимо построить поверх этого get_ip_address() метода. Другими словами, они вызывают get_ip_address() и что-то делают с возвращенным IP-адресом.
  2. Эти функции зависят от get_ip_address() , но им не нужно знать или использовать состояния/переменные в интерфейсе get_ip_address().

Требуется ли какой-либо из этих 2 немедленный рефакторинг get_ip_address() , предполагая, что само приложение ограничено поддержкой Linux?

Нет. Есть «менее идеальный», но правильный код. Этот технический долг, по сути, является накладными расходами. Сама задолженность очевидна, но не замедляет разработку, пока она поддерживает правильность, оговоренную в определении продукта (запуск на Linux только на платформах версии XYZ и т. д.).

Это нормально, если функции, относящиеся к приложению, не требуют внутренних изменений, внесенных в get_ip_address()too.

Все это здорово, но через 2 недели ваша команда решает, что это приложение нужно запустить и на MacOS.

Шаг 2. Добавьте поддержку MacOS

Вы решаете запустить тот же код на Mac.

➜  Desktop python get_ip_address.py
<STACK DUMP HERE>
OSError: [Errno 2] No such file or directory

э-э… не думаю, что эта реализация работает на MacOS. На Mac нет ip addr. Время искать другую библиотеку, чтобы заставить ее работать.

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

На самом деле, к тому времени, когда вам потребуется межплатформенная поддержка, вы, возможно, уже ищете решение, более похожее на приведенное выше. Вернемся к загадке MacOS…

Нужно ли мне проводить рефакторинг на этом этапе? да.

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

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

Есть технический долг, который можно погасить позже с очень низкими процентными ставками. Это редко замедляет разработку расширяемых функций и может быть пересмотрено позже. Существует также еще один технический долг, который требует немедленного погашения, поскольку любая дальнейшая разработка/реализация функции останавливается до тех пор, пока она не будет завершена. За любую работу по разработке взимается штраф по времени, потому что в первую очередь она связана с «сломанной» функцией.

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

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

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

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