Весьма странный подход у большинства производителей... в какой-то мере характеризующий общее положение на рынке програмных продуктов.

1. Необходимо четко представлять что такое програмный продукт. А это не только исходный код программы и его скомпилированный код. Мое убеждение сводится к тому, что под програмным продуктом следует понимать:
* аналитическое описание програмного продукта и его функциональности(!)
* исходный и двоичный код програмного продукта
* руководство пользователя, мануал или правила пользования.

2. Объем програмного продукта, время на его реализацию. Эти параметры позволяют оценить нам всякого вида затраты.

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

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

Практика и теория показывают, что параметры полученные опытным путем несут за собой большую ошибку, а комплекс этих параметров несет ошибку еще большую.
----------
Если мы имеем полное представление о продукте (это утверждение всегда ложно, но иногда требуется принять за истину), то можем определить расходы на проект: время, деньги, люди, оборудование, дополнительные програмные средства. Как следствие: никогда не бывает достаточным времени, денег, людей, оборудования, доп. програмных средств.
----------
В зависимости от предполагаемого количества одновременно используемых ресурсов выбирается модель коллектива для реализации проекта. Сквозной подход (анализ, кодирование, тестирование, исправление, ошибок, документирование на кажом этапе), цикличный (сквозной но переход на начало осуществляется при нахождении ошибок, что влечет за собой анализ, кодирование, тестирование и т.д.), ориентированных групп по задачам (каждая группа выполняет поставленные перед ней задачи, реализует от начала модуль системы), ориентарованных групп по функциям (группа аналитиков, группа кодировщиков, группа тестеров, группа документации и т.д.). Моделей коллективов существует столько, сколько руководителей проектов. Практика показывает, что идеальной модели не существует.
----------
Теперь об анализе исходного кода. Практика показывает, что необходимо доверять кодировщику. В его задачу и входит нахождение оптимальной реализации, соответсвующей заданым параметрам (интерфейс, временные метрики, объем используемой памяти и дискового пространства и пр.). Практика показывает, что кодировщик не должен выполнять функции аналитика и только в случае явной ошибки должен уведомлять аналитика о ней. Кодировщик работает только со своим техническим заданием. Зачем необходим анализ исходного кода? Я не знаю, но уверен однозначно, что показателем должно служить соответсвие скомпилированного кода поставленным перед ним ограничивающими условиями.
----------
Каждый коллектив разрабатывает собственные средства обмена информации, документирования изменений и ошибок, контроля реализации и пр.. Главное, чтобы эти средства обеспечивали однозначность, целостность, компактность проекта.
----------
Oracle_Developer >
* а действительно именно это тебе нужно?

ksukhonosenko > Ctrl-C/V Programming MUST DIE !!!
* Использование компонент в Делфи это из разряда такого вот программирования, Oracle Developer не исключение. В современном мире программирование и сводится к копированию и соединению этих маленьких черных ящичков.

Ekuku > Продукты такие наверно есть, но это из области нечеткой логики. Поэтому они и стоить должны нехило и работать глючно.
* придерживаюсь этой же точки зрения. И какой смысл использовать эти продукты, если результат их работы несет за собой непрогнозируемую ошибку?

Oracle_Developer > Собираються все разработчики и давай обсуждать чей-то код. Или быть может для этих целей ведеться база обсуждений.
* Пример с 4000 штатом ИТ впечетляет, даже если учесть, что только 1/5 из них разработчики. Сидят разработчики в конференц зале и обсуждают код одного из них :) ... и когда же очередь дойдет до последнего?

ksukhonosenko > У нас - бардак - у нас нет. Но вообще - это очень полезно. Вообще читать чужой код полезно. Узнаешь как не надо программировать :)
* У не поэтому у вас бардак, что все у вас учатся как НЕ надо программировать, а как раз не наоборот тому как НАДО программировать?

Rudyshin Sergey >
* хорошие вопросы.

pauel >
* А если самый главный лидер заболеет, то проект остановится? Да конечно, есть группы которые не закончили задания и им есть чем заняться, а те что свои задания выполнили? Думается у вашего главного есть хотя бы один заместитель и помощник. А это правда, что ваш самый главный лидер перебирает код 4000 программистов и потом собственноручно вносит изменеия? Должно быть на реализацию крупных проектов у вас уйдет не менее 5-10 лет, если код может править только один человек. Актуальность продукта становится на порядки ниже.

----------
Рекомендую книгу: Брукс, "Мифический человеко-месяц - или как пишутся программные системы" (надеюсь название не сильно перебрал).

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

pauel > Labu dienu. Juus arii no Latvijas? Un Juusu kompaanija ir iespeejams Dati vai SWH?
В таком случае у вас небольшое количество людей на проект. А как бы поступили бы у вас, если на один проект пришлось кинуть 4000 сотрудников? Полагаю делили на модули/задачи, а дальше поимели проблем на интерфейсах.

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

ksukhonosenko> Поэтому - я за чтение чужого кода. И с точки зрения обучения и с точки зрения контроля.

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

Ekuku>
Я постоянно сталкиваюсь в своей работе с одной компанией. Так вот, она все-таки смогла научить своих заказчиков правилу жизни: ничего новго мы вам вчера не поставим. У нас есть ресурс который нам необходимо распределять и вам(заказчикам) стоит это учитывать. Любой проект займет время.

Rudyshin Sergey>
Имеет ли смысл делать оценку кода по различным метрикам с целью обнаружения ошибки? Полагаю, это вообще задачи разных направлений: оценка продукта (стоимость конечного продукта, например) и отладка/исправление сырого продукта.

Oracle_Developer>
Оценивать код имеет смысл если вы его продаете (т.е. определяете его цену), а для исправления логики и ошибок лучше позвать опытного товарища.