Лекция
Привет, Вы узнаете о том , что такое технический долг, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое технический долг, долг кодинга, алгоритм страуса , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
технический долг (также известный как долг кодинга ) — это метафора-неологизм, обозначающий проблему, возникающую при наличии в настоящем факта незавершенной работы в прошлом, либо откладывание на будущее выполнение той работы, которая должна быть выполнена в настоящем. Также технический долг является неизбежным следствием плохой продуманности структуры системы, непродуманности архитектуры программного обеспечения или некачественную разработку ПО, в следствие которой, выполненная работа уже сразу требует переделки. Долг может рассматриваться в виде работы, которую необходимо проделать, пока задача не сможет считаться выполненной. Если долг не погашается, то он будет продолжать увеличиваться, что усложнит дальнейшую разработку.
Как только появляются изменения в программном коде, часто появляется необходимость сделать связанные с ними изменения в других частях кода или документации. Другие необходимые, но незавершенные изменения, считаются долгом, который должен быть «оплачен» в какой-то определенный момент в будущем. Так же, как финансовый долг, эти незавершенные изменения начисляют пеню, что может сделать дальнейшее развитие проекта более трудоемким. Хотя этот термин используется в первую очередь по отношению к разработке программного обеспечения, он также может быть применен к другим сферам.
Общие причины технического долга (может быть несколько):
«Процентные платежи» появляются как при локальной разработке, так и при отсутствии технической поддержки со стороны других разработчиков проекта. Продолжение развития проекта может в будущем увеличить стоимость «погашения задолженности». Оплата долга происходит посредством простого выполнения незавершенной работы.
Накопление технического долга является основной причиной для превышения сроков выполнения проектов. Трудно оценить, сколько именно работы необходимо выполнить для погашения долга. Неопределенное количество незавершенной работы добавляется в проект с каждым изменением. Сроки «горят», когда в проекте приходит понимание того, что есть еще гораздо больше незавершенной работы (долга), чем времени для ее завершения. Чтобы иметь предсказуемые графики выпуска, команда разработчиков должна ограничить количество выполняемой работы до такого, которое позволило бы минимизировать объемы незавершенной ранее работы (долга).
"Пока развивающаяся программа постоянно меняется, ее сложность, отражая ухудшение структуры, увеличивается, пока не будет выполняться работа по поддержке оной."— Меир Мэнни Леман, 1980
В то время как закон увеличения сложности Мэнни Лемана уже доказывал, что постоянное развитие программ увеличивает их сложность и ухудшает структуру, пока ведется работа над ними, Уорд Каннингем впервые провел сравнение между технической сложностью и долгом в отчете за 1992 год:
"Создание первого временного кода, - это как влезание в долги. Небольшой долг ускоряет разработку до тех пор, пока не будет своевременно оплачиваться в виде переписывания ... Опасность возникает, когда долг не погашен. Каждая минута, потраченная на не-совсем-правильный код, учитывается в качестве процента по этому долгу. Целые инженерные организации могут быть привлечены к простою из-за долговой нагрузки неконсолидированной реализации, объектно-ориентированной или иной."— Каннингем, Уорд, 1992
В своей статье от 2004 года, Рефакторинг с использованием шаблонов, Джошуа Кериевски представляет в качестве аргумента сравнение расходов, потраченных на решение вопросов, связанных с архитектурной халатностью, которую он описывает как «долг структуры».
Действия, которые могут быть отложены, включают документацию, написание тестов, уделение внимания «TODO» комментариям, борьбе с компилятором, а также предупреждениям по статическому анализу кода. Другие случаи технического долга включают базу знаний, которая не распространяется внутри организации и код, который является слишком запутанным, чтобы его было легко изменять.
В программном обеспечении с открытым исходным кодом откладывание отправки локальных изменений в основной проект является техническим долгом.
Вы должны стремиться к такому бюджету технического долга, который возвращает вас вниз или вверх, к максимальной сумме технического долга, которую вы можете себе позволить. Чтобы определить этот бюджет, очертите в своей кодовой базе области, где технический долг стоит погасить немедленно, то есть долги, которые помешают вашей компании достичь своих текущих целей. Для вас нежелательно возвращать как слишком мало долга, так и слишком много.
Андреас Клингер, координатор удаленных команд в AngelList, :
Не все нужно рефакторить. Об этом говорит сайт https://intellect.icu . Если это не критичная часть, или никому не нужно улучшать данную функциональность в ближайшие месяцы, или это просто слишком сложно, подумайте о признании этого места техническим долгом.
Проще говоря, ваша цель — найти, где перекрываются две вещи: то, над чем вы будете работать в текущем спринте, месяце или квартале, и те части вашей кодовой базы, которые содержат технический долг. Выплачивайте долг в зоне этого пересечения, но не за ее пределами.
И именно здесь наука дополняет искусство. Вы можете использовать данные, чтобы определить области, где вам нужно погасить технический долг в ближайшее время:
Каждый разработчик в принципе понимает, что такое технический долг. Что в его проекте этот долг наверняка присутствует. Если повезет, он вспомнит несколько кусков кода, которые давно просятся быть переписанными.
Но как формализовать понятие технического долга, чтобы объяснить его другим? И, тем более, объяснить это менеджеру так, чтобы получить одобрение на рефакторинг? Как найти все места в проекте, которые нужно по-хорошему переписать, и как определить, какие из них должны быть переписаны в первую очередь?
Если эти вопросы неоднократно у вас возникали, прошу под кат.
Не весь коряво написанный код по определению является техническим долгом. Конечно, если есть такой код, то его лучше рано или поздно переписать. Но все мы знаем, что полировать код можно чуть ли не до бесконечности. Как же определить, какой код является техническим долгом?
Довольно хорошее описание технического долга дал Мартин Фаулер:
Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
То есть, чем больше усилий во время разработки мы затрачиваем из-за какого-то куска кода, тем большим техническим долгом он является. С этим сложно не согласиться, но все же этого недостаточно для того, чтобы четко определить, какие места должны быть переписаны.
Для того, чтобы оценить, насколько каждый конкретно файл/класс/функция затрачивает наши усилия при разработке, Адам вводит такое понятие, как горячие точки, Hotspots. И для поиска этих хотспотов нужен только один инструмент, который есть практически у каждого разработчика — система контроля версий.
Оценить количество усилий на поддержку файла с кодом можно, взглянув на то, как часто этот файл меняется, и на то, какая сложность у этого файла. С оценкой частоты изменений все однозначно и понятно. Сложность можно оценить разными способами, в зависимости от ваших предпочтений. В простейшем случае это может быть размер файла или количество строк кода. При прочих равных условиях поддерживать файл на 100 строк кода сильно проще, чем файл на 1000 строк кода. Если же размер файла в вашем случае не является критерием оценки сложности, можно воспользоваться различными утилитами для статической оценки сложности (например, цикломатической).
Тогда хотспоты можно будет выявить следующим образом:
Вот пример поиска горячих точек в проекте Tomcat:
Большие синие круги — это папки. Маленькие — файлы.
При всем этом, наличие хотспота совсем не означает, что этот файл проблемный (но чаще всего так и есть). Это означает, что в этих файлах вы проводите больше всего времени. И что при рефакторинге эти файлы должны быть первыми в списке, чтобы убедиться, что код там чистый, легко поддерживаемый и расширяемый.
Также в качестве примера приводятся графики анализа кода нескольких проектов, разных насколько это возможно. Разные языки, разное время жизни, разные компании-разработчики. По оси X у нас расположены файлы, по оси Y — частота их изменений.
У всех проектов наблюдается один и тот же паттерн. Большая часть кода расположено в «хвосте» графика. И соответственно, есть очень небольшая часть файлов, которые изменяются очень часто. Эти файлы тоже являются первыми кандидатами для рефакторинга.
При поиске хотспотов можно пойти глубже. И в проблемных файлах искать хотспоты уже на уровне отдельных функций:
Инструмент, который был использован для поиска таких хотспотов — codescene.io
Также полезной практикой будет регулярной отслеживание сложности вашего кода. Анализ таких данных в виде графиков будет очень наглядно показывать, в какие моменты вы сбились с верного пути.
В информатике , то алгоритм страуса стратегия игнорирования потенциальных проблем на том основании , что они могут быть чрезвычайно редки. Он назван в честь эффекта страуса, который определяется как «засунуть голову в песок и притвориться, что проблем нет». Он используется, когда более выгодно позволить проблеме возникнуть, чем пытаться ее предотвратить.
Алгоритм страуса в информатике , это стратегия пренебрежения потенциальными проблемами из-за того, что вероятность их возникновения чрезвычайно мала — «погрузить голову в песок и представить, что проблемы нет». То есть предполагается, что эффективнее разрешить проблеме реализоваться, чем попытаться ее предупредить.Этот алгоритм популярен в теориях игр.
Такой подход может быть применен для взаимной блокировки при параллельном программировании, если мы верим в очень низкую вероятность такой блокировки, а стоимость обнаружения или предотвращения слишком высока.
Взаимные уступки
Удобство
Правильность
Это один из способов работы со взаимными блокировками. Другие методы: избегание ( алгоритм Питерсона ), предотвращение ( алгоритм банкира ), выявление и восстановление .
Трудной вычислительной проблемой в информатике является этот тупик распознавания (обнаружение тупика). Алгоритм страуса является распространенной тактикой борьбы с ними, так как считается, что взаимоблокировки возникают редко и поэтому не стоят больших затрат на их выявление и предотвращение.
Например, ОС Unix, имеющая в ядре ряд массивов фиксированной размерности, потенциально страдает от тупиков, даже если они не обнаружены. Например, суммарное число процессов в системе определяется размерностью таблицы процессов. Если таблица заполнена, вероятность этого ничтожна, но такое может произойти, то для программы, которая делает вызов fork, резонно подождать некоторое время и попытаться осуществить этот вызов вновь. Следует ли отказываться от вызова fork, чтобы решить эту проблему?
Максимальное число открытых файлов аналогичным образом ограничено размером таблицы индексных узлов. С ними может произойти аналогичная ситуация. Пространство выгрузки на диске - другой лимитируемый ресурс. Фактически любая таблица в ОС - конечный ресурс.
Подход Unix состоит в том, чтобы игнорировать данную проблему в предположении, что большинство пользователей предпочтут случайный тупик нелепым правилам заставляющих их иметь один процесс, один открытый файл и т.п. ... Таким образом, мы сталкиваемся с нежелательным выбором между строгостью и удобством. Трудно найти общее, устраивающее всех решение.
Этот подход можно использовать при работе с взаимоблокировками в параллельном программировании, если считается, что они очень редки, а стоимость обнаружения или предотвращения высока. Например, если каждый ПК блокируется один раз в 10 лет, одна перезагрузка может быть менее болезненной, чем ограничения, необходимые для ее предотвращения.
Набор процессов заблокирован, если каждый процесс в наборе ожидает события, которое может вызвать только другой процесс в наборе. Обычно событием является освобождение удерживаемого в данный момент ресурса, и ни один из процессов не может запуститься, освободить ресурсы и быть пробужденным.
Алгоритм страуса делает вид, что проблем нет, и его разумно использовать, если тупиковые ситуации случаются очень редко и стоимость их предотвращения высока. Такой подход используется в операционных системах UNIX и Windows .
Хотя использование алгоритма страуса является одним из методов борьбы с взаимоблокировками , существуют и другие эффективные методы, такие как динамическое предотвращение, алгоритм банкира , обнаружение и восстановление, а также предотвращение.
Несмотря на свою эффективность, использование алгоритма Страуса меняет правильность на удобство. Тем не менее, поскольку алгоритм напрямую работает с крайними случаями, это не большой компромисс. На самом деле, самый простой и часто используемый метод выхода из тупика — это перезагрузка.
Некоторые алгоритмы с плохой производительностью в наихудшем случае обычно используются, потому что они демонстрируют плохую производительность только в искусственных случаях, которые не встречаются на практике; типичными примерами являются симплексный алгоритм и алгоритм определения типа для Standard ML . Такие проблемы, как целочисленное переполнение в языках программирования с целыми числами фиксированной ширины, также часто игнорируются, потому что они возникают только в исключительных случаях, которые не возникают для практических входных данных.
Гибридный подход с использованием алгоритма Страуса заключается в том, чтобы определить, что очень редкий случай не возникает, а затем переключиться с другого, более сложного алгоритма. Компромисс здесь заключается в том, что если обстоятельства изменятся или не будут обнаружены, редкие проблемы могут возникнуть снова.
В самом худшем случае (когда проблемы возникают довольно часто) этот алгоритм приводит к крайне низкой производительности системы. Алгоритмы с низкой производительностью в худших случаях в основном применяют из-за того, что низкую производительность они обнаруживают на искусственных примерах, почти не встречающихся в практике; типичные примеры это симплекс-метод и алгоритм проверки типов для Standard ML . Такие случаи, как целочисленное переполнение целых фиксированной ширины в языках программирования, также часто пренебрегают из-за того, что они происходят только в исключительных случаях, не встречающихся в практических входных данных.
Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области технический долг имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое технический долг, долг кодинга, алгоритм страуса и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем