Как создавать реально сложные, гиганские програмные системы?

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

Читаю Совершенный Код - но хотелось бы что нить про реальный успешный проект!

 

Те, кто умеет это делать, занимаются делом, им некогда писать книги. Обратите внимание - книги по программированию "русскоязычных" афторов - как правило сборник надёрганого хрен знает откуда материала, всё очень поверхностно, практической ценности никакой ( есть исключения ). В нашей стране книгоиздательское дело ещё недавно было прибыльнее торговли наркотиками ...( себестоимость книжки 10-30 руб ) щас немножко похужее из-за инета, вот почему они вой поднимают насчёт... вареза..
В одной книге всего не может быть - это отдельные сущности...
На ннм кое-что есть... поиск по сайту...

 

Лабы NASA сертифицированы по уровню CMM5 - http://kholeg.spaces.live.com/blog/cns!D006ED9CB32B0F60!152.entry

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

http://ceh.nasa.gov/webhelpfiles/Software_Estimation.htm
http://www.hq.nasa.gov/office/codeq/software/docs.htm
http://satc.gsfc.nasa.gov/assure/assurepage.html

 

systemio почитай про экстремальное программирование. А про аспекты программирования можно почитать в книгах по паттернам. Еще можно заглянуть на www.topcoder.com/tc где ежедневно создаются новые программные компоненты и понаблюдать за процессом (см. development и design соревнования).

 

Оффтоп
Цитата из блога (см. первую ссылку volodya):

Интересный факт , вопрос о женщинах-программистах на форуме недавно обсуждался.

 

Оффтоп
Что то тут женщин не густо

 

Хотелось бы на русском - не хочется тратить время на перевод.
Первая статья volodya рулит!

 

Я думаю, никаких особых отличий сложных систем от обычных небольших программ нет. Программирование - это не технология, а ремесло, по сути. Поэтому все основано на личном опыте. Сложные системы создают люди имеющие опыт создания таких сложных систем . Никто закончив институт не сможет сразу наваять что-то сложное, а зачастую и простое. Нужно накопить личный опыт разработки. Причем опыт разработки систем из определенной области. Создавать программы вообще нельзя. Например, нельзя человека разрабатывающего игры посадить писать код для оси: у него мало опыта создания подобных систем. Скорее всего он ничего толкового не напишет. Спроектировать какую-то программу можно, только если ты писал ее уже не раз. Если ты пишешь, например, компилятор в первый раз, то cпроектировать его не получится: нет опыта создания. Придется идти методом проб и ошибок, искать дополнительные сведения, примеры кода. По сути, ты учишься создавать именно этот тип программ. И каждый программист имеет такой уникальный опыт. Кто-то писал драйвера, вирусы, но никогда не писал компиляторы или оси. И, естественно, у такого человека получится спроектировать драйвер или вирус, а компилятор придется учиться писать. Каждая программа уникальна. Если ты решил написать что-нибудь, то, если ты не писал такого еще ни разу, тебе придется идти методом проб и ошибок, то есть учиться делать именно эту программу. Решения принимаемые тобой не всегда будут оптимальны, но тут главное сделать рабочую версию. У создателей крупных программ тоже самое. Если ты думаешь что они просто сели и спроектировали такую систему сразу после института, то ты ошибешься. Они имеют большой опыт разработки именно таких систем. Человек, скорее всего, довольно долго варился в этой теме. Участвовал в разработке подобных вещей. Копил опыт. И однажды сам смог создавать подобные системы. Разумеется код управляющий работой спутника методом проб и ошибок не напишешь . В этой сфере накоплен большой опыт. Молодые программисты приходят в коллективы где есть это знание и перенимают его. Потому, я думаю, желательно поработать в крупном проекте, если хочешь уметь писать что-то крупное. И определись с областью. Что бы ты хотел создавать.

 

С божьей помощью и стопудовым терпением.

 

systemio
Макконел "Совершенный код" - не повредит отцу русской демократии

 

Вставлю свои 5 копеек

• Экстремальное программирование откровенно непригодно для больших систем,
и это не моё мнение, а самих разработчиков xp
• Если исходить из того, что программирование - ремесло, то действительно большую систему построить будет невозможно. Предел будет аккуратно там,
где заканчиваются возможности такого подхода
• Если аналогичные системы существуют, то всё уже спроектировано, можно только усовершенствовать. Исходить из того, что для проектирования нужен опыт разработки аналога - заведомо тупиковый путь, да и создать что-то принципиально новое будет сложнее, чем это есть на самом деле.
Для проектирования очень важен опыт проектирования и некторый класс знаний и навыков. Т.е. сли человек уже писал, скажем, компилятор, но не имеет представление о
проектировании, ничего путного в проектировании от него ждать не приходится
• Большие и сверхбольшие системы кардинально отличаются от небольших программ.
Способность к их разработке актуальна в одну сторону, т.е. человек способный написать небольшую программу вовсе не обязательно справится с системой в 100 раз больше.
В частности, можно спокойно небольшую программу можно спокойно написать структурно, без использования ООП, а вот большую систему (>200 тыс строк) качественно написать без ООП практически не реально

 

Dian

наскоко я понял и вынь и линь и нек другие системы (я всех не знаю) написаны полностью или практически полностью на С.
Большие системы практичнее всего писать как набор маленьких и небольших модулей взаимодействующих через строго описаные интерфейсы/протоколы. Чем строже, тем лучше. Как пример можете посмотреть на оберон/блэкбокс.
Одно только "но". само написание большой системы достаточно тривиально. Непростым в ней является первоначальное продумывание архитектуры, способов взаимодействия между частями (чем проще, тем лучше), расширяеиости, направленности, ограничений, вероятных слабостей. Плохое продумывание как правило приводит к чрезмерной усложненности, запутаности, трудноуловимым внутренним ошибкам, невозможности расширить без частичного или полного переписывания, чрезмерным затратам на написание/сопровождение. Очень большой слабостью будет отсутствие совместимости снизу вверх между версиями (плохое проектирование), а вот возможность апгрейда добавлением/заменой только необходимых частей - большой силой.

Те написание чего побольше происходит большей частью без компьютера. Для начала надо научиться именно этому.

 

Dian

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

_basmp_

Ну а это фактически и есть то самое проектирование с документированием.