Комментарии 11
Добро пожаловать в 2013.
Помимо этого полезно упомянуть еще системы для автоматического построения билдов. Без этого сейчас никуда, как минимум CI стоит внедрять. В команде из 3-4 человек это уже будет полезно.
Тулов очень много — TeamCity, Jenkins, Go, MSBuild и т.д. Вообще много работал с TeamCity для небольших коммерческих проектов в самый раз. Недавно решил еще заценить Go от ThoughtWorks
Тулов очень много — TeamCity, Jenkins, Go, MSBuild и т.д. Вообще много работал с TeamCity для небольших коммерческих проектов в самый раз. Недавно решил еще заценить Go от ThoughtWorks
Ну как-то совсем мало. Почитайте тест Джоэла Спольски, датированный 2000 годом.
Я как-то не понял, а где в этой статье, собственно, инструменты для командной разработки?
SVN, по-вашему, таковым не является?
Это статья, в которой говорится, что существует SVN и Notepad++? Для таких объёмов информации есть твиттер.
UPD: Поясню, от статьи с таким заголовком ожидается увидеть множество названий, и для каждого — назначение, возможности, цены, плюсы и минусы, собственный опыт работы, а также возможные связки приведенных инструментов.
UPD: Поясню, от статьи с таким заголовком ожидается увидеть множество названий, и для каждого — назначение, возможности, цены, плюсы и минусы, собственный опыт работы, а также возможные связки приведенных инструментов.
Я разве где-то в статье говорил, что перечислю все инструменты? Или она называется «Все инструменты для командной разработки»?
Вместо того, чтобы минусовать бессмысленно, лучше бы по делу что-нибудь добавили…
Вместо того, чтобы минусовать бессмысленно, лучше бы по делу что-нибудь добавили…
По делу здесь можно добавить статью про инструменты командной разработки. Она должна быть между заголовком и разделом с комментариями, там, где сейчас три абзаца ни о чем.
Вы получаете минусы за то, что написали статью очень низкого качества. Настолько, что и статьёй это назвать тяжело. Поэтому, во избежание дальнейших минусов рекомендую убрать ее в обратно в черновики. Если вам все же хочется написать статью на эту тему, то добавьте еще раз 40 по столько же текста, добавьте скриншоты, расскажите про свой опыт работы с различными инструментами, как это помогло командной работе, насколько эти решения масштабируются на большие команды.
А если кроме SVN и Notepad++ вам написать не о чем, то вам не стоит пока писать статьи для хабра на эту тему.
Вы получаете минусы за то, что написали статью очень низкого качества. Настолько, что и статьёй это назвать тяжело. Поэтому, во избежание дальнейших минусов рекомендую убрать ее в обратно в черновики. Если вам все же хочется написать статью на эту тему, то добавьте еще раз 40 по столько же текста, добавьте скриншоты, расскажите про свой опыт работы с различными инструментами, как это помогло командной работе, насколько эти решения масштабируются на большие команды.
А если кроме SVN и Notepad++ вам написать не о чем, то вам не стоит пока писать статьи для хабра на эту тему.
Комментарий на правах feedback-a…
Для такого названия поста слишком несистемно представлена информация, больше похоже на обрывки мыслей. Значительно ценнее опыт применения для решения конкретных задач, желательно с указанием особенностей проекта(ов), «граблей», на которые Вы наступили, и находках (нестандартные варианты использования, например), которые позволили получить синергетический эффект от использования, пусть даже в Вашем конкретном проекте.
Мы у себя, например, два года выстраивали процессы коллективной разработки распределенной команды программистов (два офиса в Москве, один в Дубне). Используем, собственно, описанные Вами инструменты: redmine, svn и др. Думаю, принципиально ничего бы не поменялось, если бы вместо redmine был trac, а вместо svn — git. Само сложное и основное было правильно выстроить процессы. Использование конкретных инструментов — дело вторичное. Если нечего автоматизировать, то можно и кучу денег вбухать в коммерческие инструменты — работа не станет эффективнее.
Делитесь реальным опытом и люди к Вам потянутся!:)
Удачи.
Для такого названия поста слишком несистемно представлена информация, больше похоже на обрывки мыслей. Значительно ценнее опыт применения для решения конкретных задач, желательно с указанием особенностей проекта(ов), «граблей», на которые Вы наступили, и находках (нестандартные варианты использования, например), которые позволили получить синергетический эффект от использования, пусть даже в Вашем конкретном проекте.
Мы у себя, например, два года выстраивали процессы коллективной разработки распределенной команды программистов (два офиса в Москве, один в Дубне). Используем, собственно, описанные Вами инструменты: redmine, svn и др. Думаю, принципиально ничего бы не поменялось, если бы вместо redmine был trac, а вместо svn — git. Само сложное и основное было правильно выстроить процессы. Использование конкретных инструментов — дело вторичное. Если нечего автоматизировать, то можно и кучу денег вбухать в коммерческие инструменты — работа не станет эффективнее.
Делитесь реальным опытом и люди к Вам потянутся!:)
Удачи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инструменты, которые мы используем для командной разработки