Фёдор К,

AxeleronФёдор К,
Чем ObsoleteAttribute не устраивает?

Это вообще из другой оперы.

У решарпера ещё есть крутая поддержка:

AxeleronРазве что ТС захочет открывать каждый класс и пролистывать, чтобы найти это все 'добро'...

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

ИзопропилTODO - это хорошо, но в ряде случаев видеть то хочется не весь говнокод, а только реально вызываемый

(dot/N)Cover +NUnit и всё-всё можно видеть, чево-каво и как и почему, зачем, как жить дальше )) ещё поднять сонаркуб и кайфовать от +100500 метрик кода.

skyANAот зарплаты каждый месяц, пока не исправил :)

Стёр коммент и всё пучком?

skyANAПул реквест не пройдёт ревью и не получит апрува :)

Офигенная автоматизация процесса разработки

Юнит-тест упал, и ничего никуда не пройдёт автоматически.

Фёдор КСпасибо всем.

Я имел ввиду, чтобы как Обслит глаза мозолил в коде.
Но придется работать со списком задач. В конце-концов это дисциплинирует. :)

С уважением.

Странный кейс какой-то. Если ты написал TODO в коде, значит что-то не доделал, значит что-то будет не работать, или работать не так. Это и без всяких мозолилок будет очевидно.

Аналогом TODO комментов могли бы быть записи в блокнотике на столе, типа: «вернуться к файлу XXXXX/YYYYY/XXXXX/AAAA.cs к строке 2456, допилить эту фигню». Это не более, чем закладка с пояснением, личный инструмент разработчика.

Если так хочется мозолилку, пишешь свой кастомный атрибут типа [VzorviMneMozgAttribute] и один юнит-тест, который будет валиться, если найдёт хоть один такой атрибут. Если тесты не используешь, можно зафигачить билд-таск который будет ворнинги толкать в консоль или вообще валиться с ошибкой, зависит от степени мазохизма

skyANAЮнит-тест упал из-за стёртого комментария?

Нет, тест упал, потому что метод работает не так как надо. На комментарии вообще пофигу

skyANAпроблема в том, что это "г-код без обработок иксепшнов, оптимизаций и др".




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


skyANAТо есть таки нужно code review при pull request-ах

А у вас есть code review по комментариям?

skyANAу нас есть code review pull request-ов

Я вообще-то не об этом спросил. Ну да ладно, видимо это секрет

skyANAhVostt, мне не интересно выяснять, что такое code review по комментариям, я написал какое оно у нас. Никаких секретов.

Не хочешь отвечать, и не надо. Никто же тебя не принуждает.
Но дурака-то зачем включать? Просто по приколу?

П.С. «мне не интересно выяснять» — это конечно требует IQ over 10000, особенно, когда ты сам об этом же и писал...

skyANAhVosttСтёр коммент и всё пучком?
Пул реквест не пройдёт ревью и не получит апрува :)

skyANAИ если видно, что удалили комментарий вида "поправить говнокод", а в самом говнокоде ни строчки не изменилось, то тупо decline с комментарием: "таки надо поправить".

Ну вот в этом и была суть вопроса, наконец-то :)


skyANAОчевидно же, если ты конечно знаешь, что такое pull request и code review :)

Не понимаю при чём тут pull request, вопрос состоял в том, обращают ли внимание во время code review на комментарии типа TODO, или нет. А когда это review происходит вообще фиолетово, хоть в полнолуние.

skyANAЛюбое изменение в коде - это pull request.

Это смотря куда.

skyANAhVostt, смотря куда pull request? А есть варианты?

В master pull request, в остальные ветки — зачем?

skyANAа для тебя это было секретом? Странно, это же элементарная логика

Я уже объяснял свою позицию: TODO комментарии это личный инструмент разработчика, нечего ревьюверу на них смотреть.


skyANAhVosttВ master pull request, в остальные ветки — зачем?о чем ты?

Не знаешь, что такое ветки? :)

Про Git-Flow что-нибудь слышал?

skyANAну для тебя личный, а для нас нет

Это понятно, именно это я выяснял у тебя.

skyANAЗачастую TODO комментарии появляются потому, как разработчик договорился с ревьюверами, что поправит данное место в такой-то версии, или после того как сделает то-то.

Ну вот, спасибо за ответ.


skyANAЧто такое ветки и в меркуриале и в гите знаю, о Git-Flow слышал. Прямо объясни, к чему ты это упомянул?

О том, что продуктивная ветка master, в остальные можно пуллить без пулл реквестов, я об этом.

skyANAПонял тебя. Но у нас feature per branch и все наоборот.

Небольшая команда в отдельной ветке пилит свою фичу. Отдельный разработчик делает себе ветку для реализации отдельной истории (Story), или задачи (Task), или багфикса.
Соответсвенно из своей ветки в ветку фичи pull request, что ревьювится внутри команды.
А в мастер уже сливается готовая фича, или не сливается, если команда не успела запилить её к текущему релизу :)

Прикольно, чисто по-человечески такая модель выглядит очень логично.

Но при интенсивной «агильной» CI разработке мы нашли, что git-flow гораздо эффективней:

origin/develop -- это ветка и стенд, куда пулятся изменения для текущей итерации

feature/sss-xxx - это фичи-бранчи (sss-xxx номер таска в джире), при чём:

origin/feature/sss-xxx -- long story фичи, которые разрабатываются усилиями нескольких разработчиков и под неё может даже подниматься стенд (довольно быстро)

local/feature/sss-xxx -- short story фичи и багфиксы, которые разрабатываются усилиями одного разработчика в рамках одного-двух раб. дней максимум, затем сразу сливаются в develop не порождая новой ветки. если вдруг выясняется, что это вовсе не short, то ветка создаётся пуллом.

origin/release/x.x.0 -- ветка и стенд стабилизации версии, где собственно и происходит ревью и отработка замечаний, юнит- и интеграционное тестирование и отработка QA тест-планов. собирается из develop. все пуллы в эту ветку, только через реквест.

origin/hotfix/x.x.x -- ветка и стенд для хотфиксов, пуллы только через реквест. обычно не живёт больше одного-двух дней.

origin/master -- выливается стабилизированная версия из release или хотфиксы из hotfix.

такая модель прекрасно себя показывает долгое время.

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

skyANA,

да во всём. что конкретно интересует?

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

я сравниваю, и git-flow получается по всем параметрам эффективней для CI, так как есть опыт работы по другим моделям, включая feature per branch (ещё на старом добром Mercurial).

но понятно, что ещё всё зависит от проекта и команды, но тут уже рассуждать надо в контексте таких проектов.

skyANA,

если мы каждый пулл в ветку разработки будем принимать только через реквест и аппрувить-деклайнить его, то КПД разработки упадёт в разы, и не думаю, что это сильно отразится на качестве результата.