[Uladzimir 60]

Цитата(Rst7 @ Oct 23 2014, 11:04) *

- Взял в привычку складывать рядом с файлами-исходниками проекта всякие даташиты, небольшие утилитки, и коммитить их тоже. Зато потом организация рабочего места на любом компьютере при наличии интернета производится за полчаса - вытаскиваем SVN-клиента, идем в закрома, вытаскиваем необходимый компилятор, делаем checkout, весь джентльменский для продолжения работы над проектом уже есть.

 

....

 

Современный сложный проект встраиваемой системы на любом рабочем столе не открыть. Там одна модель дивайса в SolidWorks может под гигабайт занимать, Altium с библиотеками тоже гигабайты.

Надо иметь всегда с собой свой компьютер.

SVN получается годен только для чего то мелкого или частного.

Ну уж если Алтиум.

у мене несколько таких SVN. Не моих. Чужих. Где я маленькая шестеренка.

Люди складывают в проекта папки с кодом, с программами, с описаниями, с механикой и черте чем еще. + все старые ревизии, которые дошли до "железа"

Там "Altium с библиотеками тоже гигабайты" выглядит мелкой сошкой на фоне хранимых объемов.

Если скачивать все--по первому разу (что в общем не требуется, для пользователя достаточно только нужные ему).

 

Так что я бы сказал ровным счетом наоборот, чем "SVN получается годен только для чего то мелкого или частного"

 

[spf 0]

"как корабль назовёте, так он и поплывёт", в топике "тупой" - лишнее.

 

Банальный тролинг прогрессирует.

 

"У меня кардинальные изменения приводят как правило к измененинию имени файла.

Почаще менять имена файлов один из способов хорошо держать в голове контекст."

 

По всей видимости попросту заняться нечем, раз доходит до таких очковтирательств.

[ViKo 1]

Про административно командный метод. Может, вам везет, но я не встречал руководителей, хотя были разные, хорошие тоже попадались, которые по своей воле решились бы что-то изменить. "Работает, и ладно". Они пока не потонут в накопившемся хламе прошлого, будут за него цепляться. А так, да, в идеале хорошо бы внедрить систему сквозного проектирования, перекидываться электронными записками, архивировать на сервере, контролировать версии и т.п. Лучшее, что я могу сделать - забить на всё, делать по-своему, рассчитывать только на себя и свои компьютеры. Лично мне, как боевой единице, части проектов сливать не нужно, дерево версий демонстрировать некому, по-большому счету, что и как будет работать, я сам определяю, как и где и в каком виде хранить.

[des00 25]

Начинал с SVN, сейчас переполз на Меркуриал. Поддерживаю порядка 5 проектов + участвую в разработке 5 проектов. Над проектом работает команда ~3 человека. У меня 3 рабочих места. Без системы контроля версий голова давно бы уже опухла.

 

ЗЫ. Когда работал один тоже использовал систему контроля версий. При экспериментах в реализациях было порядка 3-4 веток, по окончании экспериментов нужные вещи мерджились в основную ветку, при этом всегда можно было вернуться к любому состоянию проекта.

[vitan 2]

У меня бабушка, живущая в деревне, до сих пор не понимает зачем ей водопровод в доме

У бабушки есть свои соображения. Она прекрасно понимает, что в доме иметь воду будет комфортнее (ну она, все-таки, человек с головой). Но еще она понимает, во что ей выльется проведение воды. Это выльется как минимум в изменение ее собственного дома. И еще она понимает, что это выльется в более серьезные изменения в масштабах всей деревни. Она понимает, что где-то построят мощную водонапорную станцию (а где? не у меня ли под боком?). Она понимает, что это затянется не на один год, и все это время по деревне будут сновать грузовики, копать экскаваторы, а заезжие гопники-гастарбайтеры устроят ей сладкую жизнь.

Я хочу сказать не то, что она, якобы видит, что это "не выгодно" и игра не стоит свеч. Я хочу сказать, что она понимает, что в этом случае рухнет привычная жизнь и деревня будет уже не той, что раньше. Да и деревней уже это сложно будет назвать.

Это просто привычка, инерция. У некоторых - осознанное желание.

Привычка свыше нам дана: замена счастию она.

Это не плохо и не хорошо, это просто так есть.

По всей видимости попросту заняться нечем, раз доходит до таких очковтирательств.

Согласен, для мозга можно найти гораздо более приятные занятия.

 

А между тем даже приблизительно не можете оценить эффект от применения контроля версий.

Ну а как мне оценить эффект от проведения водопровода в деревенском доме (с учетом вышеописанных артефактов)? Да, согласен, я не могу провести количественную оценку. Я не профессиональный менеждер проектов, я не веду метрики, не считаю эффективность применения рабочей силы, бюджеты, прибыль, и дебет с кредитом не свожу. Я говорю, что мне понравилось копать экскаватором, и я без сожаления бросил лопату, только и всего.

Хотите цифр - обратитесь к специалистам, уверен, что найдется куча народу, которая Вам расскажет, как они успешно ввели те или иные средства повышения производительности труда. Я не вводил, я агитировал и добивался того, что люди сами потом захотели перестроиться.

 

Про велосипед совершенно негодная метафора. Ну вот причем здесь велосипед?

Ну обычно его вспоминают, когда видят попытки по-своему решить задачу, которая уже решена общепринятым способом.

 

Контроль версий это можно сказать ненужная сложность по Бруксу.

Можно так сказать. Только верно ли это утверждение? И где доказательство?

 

А также поклонник 1-го принципа Agile: люди и взаимодействие важнее процессов и инструментов.

Вы, видимо, не до конца его понимаете. Суть не в том, что можно пренебрегать процессами и инструментами, а в том, что без людей и их взаимодействия не будет развития. Процессы и инструменты отражают ситуацию в статике, а люди (взаимодействующие) являются движущей силой для развития. Т.е. люди должны не отрицать процессы и инструменты, а должны отталкиваться от них в поисках лучшего. Но если они скажут, что видят прогресс в отказе от инструментов и процессов, то они будут неправы.

Да, они могут отказаться от чего-то одного, но взамен должны будут _обоснованно_ предложить другое. То, что по их мнению, будет лучше прежнего.

Ну и что Вы предлагаете? Помнить контекст в голове и сравнивать все тотал коммандером? Обоснуйте тогда, докажите, что это лучше! Что-то мне подсказывает, что тяжеловато Вам придется... :)

 

 

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

Вы даже не представляете, сколько раз я слышал подобные фразы!

 

От меня ничего не зависит. Я винтик. Зачем всё это? Я прекрасно разбираюсь внутри себя самостоятельно. Мои результаты всегда качественны. Улучшать нечего, придуманная мной система организации моего же труда почти совершенна. Да, хотелось бы большего. Хотелось бы использовать компьютер не только в качестве пишущей машинки. Но как только я что-то начинаю, все упирается в соседа, который такой же винтик, как и я. Ради каких-то абстрактных целей я не буду рушить с таким трудом созданную мной внутреннюю организацию. Неизвестно, чем еще все это кончится, скорее всего, ничем, только время потратим, это ж Россия!

 

Продолжать можно долго. Дело просто в желании, ничего более.

Кто не хочет - ищет причину, кто хочет - ищет путь.

[Xenia 35]

Это всё здорово, но только для ситуации один человек - один проект от начала и до релиза.

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

Если программист уволится на середине, то его и за человека считать не надо :). Достаточно будет просто сохранить проект на той стадии, до которой тот его довел, а дальше новый исполнитель поведет его дальше по своему усмотрению. Тем более что именно он будет отвечать за проект, а не тот, кто уволился.

 

В тех же случаях, когда над проектом работают два и более исполнителя, работа должна быть поделена между ними с умом. Т.е. примерно так, как задачу делят на два или более потока. И если из-за такого распаралелливания и возникают определенные неудобства, то это задача периодического объединения работ отдельных исполнителей в одно целое. Обычно такая заадча решается тем, что один из исполнителей назначается главным, на которого и возлагается задача сращивания результатов работ. Он же должен и распределять работы по исполнителям так, чтобы ему потом было легче их сращивать.

 

Скажем, если две швеи шьют один костюм, то будет эффективно, если одна будет шить пиджак, а другая брюки. Но если они начнут срочить обе вещи по очереди, то им пришлось бы в основном заниматься не швейным делом, а писательством в "лист регистрации изменений" :).

 

ИМХО, приучить пользоваться новым инструментом можно двумя путями: тоталитарно-административным либо создать такие условаия, что "нужда сама заставит". И в этот момент подсказать правильный путь, объяснить, как пользоваться и то.

Какая нужда? Кто вообще читает этот "лист регистрации изменений"? Ради какой проверяющей инстанции он пишется? :)

[Xenia 35]

Это всё здорово, но только для ситуации один человек - один проект от начала и до релиза.

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

Если программист уволится на середине, то его и за человека считать не надо :). Достаточно будет просто сохранить проект на той стадии, до которой тот его довел, а дальше новый исполнитель поведет его дальше по своему усмотрению. Тем более что именно он будет отвечать за проект, а не тот, кто уволился.

 

В тех же случаях, когда над проектом работают два и более исполнителя, работа должна быть поделена между ними с умом. Т.е. примерно так, как задачу делят на два или более потока. И если из-за такого распаралелливания и возникают определенные неудобства, то это задача периодического объединения работ отдельных исполнителей в одно целое. Обычно такая заадча решается тем, что один из исполнителей назначается главным, на которого и возлагается задача сращивания результатов работ. Он же должен и распределять работы по исполнителям так, чтобы ему потом было легче их сращивать.

 

Скажем, если две швеи шьют один костюм, то будет эффективно, если одна будет шить пиджак, а другая брюки. Но если они начнут срочить обе вещи по очереди, то им пришлось бы в основном заниматься не швейным делом, а писательством в "лист регистрации изменений" :).

 

ИМХО, приучить пользоваться новым инструментом можно двумя путями: тоталитарно-административным либо создать такие условаия, что "нужда сама заставит". И в этот момент подсказать правильный путь, объяснить, как пользоваться и то.

Какая нужда? Кто вообще читает этот "лист регистрации изменений"? Ради какой проверяющей инстанции он пишется? :)

[vitan 2]

Скажем, если две швеи шьют один костюм, то будет эффективно, если одна будет шить пиджак, а другая брюки. Но если они начнут срочить обе вещи по очереди, то им пришлось бы в основном заниматься не швейным делом, а писательством в "лист регистрации изменений" :).

Именно. Только не забывайте, что без писательства результата они не достигнут никогда, а вот, если займутся им, то - да, результат будет.

На вопрос "когда будет" ответ такой. Заменяете костюм на самолет, а двух швей на авиаконцерн. Самолет появится в строго прогнозируемые сроки. А вот без писательства будут, как ни забавно, только разговоры.

[AlexandrY 3]

Начинал с SVN, сейчас переполз на Меркуриал. Поддерживаю порядка 5 проектов + участвую в разработке 5 проектов. Над проектом работает команда ~3 человека. У меня 3 рабочих места. Без системы контроля версий голова давно бы уже опухла.

 

ЗЫ. Когда работал один тоже использовал систему контроля версий. При экспериментах в реализациях было порядка 3-4 веток, по окончании экспериментов нужные вещи мерджились в основную ветку, при этом всегда можно было вернуться к любому состоянию проекта.

 

А что за код вы пишите (С-и, С++, asm ..., под линукс, под Win ...) и какого объема? Сколько файлов в вашем проекте?

И что называете проектом? Результатом вашего проекта является что: программа, плата, устройство, система..?

 

Например для программы встраиваемого устройства я плохо представляю как можно держать ветки да потом их еще мерджить.

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

 

Объясню.

Ветки это просто немного другой код. Код жалеть нельзя. Это непосредственно следует из метафоры Брукса о мусорном ведре из книги "Мифический человеко-месяц"

Главное проект, архитектура.

 

Впрочем повидимому некоторые боготворят реюзинг кода. И ради реюзинга готовы тянуть с собой в контроль версий кучу мусора.

Возможно это привычка при работе в больших коллективах для создания видимости титанической работы.

Допускаю что это даже способ выдвинуться в добровольных коллективах или даже способ своеобразной обфускации (запутывания)

 

Т.е. мне интересны психологические основы такого поведения.

 

 

 

[Xenia 35]

Это всё здорово, но только для ситуации один человек - один проект от начала и до релиза.

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

Если программист уволится на середине, то его и за человека считать не надо :). Достаточно будет просто сохранить проект на той стадии, до которой тот его довел, а дальше новый исполнитель поведет его дальше по своему усмотрению. Тем более что именно он будет отвечать за проект, а не тот, кто уволился.

 

В тех же случаях, когда над проектом работают два и более исполнителя, работа должна быть поделена между ними с умом. Т.е. примерно так, как задачу делят на два или более потока. И если из-за такого распаралелливания и возникают определенные неудобства, то это задача периодического объединения работ отдельных исполнителей в одно целое. Обычно такая задача решается тем, что один из исполнителей назначается главным, на которого и возлагается задача сращивания результатов работ. Он же должен и распределять работы по исполнителям так, чтобы ему потом было легче их сращивать.

 

Скажем, если две швеи шьют один костюм, то будет эффективно, если одна будет шить пиджак, а другая брюки. Но если они начнут срочить обе вещи по очереди, то им пришлось бы в основном заниматься не швейным делом, а писательством в "лист регистрации изменений" :).

 

ИМХО, приучить пользоваться новым инструментом можно двумя путями: тоталитарно-административным либо создать такие условаия, что "нужда сама заставит". И в этот момент подсказать правильный путь, объяснить, как пользоваться и то.

Какая нужда? Кто вообще читает этот "лист регистрации изменений"? Ради какой проверяющей инстанции он пишется? :)

[des00 25]

А что за код вы пишите (С-и, С++, asm ..., под линукс, под Win ...) и какого объема? Сколько файлов в вашем проекте?

И что называете проектом? Результатом вашего проекта является что: программа, плата, устройство, система..?

Работаю в сфере беспроводной связи и вычислительных устройств.

Проект : разработка конечного устройства (софт, железо, интеграция) или разработка reuseble IP core. Язык разработки матлаб/Verilog/SystemVerilg/VHDL/embedded C(C+)/PC C(C++). Функциональные схемы : OpenOffice Draw, платы PCAD/Altinum. Корпуса и сборочники уже в Лоцмане.

 

В проектах 300-500 файлов, в среднем в файле от 200-1000 строк. Работает в команде системщик + embedded/PC программист + несколько HDL дизайнеров разных уровней.

 

Например для программы встраиваемого устройства я плохо представляю как можно держать ветки да потом их еще мерджить.

Например обкатка разных алгоритмов обработки сигнала, обкатка реализаций по соотношению ресурс/производительность.

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

Срез (tag) это тоже ветка. Релиз софта выкатывается именно из среза, с конкретным номером. При поддержке проекта и поиске багов, берется именно то состояние проекта которое было отправлено клиенту. И повторяется ситуация с которой столкнулся клиент для изучения

[_4afc_ 25]

Предыдущие посты меня не убедили в необходимости SVN в жизни эмбаддера.

Обязательно сохраняю заработавший код в отдельный архив и меняю ревизию. После каждой мысли перенесённой в код - нажимаю сохранение.

 

Был у меня такой опыт: писали вдвоём одну систему под QNX. Часть писал он, часть я. Один и тот же файл редактировать не было необходимости. Переодически обменивались работающими файлами. Система была создана и работала.

 

А был другой: пришёл програмист, создал отдел и сел там начальником. Купил сервер для SVN. Нанял 10 человек. Купил пачку лицензионной винды и вижуал си. Поставил Доксиген. Взял бетатестера. Найденые баги исправлялись только если они были зарегестрированы на сервере через веб интерфейс. И я там был. Добавлял ему из своих архивов в SVN коды. Разработка системы не была завершена.

 

Необходимость SVN для работы в команде вызвана неумением руководителя проекта разбить работу не отдельные узлы и формализовать их взаимодействие.

 

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

 

Единственное где нужна подобная отчётность и внешнее хранилище - это чисто софтовое писание в команде на удалёнке под присмотром тимлидера. Но там эти условия объявляются при приёме на работу.

 

А когда ембадер взялся за проект в определённый срок, а потом ему говорят - поставте SVN, Касперского, Windows 8 ходите на корпоративную йогу по субботам и пишите ежедневные отчёты о проделанной работе - это уже другие деньги, сроки и уж абсолютно точно меня в такой команде не будет.

 

[Xenia 35]

У нас, российских разработчиков, свой путь к технической сингулярности :) - с упором на индивидуала! А насаждение американской коллективизации в любом деле уже достало.

[Сергей Борщ 119]

Разработка системы не была завершена.

Cреди людей, родившихся в 1839 г. и питавшихся впоследствии огурцами, смертность равна 100%.

 

У нас, российских разработчиков, свой путь к технической сингулярности :) - с упором на индивидуала!

Я все свои проекты делаю в одно лицо. И система контроля версий мне все равно очень помогает.

 

 

Мда. "Давайте спорить о вкусе устриц и кокосовых орехов с теми кто их ел".

[ViKo 1]

Я все свои проекты делаю в одно лицо. И система контроля версий мне все равно очень помогает.

Чем?

"Устриц" ел. Не вкусил. И сейчас это блюдо стоит перед носом (на компьютере). Иконки значками разнообразит.