Comments 11
> Большое количество пометок FIXME и TODO и малое количество комментариев в коде должно насторожить.
По моему опыту, комментарии в большинстве случаев наоборот свидетельствуют об архитектурных ошибках и костылях. Исключением являются лишь пояснения к сложным алгоритмам и документирование интерфейсов.
По моему опыту, комментарии в большинстве случаев наоборот свидетельствуют об архитектурных ошибках и костылях. Исключением являются лишь пояснения к сложным алгоритмам и документирование интерфейсов.
Как по мне, комментарии в коде напрямую не свидетельствуют о том, что есть архитектурные ошибки. Они свидетельствуют о ценностях команды и принципах работы на проекте.
Сами костыли свидетельствуют об этом — это факт :) а комментарии не при чём.
Сами костыли свидетельствуют об этом — это факт :) а комментарии не при чём.
Да, если есть комментарий в коде, значит код не достаточно отвечает на вопрос о том, что в нем происходит, так что идеальный код — это код, который можно понять без единого комментария. Исключение — когда коммент отвечает не на вопрос «что здесь происходит?», а на вопрос «почему происходит именно это?». В бизнес-логике сплошь и рядом приходится писать комменты вида: «Вот этот БРЕД тут происходит потому, что приходится учитывать условия маркетинговой акции, которая завязана на фазу луны и первую букву отчества пользователя».
Земляки, хотелось бы больше конкретики и примеров.
Спасибо за материал, тема, безусловно необъятная, и в одну статью не влезет, есть пара вопросов:
- Вот вы пишете, что аджайл помогает решать проблему техдолга за счёт итераций и дробления скоупа. Но ведь тот же аджайл допускает изменения по ходу дела в пользу лучшего продукта здесь и сейчас. Как быть в такой ситуации? Ведь изменяющиеся постоянно требования в угоду рынку и есть причина отсутствия чёткой реализации и обилия костылей.
- Мне кажется, что часто отменяющийся код хорош тем, что его часто читают разные скорее всего люди. Ведь тот код, который запилили на скорую руку с костылем или без и ушли из него надолго, закопав стюардессу, есть имхо основной источник техдолга и неожиданных эффектов в будущем, наряду с изменяющимися требованиями и нехорошей архитектурой кода, которую почему-то не упомянули. Вы каким-то образом решаете задачу отслеживания долга в таких случаях?
- Куда-то подевалась мать всех костылей — плохая архитектура самого приложения и отдельно взятых модулей. Когда любое расширение несёт за собой боль и страдания. Но при этом вы указали документацию и отсутствие комментариев в коде, что само по себе не является маркером технического долга. Не могли бы вы прокомментировать, как предложенные методы помогут решить вопрос плохой архитектуры?
Спасибо!
В п.2 меняющийся, вместо «отменяющийся». Прошу прощения.
Хоть и не автор, но выскажу свои соображения.
1) Тут мне тоже интересно мнение автора, но на мой взгляд достаточно просто выделять под технический долг часть итерации. Аджайл это же не про то что стелимся всегда под желания заказчика и тут же откладываем что то важное если новая хотелка появилась.
2) Часто меняющийся код может означать две вещи: в нем много ошибок, тогда технический долг очевиден, либо же просто важную часть решения, но тогда это повод обратить внимание на архитектуру этого места и подумать над улучшением, чтобы в дальнейшем еще меньше проблем было. В случае же не меняющегося кода ситуация такова: код пусть и костыльный, но рабочий, а значит его можно и не трогать, поскольку наша же цель сделать архитектуру и продукт достаточно хорошими, а не идеальными. А если код недостаточно хороший, то возвращаемся к тому что в нем будут ошибки, а соответственно он перейдет в категорию кода который трогают часто.
3) Комментарии и документация это не маркер тех. долга, а маркер что на эти места следует обратить внимание, и возможно они являются техническим долгом.
P.S. Ну и не забываем что аджайл на то и аджайл, что здравый смысл превыше формальных вещей каких то, так что если все видят что маркера тех. долга нет, но считают что он есть — значит считаем что тех. долг есть на самом деле и плюем на формальные признаки.
P.P.S. Сам не сварщик, маску на свалке нашел (ни разу не менеджер, просто немало про аджайл на хабре пишут и в подкастах говорят, хочешь не хочешь наслушаешься)
1) Тут мне тоже интересно мнение автора, но на мой взгляд достаточно просто выделять под технический долг часть итерации. Аджайл это же не про то что стелимся всегда под желания заказчика и тут же откладываем что то важное если новая хотелка появилась.
2) Часто меняющийся код может означать две вещи: в нем много ошибок, тогда технический долг очевиден, либо же просто важную часть решения, но тогда это повод обратить внимание на архитектуру этого места и подумать над улучшением, чтобы в дальнейшем еще меньше проблем было. В случае же не меняющегося кода ситуация такова: код пусть и костыльный, но рабочий, а значит его можно и не трогать, поскольку наша же цель сделать архитектуру и продукт достаточно хорошими, а не идеальными. А если код недостаточно хороший, то возвращаемся к тому что в нем будут ошибки, а соответственно он перейдет в категорию кода который трогают часто.
3) Комментарии и документация это не маркер тех. долга, а маркер что на эти места следует обратить внимание, и возможно они являются техническим долгом.
P.S. Ну и не забываем что аджайл на то и аджайл, что здравый смысл превыше формальных вещей каких то, так что если все видят что маркера тех. долга нет, но считают что он есть — значит считаем что тех. долг есть на самом деле и плюем на формальные признаки.
P.P.S. Сам не сварщик, маску на свалке нашел (ни разу не менеджер, просто немало про аджайл на хабре пишут и в подкастах говорят, хочешь не хочешь наслушаешься)
- По опыту в большинстве проектов фиг кто даст выделить время и отдать часть итерации под техдолг. Почему-то считается, что это вообще не проблемы бизнеса. Мы пробовали разные сценарии: парко-хозяйственный день, когда 20% итерации идёт на техдолг (не очень работает), технологические итерации, когда команда между проектами целую итерацию делает только техдолг и инженерные задачи ( реально работает, но крайне непросто убедить бизнес пойти на это). Аджайл в идеальном мире действительно не про это, но в реальном мире часто все идёт именно по пути замены требований по пути. Тоже самое касается внесения новых задач в уже стартанувшую итерацию. Интересен именно нехороший сценарий.
- Выходит, что признание долгом долга вещь сугубо субъективная, я верно понял? Т.е. в задах системы живет пачка овнокода, но поскольку она работает и жить не мешает — она признается нормой?
- Вспомнилось «highly likely”:))) Документация часто сама является техдолгом, потому как написать-написали, а поддерживать забыли:))
Про аджайл спорить не буду, до не тот топик.
технологические итерации, когда команда между проектами целую итерацию делает только техдолг и инженерные задачи ( реально работает, но крайне непросто убедить бизнес пойти на это)
У нас не сработало. В частности потому, что если три итерации делается «бизнес» из говна и спичек, при экономии не только на спичках, но и на говне, с аргументацией «надо дать бизнесу ценность СЕЙЧАС, а на тех-итерации поправите и сделаете по уму», то к тех-итерации подходишь со слоем костылей, который вырос еще на одном слое костылей, под которыми тоже не все слава богу. И переделать за одну итерацию то, что говняколось три нет никакой возможности, в лучшем случае причесать слегка, что б самый страшный ужас наружу не лез.
Sign up to leave a comment.
Технический долг на проекте или выбраться из черной дыры