Ответ на »сообщение 29« (Виктор)
___________________________

На одном из форумов наткнулся на название "Битовый сортировшик". В литературе по алгоритмам я его не нашел. Пришлось придумывать. Работает стабильно. Миллион элементов по 32 байта сортирует на 850 целероне за 20 с.
А можно подробнее? Вопрос заинтересовал, но найти тоже ничего не смог

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

В мире Java уже есть продукты с такой функциональностью.

Ответ на »сообщение 40« (Max Belugin)

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


Но с моей точки зрения скорее всего хватит обычных возможностей CVS или subversion. Овчинка вряд ли стоит выделки.
Абсолютно согласен. Может быть, для выделки была предложена не та овчинка? :)

Система генерации метаинформации о структуре исходников была бы очень полезна для сбора метрик и поиска с критериями, которые очень сложно задать на уровне регулярных выражений.
Пример.
Предпосылки:
У нас 28 MB исходников, 35 проектов, 1315 модулей.
В разных проектах - разные директивы компиляции, часть проектов подключает модули через пути поиска, один и тот же идентификатор может обозначать разные сущности, есть связи только на уровне dfm (например, таблица на датамодуле <->форма, оторая эту таблицу использует)

Очень часто задается вопрос:
В каких проектах/модулях используется заданный модуль/метод/интерфейс/константа?
Учитывая предпосылки, обычный поиск по регулярным выражениям иногда становится очень сложным.
Если бы был генератор метаинформации о связях между конструкциями языка, жизнь могла бы стать проще :)
В качестве подтерждения: когда я написал простенький синтаксический анализатор uses, из проекта удалось вычистить 4 мегабайта неиспользуемых файлов.

Пример 2. Вопрос: Какие модули мне нужно подключить к проекту, чтобы использовать модуль X (который может тянуть за собой оооочень много ссылок)?. Наличие метаинформации о связях, опять же, помогла бы очень сильно.

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

Ответ на »сообщение 37« (Jack Of Shadows)
___________________________

Ответ на »сообщение 36« (Сергей Перовский)
___________________________
>Идеализм. Из серии - я не знаю сколько это будет стоить, но надо делать так. Решение экономически неоправдано.
А Вы попробуйте, не так уж дороги в России настоящие профессионалы.

>Здесь вряд ли найдется кто либо, работающий в проектах с участием сотен программистов, и огромным бюджетом. Большинство здесь либо одиночки, либо работают в проектах по 2-10 человек.
Для одиночки вопрос совместной разработки не стоит.
Небольшая группа тоже может работать без этих механизмов, а большой толпы быть недолжно.

> И где на всех набрать профессионалов-хирургов ? А работу делать надо. Желательно совместно. Часто не зная с кем работаешь.
А с непрофессионалами не надо связываться.

Я сейчас участвую в таком проекте, где все разработчики в разных странах. И мне не требуется править чужой текст, и даже видеть его.
Есть спецификации БД в терминах реляционной алгебры, все точно знают, какая база будет.
Для отображения результатов специалист по графике предоставил ряд заголовков функций.
Сидим вдвоем, реализуем ядро алгоритма и не задумываемся о работе других участников.
Знаю, что в MicroSoft над той же задачей работают человек 150-200. Но, могу спорить, мы сделаем гораздо быстрее.

Ответ на »сообщение 39« (Дмитрий Пашин)
___________________________


Вопрос "Как это реализовать" уперся в то, что нужно делать компилятор, идентичный Delphi, либо иметь минимум бонусов по сравнению с обычными CVS.


Если быть занудой, то компилятор не нужен - нужен только парсер. Например для C# есть Code DOM.

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

Тогда можно будет при конфликтах более явно указывать его причину.

Но с моей точки зрения скорее всего хватит обычных возможностей CVS или subversion. Овчинка вряд ли стоит выделки.

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

Вопрос "Как это реализовать" уперся в то, что нужно делать компилятор, идентичный Delphi, либо иметь минимум бонусов по сравнению с обычными CVS.

P.S. За ссылку по Бруксу спасибо. В библиографиях встречалась достаточно часто, но найти и прочитать текст так руки и не доходили. Теперь, наконец, прочитал. Концептуальная, конечно, статья, что и говорить...

Ответ на »сообщение 37« (Jack Of Shadows)
___________________________


Идеализм. Из серии - я не знаю сколько это будет стоить, но надо делать так. Решение экономически неоправдано.Здесь вряд ли найдется кто либо, работающий в проектах с участием сотен программистов, и огромным бюджетом. Большинство здесь либо одиночки, либо работают в проектах по 2-10 человек. И где на всех набрать профессионалов-хирургов ? А работу делать надо. Желательно совместно. Часто не зная с кем работаешь.
Так Брукс как раз и позиционирует метод для команды из примерно десятка человек (точнее, у него указаны 10 ролей). А для больших проектов предлагает использовать несколько бригад с координатором.

P.S. Сегодня был на встрече у крупного клиента, фирма занимается лизингом авто по европе. Департамент внутренней разработки - 65 человек. Разбиты на группы по функциональной (предметной) области. Каждый сам себе хирург, дублированеи кода и данных, денормализация, народ бегает взмыленный, шефы проектов нервные, в общем, бордель еще тот :)

Ответ на »сообщение 36« (Сергей Перовский)
___________________________
Идеализм. Из серии - я не знаю сколько это будет стоить, но надо делать так. Решение экономически неоправдано.Здесь вряд ли найдется кто либо, работающий в проектах с участием сотен программистов, и огромным бюджетом. Большинство здесь либо одиночки, либо работают в проектах по 2-10 человек. И где на всех набрать профессионалов-хирургов ? А работу делать надо. Желательно совместно. Часто не зная с кем работаешь.

Ответ на »сообщение 30« (Jack Of Shadows)
___________________________
Недавно (кажется 25 лет спустя после первого издания)была переиздана в России книга Ф.Брукса "Мифический человеко-месяц".
Он руководил в IBM созданием OS/360.
В книге в основном анализируются собственные ошиби в организации работ большого коллектива программистов. В шутку мы ее называли "Как нам удалось создать кошмарную операционку".
Несколько идей оттуда:
-Если для руководства 200 программистами Вы нашли 20 классных профессионалов - увольте 200. Профессионалы напишут сами быстрее и лучше.
-Подключать к опаздывающему проекту новых программистов все равно, что тушить пожар бензином - на ввод их в курс дела участники проекта потратят больше времени, чем выиграют от перераспределения работы.
-Человек работающй во втором своем проекте требует тщательного надзора - ему очень хочется воплотить идеи, не реализованные в первом, хотя они могут абсолютно не подходить к новому.

Основная идея понятна - писать основной код должно небольшое число квалифицированных людей которым нужно создать все условия.
Отсюда принцип хирургической бригады - один имеет право резать, остальные только помогают.
На случай физической утраты "Хирурга" в схеме Брукса предусмотрен "Второй пилот" - человек, который участвует в обсуждении кода, обязан ПОНИМАТЬ, что пишет программист, но не имеет права вносить изменения.
Это кажется расточительством, но попробуйте писать код, когда рядом сидит человек, которому нужно объяснить, что пишешь и почему именно так.
Четкость мышления повышается, количество ошибок резко падает, производительность (с учетом отладки) растет больше, чем вдвое.
Далее в бригаде по Бруксу программист-инструментальщик, для написания мелких служебных процедур, специалист по тестированию, секретарь-архивариус и т.д.
В общем все совсем не так как теперь принято: программист не внизу административной пирамиды, а наверху.
Поверьте, это работает.

Вот кратко о Бруксе
http://www.macro.aaanet.ru/auxil/brooks.html
А вот МЧМ в электронном виде
http://lib.ru/CTOTOR/BRUKS/