Комментарии 18
Интересная вещь. Можете поподробнее рассказать как вы работаете с такими комментами: н-р номер строки меняется (тут понятное дело можно сравнить по содержимому), коммент на той же строке меняется (заменяем?) а если оба?
Вообщем тема очень интересная.
Вообщем тема очень интересная.
Поздравляю с победой. Проект очень и очень интересен. Одна просьба (или, может, вопрос?): подскажите будете ли вы добавлять поддержку других репо кроме гитхаба (как это следует из этого: «Log in with Github and choose your repository.»)? Или может я чего-то не понимаю и проект уже сейчас можно утащить и попробовать, например с локально установленным Stash?
Похоже, для этого есть в футере специальная ссылка, ведущая сюда
Ну, может и так.
Насчет багов — не судите нас строго, мы всего лишь двухдневный проект, сделанный в безумной спешке. В ближайшие дни и месяцы будем приводить все в классный и удобный вид и ваши багрепорты, отправленные сюда, нам сильно в этом помогут.
Насчет багов — не судите нас строго, мы всего лишь двухдневный проект, сделанный в безумной спешке. В ближайшие дни и месяцы будем приводить все в классный и удобный вид и ваши багрепорты, отправленные сюда, нам сильно в этом помогут.
Судя по всему, тестеры для другого техпроцесса, а CodeNotes для другого. Минусы есть, плюсы, но всё по другому. Я вот свой фреймворк пишу, и у меня личного тестера нет.
Даю идею. Тестер описывает багу в BDD стиле:
[я] в роли пользователя
[хочу] сохранить задачу в форме Х
[чтобы] она отобразилась в форме Y
а CodeNotes генерирует тест заглушку и добавляет в код. Проект собирается, тест не проходит, разработчикам улетает информация на мейл.
[я] в роли пользователя
[хочу] сохранить задачу в форме Х
[чтобы] она отобразилась в форме Y
а CodeNotes генерирует тест заглушку и добавляет в код. Проект собирается, тест не проходит, разработчикам улетает информация на мейл.
К сожалению не все задачи можно (и необходимо) описывать на уровне кода. Всегда хочется иметь единое место для работы с задачами. Как вы будете подходить к описанию проблем/запросов изменений, которые затрагивают несколько больших компонентов? Или в случае когда необходимо провести исследование, скажем, производительности и отразить его результаты?
Возможно, будет возможность создания задач из веб-интерфейса.
Пока мы размышляем над возможными сценариями и путями решения. Конечно, CodeNotes вряд ли подойдет для абсолютно полной замене Jira в любых проектах, но есть целый ряд проектов, в которых мы сможем упростить и улучшить процесс разработки.
Пока мы размышляем над возможными сценариями и путями решения. Конечно, CodeNotes вряд ли подойдет для абсолютно полной замене Jira в любых проектах, но есть целый ряд проектов, в которых мы сможем упростить и улучшить процесс разработки.
На правах мнения:
Задача получения информации решается многими средствами. Примерами могут служить инструменты измерения покрытия кода тестами, статического анализа (pmd, findbugs, checkstyle) и развитие этой идеи до продуктов уровня sonar/fortify.
Если подумать в этом направлении ещё немного, то у меня получается следующее: источником огромного количества информации является код. С этим ничего не поделаешь (и это _отражает_ реальность). Часть информации приходит в код извне (требования (всех уровней), технические решения (что-то делаем так, а не иначе)). Так вот, «внешнюю информацию» можно пытаться «отразить в коде» (как мне кажется это выбранный вами подход), а можно пытаться делать средства для сопоставления «кода» и этой «внешней информации».
С моей точки зрения второе интереснее, т.к. во первых задача становится более четкой (как сопоставить информацию A, B, C с местами в коде X, Y, Z), во-вторых код остается «чистым».
Что думаете?
Задача получения информации решается многими средствами. Примерами могут служить инструменты измерения покрытия кода тестами, статического анализа (pmd, findbugs, checkstyle) и развитие этой идеи до продуктов уровня sonar/fortify.
Если подумать в этом направлении ещё немного, то у меня получается следующее: источником огромного количества информации является код. С этим ничего не поделаешь (и это _отражает_ реальность). Часть информации приходит в код извне (требования (всех уровней), технические решения (что-то делаем так, а не иначе)). Так вот, «внешнюю информацию» можно пытаться «отразить в коде» (как мне кажется это выбранный вами подход), а можно пытаться делать средства для сопоставления «кода» и этой «внешней информации».
С моей точки зрения второе интереснее, т.к. во первых задача становится более четкой (как сопоставить информацию A, B, C с местами в коде X, Y, Z), во-вторых код остается «чистым».
Что думаете?
Во-первых, внешнюю информацию мы пока никаким образом не отражаем в коде. Скорее наоборот, мы генерируем из кода эту самую информацию. Но вы правы, это чуть ближе к нам, чем сопостовление внешней информации с информацией в коде.
Во-вторых, предложенный вами подход интереснее, но существенно сложнее и с трудом поддается автоматизации, на мой взгляд. То есть единственное решение — сопоставить информацию в задаче с тем, что есть в коде вручную, но это добавляет лишь дополнительных проблем и замедляет сам процесс работы.
Во-вторых, предложенный вами подход интереснее, но существенно сложнее и с трудом поддается автоматизации, на мой взгляд. То есть единственное решение — сопоставить информацию в задаче с тем, что есть в коде вручную, но это добавляет лишь дополнительных проблем и замедляет сам процесс работы.
У меня это уже давно сделано в emacs
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CodeNotes — победитель Clojure Cup 2013