Подскажите литературу для курсовой работы
Тема курсовой такая: «Работа с современными системами контроля версий для групповой разработки программных продуктов».
Книги по основах работы с Git, CVS, SVN, Mercurial — это само собой. А вот что стоит почитать, чтобы раскрыть именно плюсы/минусы использования этих систем именно для групповой разработки? О чём стоит упомянуть?
Буду очень благодарна за любую помощь. Первый раз пишу курсовую, а от руководителя какой-либо помощи ждать не приходится... Пытаюсь вот без него разобраться, как и о чем писать...
P.S.: Литературу можно на английском/украинском/русском языках.
6 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівНечего тут разбираться. )))
Основная задача — получить положительную оценку, выполнив КР.
Главное в КР — писуля «отчет о выполнении КР», а основа любой писули некий план (view, концепт, можно называть как угодно), в вашем случае — задание на КР, содержащее требования к оформлению (а) и требования к содержанию (б).
1) Открываете Word и копируете из (а) титульный лист и перечень разделов, создаете оглавление при помощи соответствующих ср-в Word. Форматируете получившееся в соответствии с (а).
В раздел «литература» вписываете ссылку на конспект лекций/методичку. Преподавателю это будет приятно. Процесс пошел, можно показывать что работа начата. )))
2) Открываете (б), в нем требования к очередному разделу + google, рекомендованную литературу, буквари по VCS и, всенепременно, лекций/методичку. Лепите в отчет то что требуется в требованиях (круто получилось ))) ) в соответствии со своим чувством прекрасного, проверяя что оно не противоречит конспекту/методичке, ставя сноски в раздел «литература». Если преподаватель не упырь — можно позволить себе не согласится с конспектом/методичкой, но аккуратно и в меру ;) ).
3) Перечитываете написанное чтобы оно не сильно противоречило само себе и было складно.
4) повторяете 2) и 3) до исчерпания разделов
5) Проверяете, показываете, исправляете замечания и т.д. до победного конца
Ну и рекомендуется иметь в виду традиционные подводные камни: противоречия в требованиях, уровень знаний преподавателя (вероятнее всего вообще никакой, но возможно и противоположное).
Групповая разработка подразумевает несколькими параллельных потоков разработки. Которые бывают независимые, а бывают основанные друг на друге; бывает, что в фиче Б нужен багфикс из фичи А; потом они все как-то сливаются друг с другом (или сразу, или постепенно). Бывает, что все изменения сразу пихаются в «основную ветку», а бывает, что на каждый чих — своя ветка. Потом поверх всего этого строится какой-то continuous integration, интеграция с багтрекеров, и т.д. и т.п.
Как сделать так, чтобы параллельная разработка не добавляла головной боли? Частично решение лежит только в организационной плоскости («делаем только так, а не иначе»), но множество возможных организационных решений так или иначе основнывается на технических возможностях выбранных инструментов («в git можно вот так, а в svn — только вот эдак»).
Как вариант, можно выбрать свою игрушечную модель процесса разработки (Alice, Bob and Cindy разрабатывают три независимых фичи, каждый в своей ветки, причем <... закончить историю самостоятельно >), и показать, как она реализуется (или не реализуется) с помощью выбранных vcs, какие есть плюсы-минусы, какие есть проблемы.
Все дуже просто гуглиться
biz30.timedoctor.com/...
www.codeproject.com/...
Андрій, дякую. Вже гуглила статті, але саме ці раніше не бачила. Можливо, зможете порадити ще якісь варті уваги книги на тему? В курсовій краще посилатися на книжки, а не на статті в Інтернеті (хоча і статті, безперечно, будуть корисні)...
Я розумію, що це одна із тих ситуацій, коли без практичної частини не обійтися, і значна частина теоретичної складової — це власні висновки, зроблені на основі практичної роботи з Git/CVS/SVN/ще чимось, але кількох стандартних книг типу «Pro Git»; «Version Control with Git»; «Version Control with Subversion»; «Essential CVS» в списку використаної літератури буде замало. =(
Мне кажется что вы понимаете не совсем правильно. Для выполнения практической части вам нужна команда разработчиков и несколько лет времени чтобы попробовать каждую из систем и сравнить ощущения.
Не беритесь объять необъятное, я бы наверное сделал акцент на обработке различных типов файлов (хранятся все, но корректно сравнить, вычленить изменения — проблема) и разрешении конфликтов (два человека изменили один и тот же файл — что происходит).
Вот здесь можно поставить себе Subversion + tortoise и еще что-то, затем смоделировать конфликт, сделать выводы. С Subversion + tortoise все можно сделать на одной машине манипулируя программой уровня Hello word, состоящей из2-3 файлов, с остальными системами — не знаю.