Anatoly
тасктрекер, вики и прочие источники информации устареют и там нихера не будет
Anatoly
они ещё сменятся три раза
Doge
тасктрекер, вики и прочие источники информации устареют и там нихера не будет
Работает очень хорошо, я так на 10+ летней кодовой базе спокойно искал всё, что мне нужно
Anatoly
блейм - прекрасная замена комментарию, всегда показывает ход мысли, ага
Doge
блейм - прекрасная замена комментарию, всегда показывает ход мысли, ага
Он позволяет найти номер задачи в которой были эти правки изначально
Anatoly
Работает очень хорошо, я так на 10+ летней кодовой базе спокойно искал всё, что мне нужно
ни разу не было, что за эти пять лет тасктрекер сменился? структура проектов сменилась и таски были отправлены в утиль?
Anatoly
ну вот просто типа номер тикета есть, а по нему никакой инфы больше нет
Doge
ни разу не было, что за эти пять лет тасктрекер сменился? структура проектов сменилась и таски были отправлены в утиль?
Нет, вся информация сохранялась.
Doge
Ни разу не было
Romɑn
Везет тебе
Romɑn
у меня 3 года проекту сменили пару джир
Doge
Ну терять инфу в таск трекере - это проблема сама по себе
Romɑn
в коммитах ссылка на таски а тасок-то и нет
Anatoly
Ну терять инфу в таск трекере - это проблема сама по себе
дождь на улице и экскаваторы, перекапывающие оптику - это проблема само по себе. Однако люди покупают зонты и резервируют каналы
Romɑn
тут проблема не ИТ, а бизнесовая, пока бизнсе понял, что не нужно платить рукожопам в 6 рах дороже прошло 3 года
Doge
Ну видимо мне везло работать в командах, где к таск трекеру и вики относились ответственно в плане сохранности данных
Romɑn
И у каждой свой таск трекер?
считай, что да. Наш таск трекер появился когда стало предыдущая команда не стала давать нам доступ к свеой инфраструктуре с джирой. Только ридонли доступ.
Romɑn
Ну видимо мне везло работать в командах, где к таск трекеру и вики относились ответственно в плане сохранности данных
тут проблема не команд, а бизнеса с аутсорсерами
Romɑn
не все можно контролировать)
зато можно оставить комментарий
Anatoly
Ну видимо мне везло работать в командах, где к таск трекеру и вики относились ответственно в плане сохранности данных
есть ещё опенсорс проекты, у которых тасктрекер то тут, то там. а код вот он всегда
Anatoly
зачем мне открывать новое окно где-то там, чтобы прочитать доку по дизайну софта, если вы её можете прямо в исходник положить?
Anatoly
какую пользу она принесёт в мёртвом тикете со статусом DONE?
Anatoly
или, чтобы прочитать код и разобраться в нём, мне надо три монитора? на одном код, на втором блеймы и история, на третьем таск-трекер с вики?
Doge
не все можно контролировать)
зато можно оставить комментарий
У меня просто с комментариями был наоборот негативный опыт в плане актуальности информации.
Это опять-таки возвращаясь именно к desing comment'ам те же. Где в них написано одно, а потом идёт что-то совершенно левое, потому что при очередном рефакторинге на эти описания народ забивал совершенно.
А в задачах с номерами хотя бы видна история почему были рефакторинги и правки около.
Крылатый
какую пользу она принесёт в мёртвом тикете со статусом DONE?
А в тикете одно поедложение и то не связанное
Крылатый
Крылатый
И переписки нет
Крылатый
Кучу раз натыкался.
Крылатый
Бесит, пиздец, когда разгребаешь потом говно.
Anatoly
вот это меня всегда радует. 15 вложенных ифов мы на ревью поймаем, а обновление документации в том же файле - нет
Anatoly
я тут узнал, кстати, что у Dependabot (который сканит на уязвимости зависимости ваши) есть лимит 20 dependency sources/repo
Anatoly
то есть, если у вас 21 csproj, то один из них не будет проверен примерно никогда, если только вы не обратитесь в поддержку гитхаба
Anatoly
при этом, иногда у них случаются проблемы с кешем, и вот вы год назад уже удалили файл проекта, а в нём всё ещё находятся уязвимые зависимости. единственный способ это исправить - опять же обратиться в поддержку гитхаба
Bonart
Не для оправдания, но к такой практике приложили руку некоторые адепты чистого кода типа дяди Боба, напирая на то, что хороший код сам себя документирует.
Ну это правда примерно наполовину. По мне обильно документировать надо контракты, а в коде - те места, в которых из самого кода не понятно, зачем вообще так сделано
Bonart
Еще обязательно нужны комментарии к коммитам, сами коммиты должны быть атомарными и иметь ссылки на задачи в трекере
Bonart
Тогда при исследовании и правда можно узнать, почему и нафига было сделано так, а не иначе
Sergey
Коммит под задачу это сильно
Bonart
Коммит под задачу это сильно
Атомарный коммит - это не коммит под задачу. Обычно одна задача - много коммитов
Sergey
А ну ок неверно понял
Vasily
Ох епт
Vasily
Бонарт галерный опыт тащит
Bonart
Бонарт галерный опыт тащит
Ну что ты сразу приговоры раздаешь. Как раз на галерах это профанируют
Bonart
Я этот процесс в полном объеме и реальной практике увидел как раз на антигалере
Anatoly
коммит атомарен по определению. видимо туда какое-то дополнительное требование вкладывается.
Evgen
можно обобщить это так - если код логичный, то его не нужно документировать, документировать нужно костыли
Не согласен, что комментировать стоит только костылированый код. Часто код не содержит пояснения того зачем то или иное решение было выбрано и какие существуют трейдофы. Комменты полезны для запутанных вещей, что бы не компилировать всё в голове 3 часа, можно прочесть коммент и гораздо быстрее вкатится в суть
Vagif
Еще обязательно нужны комментарии к коммитам, сами коммиты должны быть атомарными и иметь ссылки на задачи в трекере
Можешь пояснить про атомарные коммиты?
Vagif
Что значет неатомарный коммит?
Bonart
Что значет неатомарный коммит?
Несколько логических изменений в одном коммите. Например, разработчик поменял настройки, отрефакторил в одном месте, переформатировал код, добавил новый - и все зафигачил в один коммит
Vagif
Ayrat
Doge
ничоси. Это скорее редкость и я не верю
В таск трекере на несуществующую задачу я там ни разу не натыкался.
Roman
В таск трекере на несуществующую задачу я там ни разу не натыкался.
даже если весь таск трекер сохранился, качественно велся и все такое — пройти эту цепочку в blame -> commit -> PR -> task и прочитать ее все равно гораздо длиннее и когнитивно затратней, чем прочитать коммент, который прям тут в коде.
+ Для добропорядочного ведения и сохранения таск трекера нужно организовать гораздо больше людей, чем для нормальных комментов
Doge
даже если весь таск трекер сохранился, качественно велся и все такое — пройти эту цепочку в blame -> commit -> PR -> task и прочитать ее все равно гораздо длиннее и когнитивно затратней, чем прочитать коммент, который прям тут в коде.
+ Для добропорядочного ведения и сохранения таск трекера нужно организовать гораздо больше людей, чем для нормальных комментов
Комментарии ещё нужно поддерживать в актуальном состоянии и далеко не все информация в них хорошо передается.
Те же схемы ты не будешь же в комментариях рисовать
Roman
схемы да, но я никогда не натыкался на их необходимость в комментах
Bonart
даже если весь таск трекер сохранился, качественно велся и все такое — пройти эту цепочку в blame -> commit -> PR -> task и прочитать ее все равно гораздо длиннее и когнитивно затратней, чем прочитать коммент, который прям тут в коде.
+ Для добропорядочного ведения и сохранения таск трекера нужно организовать гораздо больше людей, чем для нормальных комментов
Дело в том, что комментарий в коде легко устаревает. И все, что есть в комментарии коммита и трекере в комментарий к коду пихать и нереально и бессмысленно
Doge
схемы да, но я никогда не натыкался на их необходимость в комментах
Ну это речь про те же кейсы со сложной бизнес логикой
Roman
Мне они нужны были для костылей и странностей домена
Vagif
Мне лично очень неудобно, когда комментарии лишь отсылают куда-то еще. Не только потому что "это еще" может потеряться, но и потому что код становится не самосодержательным
Roman
Roman
к тому же, дату можно и по блейму понять)
Bonart
Мне лично очень неудобно, когда комментарии лишь отсылают куда-то еще. Не только потому что "это еще" может потеряться, но и потому что код становится не самосодержательным
Ну код - это всего лишь снапшот конкретной версии системы. Т.е. комментарий конечно хорошо опишет статику, но не динамику изменения кода
Vagif
Ну код - это всего лишь снапшот конкретной версии системы. Т.е. комментарий конечно хорошо опишет статику, но не динамику изменения кода
Именно поэтому стоит делать снапшот содержательным. Динамика развития - это уже к внешним системам, а комментарии кода помогают понять то, как это работает сейчас.
Anatoly
Anatoly
Дело в том, что комментарий в коде легко устаревает. И все, что есть в комментарии коммита и трекере в комментарий к коду пихать и нереально и бессмысленно
комментарий в коде устаревает только если ревьювер щёлкает клювом
Doge
.net команда справляется как-то
Ну тут их не очень корректно сравнивать со средней командой в среднем проекте.
Anatoly
Doge
Ресурсов людских столько нет + куда более жесткие сроки обычно
Anatoly
И получаешь костыльный эрзац комментария коммита
комментарий коммита не доступен в момент чтения кода
Doge
комментарий коммита не доступен в момент чтения кода
Ну если комментарий нужен для каждого участка кода - то с кодом точно что-то не так.
Речь же тут шла про места, где какая-то ощутимо неочевидная логика по тем или иным причинам.
Doge
А там уже посмотреть в историю и т.п. - это не очень большой даунтайм
Anatoly
Ну если комментарий нужен для каждого участка кода - то с кодом точно что-то не так.
Речь же тут шла про места, где какая-то ощутимо неочевидная логика по тем или иным причинам.
я крайне рекомендую ссылку открыть и почитать
Doge
я крайне рекомендую ссылку открыть и почитать
Там всё примеры вокруг системного сишного кода, что имеет свои особенности.
Те же design доки в обычном бизнесовом коде относительно бесмысленные будут, потому что дизайн везде одинаковый и очевидный в подавляющем числе случаев.
Vagif
комментарий коммита не доступен в момент чтения кода
Вот да. Меня еще фшапр испортил, привык читать все последовательно, как книгу.