Средства и методы разработки

Коллеги, похоже, мы стоим на границе новой эры развития техологий программирования. Подборка мыслей. Суть технологии - отказ от "файла с исходником" как универсальной основы программирования. Вместо этого будет "универсальная БД", где будет код, тесты, спецификации, дока, каменты, форум программеров - все сразу. Файлы с кодом будут синтезироваться автоматически и скармливаться компилеру. Прикинем размеры БД. Пусть у нас будет супер-проект на 10м строк. Ядро линуха - порядка 7-8м "эффективных" строк кода http://www.linux.o …ru/news/kernel/3193048 http://linuxforum. …viewtopic.php?id=20506 Пусть каждая строка - 10 тегов. На каждый тег запись в БД. + на каждый тег - запись о связях, с чем этот тег связан. Итого 100М +100м = 200м записей. Пусть с учетом индексов и прочего запись будет эквивалентна 512 байтам. Тогда общий объем - 100Г данных. Как я не раз писал, простой сервачек со 128Г памяти будет стоить 150кр. Что реально даже для одиночек. При использовании Infiniband реальна скорость 1 Гбайт/сек в винде при использовании RamDrive на сервере. http://caxapa.ru/314114.html Латентность там будет 1-2 мкс. Конфигурация системы примерно такая. Сервак для хранилища и RamDrive. Девелоперская машина для кодинга и сборки кода, при этом сами исходники синтезируются ПО сервка (чтобы не было накладных расходов на каналы связи) и кладутся на RamDrive сервака. Такое разделение позволит избежать проблем при падении девелоперской машины. Сервак и девелоперская машина связаны Infiniband и кросоверным кабелем. При организации локальной рабочей группы можно набить в сервачек кучку 10G Ethernet и кабелями к рабочим станциям. Чтобы не платить 230к за коммутатор. Хотя, заметим, даже 230к не смертельно для группы. Групповая работа. Если не нанимать в качестве кодера секретаршу "печатаю 2к символов в минуту, но такая х-ня получается", то можно считать, что обычный кодер производит едва ли более 2-3 символов в сек. Что позволяет производить глобальную синхронизацию с "центральной БД" в реальном времени даже при использовании GSM канала. При условии, что у сервака все в памяти и реакция на запросы имеет латеность единицы мкс. Понятно, что не все правки надо тут же отображать в центральной БД, нужно комитить только осмысленные куски, что только упростит ситуацию. Зато on-line чат с коллегой на другой стороне шарика, который останется в базе проекта, со всеми сведениями этого чата и ссылками на объекты проекта - это мощная штука! Таким образом, локальный сервка служит "интерактивным справочником" по коду. Новый ввод on-line синхронизируется с центральной Базой, + фоновая проверка идентичности копий и перекачка файлов (ДШ и прочее). Понятно, что учет труда каждого тоже не проблема. Можно хоть пооператорную оплату вводить. Команда становится принципиально распределенной. Значит, можно нанимать узких спецов на конкретные задачи, и они будут кодить, не отрываясь от других работ. В любом месте, в любое удобное для себя время. Deadline соблюл - получи денюшки. Права доступа в проекте прописаны на уровне классов и функций. Правит код только мантейнер, зато все желающие могут писать матюки и патчи, привязывая их чуть ли не к конкретному символу обсуждаемого кода. Автоматизация учета матюков и прочее. Пока лично мне не очень понятно, как делать версионность достаточно больших объектов в этой БД, но, уверен, это задача наверняка решится с привлечением профи. Т.е. заменить объект в узле графа на его новую версию (с сохранением старой; для экономии места старую версию можно сбросить в SSD БД), или изменить связи не меняя узлов - мне понятно, а как отобразить, что в новой версии графа другой набор узлов - пока не очень понятно. Что касается языков, что С++ просто создан для такого дела :) Но не просто С++. С неким набором правил, которому следуют все участники проекта. С разделением интерфейса и реализации. С контрактами и прочими штучками. Подход можно применить для любого языка. Сам исходник будет также отличаться от традиционного подхода. Никакой условной компиляции, никаких либ в виде объектников. В файл исходника собирается только то, что реально должно исполняться. Прикинем скорость синтеза. Пусть наша БД выдает 1М транзакций в сек. У нас 100м тегов, т.е. полный набор файлов мы синтезируем за 2 минуты, что терпимо. Насчет многофайловости. Все засунуть в один файл трудно - у компилеров есть ограничения на количество объектов в единице компиляции. Система сама разобъет код на файлы. Чтобы и пределы не нарушить, и компилер мог оптимизировать (большие файлы ему в этом помогают). По мере синтеза файлы новой ревизии сравниваются со старымим. Если файл не изменился - его объектник заново компилять не надо. Если говорить об эмбеддерских проектах, то тут, конечно, нужен симултор проца. Они есть :) http://www.ovpworld.org/ говорится о достижении 600м-1Г дристанов в симуляторе. Непонятно, на какой машине, непонятно, что там с многопоточностью, и можно ли все это ускорить моднючими процами http://caxapa.ru/314092.html Но даже 500М дристанов - это покрытие большинства реальных задач. Аппаратуру описывать на SystemC|SystemVerilog, и подрубать ее к симулятору ядра. В итоге мы имеем (по моим интутитивным прикидкам), что команда в десяток девелопеорв сможет ээфективно управляться к проектом класса "ядро линуха", что есть разрыв шаблона, однако :) Соответственно, кто первым освоит технологию - хорошо поднимется.