OberonCore

Да, там как-то странно предложение составлено.



Отдавать модули (без версии) клиентам можно, если:
1) Клиентов обозримое (запоминабельное) количество. Лично для меня это число не больше 2.
2) Разработчик (человек) один. Иначе будут разборки кто кому чего когда дал.
3) Разработчик имеет прямой контакт с клиентами (а не цепочку "разработчик <-> саппорт <-> IT отделение <-> клиент").
4) Разработчик не отвлекается ни на что другое, а планомерно сопровождает данный продукт.

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

P.S. Все это из той же оперы, что и "зачем оберону CVS?" Пока школьные поделки на нем делаются - нафиг не нужно.

И правда, нафига Оберону CVS, если есть SVN

А если серьёзно, то из нашего опыта: от SVN требуется не система контроля версий, а хранилище коллективной работы. Из версионирования требуется только возможность дать команду copy и закрепить какой-то момент отдельно. "Трекать версии" не понадобилось пока ни разу.

SVN уже тоже не модно...



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

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

По факту, каждый день используются svn status ("собственные диффы", только по модулям, а не по текстам..), commit и update. Блокировки - иногда. Обычно за модуль отвечает кто-то один.

copy нужно бывает. Сделать слепок стабильного момента или значимого...

Какие подключаемые реализации? Реализация одна. Например, модуль работы со строками. Пока две команды работали в своих ветках над своими разными реализациями разных фич, обе чего-то добавили в этот модуль, а может даже и баги там нашли/фикснули. Такая ситуация нетипична для оберонов? Никакого code reuse? Каждая фича реализуется с нуля? Или за каждым модулем закреплен "ответственный" и если возникают проблемы - то он их устраняет и следит за тем, чтобы в обоих ветках была правильная версия этого модуля?



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

Дикость какая-то. Из таких рассказов возникает ощущение, что исходники постоянно перекраиваются - даже старые, даже устоявшиеся. Серьёзная работа с текстом, не иначе...

Кстати, а можно постнуть пример диффа, когда, например, код FOR'а с жирным (в смысле выделенным шрифтом) RETURN из середины был заменен WHILE'ом? Чтобы представление иметь

Конечно перекраиваются Не все же занимаются реализацией интервальных вычислений - реализовал и забыл Требования к системе меняются, система живет, эволюционирует. Что-то новое зарождается, что-то меняется, что-то отмирает.

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

Нет, конечно, бывает всё. Но если говорить про штатный ход событий...



Очень нежелательная ситуация. Изменение уже завершённого интерфейса. Обычно ведём расширение отдельными модулями. Если не получается, то решение может быть принято только совещательно.


Редко такое бывает. Сразу сообщается автору модуля.


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

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

P.S. Кстати, только не так давно стали привыкать к дисциплине "написал модуль - сразу к нему комплект тестов". Хорошо, уверенности сильно добавляет - и на этапе комплексирования головняка меньше...
Ошибки в основном вида "где-то что-то забыли соединить-настроить" - как раз для срезания тестами. И, конечно, лучше на отдельном маленьком блоке срезать, чем дожидаться, когда соберётся "самотест" - т.е. более крупный блок.

С ростом масштабов эта "база" превратится в злобнейшую бюрократию, которая будет съедать все время. Даже в небольших командах этот принцип (хозяин кода) плохо работает, когда появляются, например, временные пояса. Я уж не говорю про болезни/отпуска. Кроме того, когда у кода нет одного владельца, возникают дополнительные преимущества:
- все члены команды представляют (хотя бы примерно) что творится в разных частях системы, нет "темных" участков, которые знает только один незаменимый "эксперт".
- больше возможностей критически оценить работу друг друга (если разбираться с незнакомым куском пришлось очень долго, то очевидно кусок спроектирован плохо).
Хотя такой подход не будет работать в крупных конторах с сильно разным инженерным уровнем разработчиков. Однако и ваш тоже не будет

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

У Vlad'а какие-то дикие иллюзии, всю дикость которых он, похоже, даже вообразить не может, хотя лично я об этом писал: работа с научными алгоритмами -- это эволюция ПО, что называется, на стероидах.

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

Да вы ничего конкретного как раз и не писали. Только замечание про то, что интервальные вычисления - только на ББ можно

Где смотрели?
Где усмотрели?

Организация, которая использует систему, тоже эволюционирует (вчера выпускали колбасу, сегодня учебники, завтра - готовим бобслеистов к Олимпиаде)?

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

В переводе на инженерию это выглядит так: для постройки нового моста мы притаскиваем кучу необработанного материала, дохрена народу, говорим им построить мост и они его строят. Динамически меняя и разрабатывая "интерфейсы" в течении недели. Представили?

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

Не совсем согласен!

Цепочка обсуждения выводит на более общие вопросы:

Как создать exe? -> Зачем создавать exe? -> Стратегия работы с клиентами. -> Промышленная разработка ПО на BlackBox.