Внутренние недостатки качества и технический долг
Когда мы используем термин Cruft в разработке программного обеспечения, мы имеем в виду избыточный, дефектный, бесполезный и плохо написанный код. Другой способ определить термин Cruft - это «вещи», которые были временно оставлены в системе во время предыдущей итерации. Кроме того, Cruft относится к любому коду, который не является необходимым для выполнения задачи, для которой он был разработан, или кода, который был забыт без какой-либо утилиты.
Хотя Cruft не означает ошибки в коде, это затрудняет обслуживание или чтение кода и создает технический долг.
Грубый компьютерный жаргон также используется для описания различных ситуаций, таких как устаревшие компьютеры, старые мониторы или устаревшие жесткие диски. Тем не менее, в нашем случае мы будем ссылаться на последствия плохо написанного кода.
Технический долг - это концепция в разработке программного обеспечения, которая показывает стоимость переделки вещей, вызванную выбором быстрого решения вместо решения проблем с использованием лучшего решения, которое мы можем реализовать на данный момент.
Технический долг и программное обеспечение
Когда мы говорим о техническом долге и Cruft, мы имеем в виду способ думать об обращении с Cruft, как если бы это был финансовый долг.
Иногда, когда мы разрабатываем функциональность, у нас нет всех знаний, чтобы реализовать ее наилучшим образом в то время, но это не значит, что нам не нужно думать об этом и делать это в соответствии с передовыми методами. Это то, что делает технический долг, который мы генерируем, легким для выплаты в будущем или нет.
Если код, который мы написали в прошлом, породил технический долг в настоящем, и этот код прост и понятен, проценты, которые нужно заплатить, будут небольшими, потому что рефакторинг будет простым и не потребует много времени ( Деньги). Но если код сложен для понимания, нам придется заплатить много процентов, потому что нам потребуется много времени, чтобы понять его, а затем провести его рефакторинг.
Следующее видео объясняет метафору технического долга:
Например, представим, что мы разработали алгоритм для распознавания образов на изображениях и идентификации кошек. Алгоритм не идеален, но мы знаем об этом, и мы разработали его таким образом, чтобы, когда мы захотим улучшить его снова в будущем, его было легко понять и изменить.
В этом случае затраты на изготовление будут небольшими. Но наоборот, если мы используем алгоритм, который мы копируем откуда-то, а затем модифицируем, не очень хорошо понимая его, а также не следуя какой-либо хорошей практике, стоимость его рефакторинга будет очень высокой. Эта стоимость и есть проценты, и от нас будет зависеть, будут ли они большими или маленькими в будущем.
Таким образом, проблема заключается не в том, что мы оставляем, а в том, что мы не осознаем его и не понимаем его как следует. Почему мы так реализуем? Что именно он делает? Используется ли вышеупомянутый алгоритм во многих местах, реализован ли он в соответствии с передовой практикой?
В следующем примере предположим, что мы с самого начала знаем объем Cruft, и мы разработали его с идеей рефакторинга в будущем. Кроме того, он не очень интегрирован с остальным нашим программным обеспечением, поэтому проценты, которые нам придется платить в будущем, будут небольшими:
В этом другом случае мы с самого начала знаем объем Cruft. Мы разработали его с идеей рефакторинга в будущем, но он очень интегрирован с остальной частью нашего программного обеспечения, поэтому проценты, которые мы должны платить, высоки, но чем раньше вы заплатите и устраните Cruft, тем меньше будет технического долга. создано, и интерес не будет расти дальше:
Это наихудший сценарий. Мы не знаем о техническом долге, возникшем в прошлом, поэтому нам сначала нужно знать его объем и понять, чтобы затем попытаться реорганизовать его, ничего не испортив. Если бы код был написан не в соответствии с передовой практикой, его рефакторинг был бы очень сложным и дорогостоящим:
Как мы можем удалить Cruft?
Удаление Cruft помогает нам удешевить его для будущих изменений. Рекомендуется устранять его постепенно. Мы можем начать удаление Cruft в тех областях, которые мы часто используем, тем самым значительно уменьшив наш долг и проценты.
Если Cruft, который мы хотим удалить, почти не используется и его актуальность в нашем коде невелика, лучше не делать этого. вкладывайте в это много времени, потому что проценты, которые мы будем платить в будущем, будут минимальными.
Как и в самой жизни, инвестируйте в то, что принесет вам больше пользы в будущем.
Заключение
Что я считаю наиболее полезным, так это знать, как дифференцировать тип долга, который мы генерируем. Не то же самое, осознавать это и оставлять его как можно лучше для его решения в будущем, чем даже не осознавать долг, который мы генерируем, и последний заставит нас заплатить очень высокую цену в будущем, когда мы попробуйте изменить или добавить новые функции.
Спасибо, что прочитали меня!
