Size: a a a

Архитектура ИТ-решений

2020 June 17

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ivan
Не совсем всегда. Во время программирования разработчик около 10% времени вводит символы с клавиатуры и около 90% он борется со сложностью и читает существующий код, и это еще оптимистичные цифры. Казалось бы, что чем чище код, тем лучше экономика. Но не всегда рефакторинг окупается. К нему также применим Принцип Парето. Есть код, который читается часто, и его рефакторинг быстро окупится и существенно улучшит экономику разработки. А есть такой код, который читается редко, и его рефакторинг не отразится на экономике разработки, но зато оттянет ресурсы от более приоритетных (и более монетизируемых) задач, что, кроме cost of repair, может повлечь за собой еще и ущерб упущенной выгоды ("cost of delay"). А есть такой код, который лучше вообще не трогать, и использовать Srangler Application или дублирование контекста. Ну и еще всегда будет образовываться prudent-inadvertent debt https://martinfowler.com/bliki/TechnicalDebtQuadrant.html , какой бы опытный разработчик не был, и как бы он не старался. Момент для устранения такого техдолга зависит от объема накопленных знаний, т.е. здесь время играет на руку.
В общем, по ссылкам все расписано.
А если мы говорим про reckless debt, то сколько времени на рефакторинг не выделяй, а качественных изменений это не принесет - у команды просто нет необходимых навыков.
Это превышает мои когнитивные способности
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
в моей команде на такой случай есть линтер для проверки наличия документации к коду
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
я не согласен только с идеей отлельных задач на рефакторинг (хотя еще пару месяцев назад был сторонником такого подхода)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
я не согласен только с идеей отлельных задач на рефакторинг (хотя еще пару месяцев назад был сторонником такого подхода)
А с чем согласен?
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Ivan
Не совсем всегда. Во время программирования разработчик около 10% времени вводит символы с клавиатуры и около 90% он борется со сложностью и читает существующий код, и это еще оптимистичные цифры. Казалось бы, что чем чище код, тем лучше экономика. Но не всегда рефакторинг окупается. К нему также применим Принцип Парето. Есть код, который читается часто, и его рефакторинг быстро окупится и существенно улучшит экономику разработки. А есть такой код, который читается редко, и его рефакторинг не отразится на экономике разработки, но зато оттянет ресурсы от более приоритетных (и более монетизируемых) задач, что, кроме cost of repair, может повлечь за собой еще и ущерб упущенной выгоды ("cost of delay"). А есть такой код, который лучше вообще не трогать, и использовать Srangler Application или дублирование контекста. Ну и еще всегда будет образовываться prudent-inadvertent debt https://martinfowler.com/bliki/TechnicalDebtQuadrant.html , какой бы опытный разработчик не был, и как бы он не старался. Момент для устранения такого техдолга зависит от объема накопленных знаний, т.е. здесь время играет на руку.
В общем, по ссылкам все расписано.
А если мы говорим про reckless debt, то сколько времени на рефакторинг не выделяй, а качественных изменений это не принесет - у команды просто нет необходимых навыков.
Иван этим сообщением как раз описал проблему отдельных задач на рефакторинг
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Напомню, мы вообще-то про дизайн говорили. А значит и рефакторинг вследствие редизайна.
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
А с чем согласен?
с документацией и редизайном
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
Иван этим сообщением как раз описал проблему отдельных задач на рефакторинг
Как решать?
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
Напомню, мы вообще-то про дизайн говорили. А значит и рефакторинг вследствие редизайна.
да, но не всегда рефакторинг приводить к редизайну
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Формулы показывать менеджерам?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
да, но не всегда рефакторинг приводить к редизайну
И что?
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
Как решать?
нужно определить куски кода с которыми разработчики работают чаще всего. это можно отследить по тем же коммитам гита, есть много различных инструментов по аналитике проектов. да и без них команда как правило сама хорошо знает, где чаще что-то меняется/добавляется
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
нужно определить куски кода с которыми разработчики работают чаще всего. это можно отследить по тем же коммитам гита, есть много различных инструментов по аналитике проектов. да и без них команда как правило сама хорошо знает, где чаще что-то меняется/добавляется
Вы это менеджерам будете рассказывать?
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
то, что это все же немного разные вещи и надо их разграничивать. меня лично тема рефакторинга только интересовала, ибо больная тема
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
то, что это все же немного разные вещи и надо их разграничивать. меня лично тема рефакторинга только интересовала, ибо больная тема
Рефакторинг - это самая простая задача
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
Вы это менеджерам будете рассказывать?
а зачем? менеджерам вообще не нужно знать, что там на кухне команды творится (хотя бывают адекватные исключения). вы же не рассказываете им, как поднимать сервер, как команда использует система контроля версий, проводит ревью и т.д.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
а зачем? менеджерам вообще не нужно знать, что там на кухне команды творится (хотя бывают адекватные исключения). вы же не рассказываете им, как поднимать сервер, как команда использует система контроля версий, проводит ревью и т.д.
Ну тогда вообще проблем нет никаких. О чём мы говорили столько времени?
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
мне кажется, тут такая же история. есть задачи, а есть use-case. менеджерам интересно только то, когда будет готово второе
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если менеджер видит (буквально) что люди ходят и разговаривают (буквально), обсуждают дизайн, вместо того, чтобы писать код, то его это начинает коробить (буквально).
источник

I

Ivan in Архитектура ИТ-решений
Николай Хитров
Иван этим сообщением как раз описал проблему отдельных задач на рефакторинг
Я такого у себя не видел. Скажу больше, по одной из моих ссылок Вы можете увидеть такой текст:

"Конечно, многие говорят, что главное для них качество, а на самом деле главное для них – выполнение графика работ. В таких случаях я даю несколько спорный совет: не говорите им ничего!

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