философы все стремятся рассудить, какова ее природа. Они стремятся найти одну, понятную и всеобъемлющую метафору, из которой бы естественным образом проистекал и процесс организации, и необходимые инструменты, и способ подготовки профессионалов.
Об отсутствии ответа на вопрос 'что есть программирование' свидетельствует хотя бы и количество статей с заголовками вроде 'Programming is like A', 'Programming isn’t like A, programming is B', 'Software developer is C', чуть не ежедневно вызывающих горячие дискуссии в техно-блогах.
Самая старая, очевидная и по сию пору соблазнительная метафора - программирование как аналог любой другой инженерной деятельности, строительства дорог, домов и мостов. 'Дырки' в этой метафоре слишком давно известны, чтобы на них подробно останавливаться: все компоненты 'моста'-программы суть плод интеллектуальной деятельности, а не объекты физического мира, что подразумевает возможность пере- и доделки виртуального 'моста' в любой момент его жизни; сочленение его с другими, существенно разнородными сущностями; повторное использование компонентов - в общем, такие способы действия, которые 'настоящего' инженера привели бы к быстрому и надежному помешательству. Тем не менее, эта рабочая модель, мало общего имеющая с действительным положением вещей, и по сию пору привлекается в дискуссиях достаточно часто.
Как только стало очевидным несовершенство 'строительной' метафоры, стали появляться ее замены-развития, суть которых, в основном, сводится к аналогиям между деятельностью разработчика и инженера-проектировщика: как бы весь цикл написания программы есть проектирование, а процесс 'производства' сведен лишь к фазе компиляции (наиболее полно этот подход отражен в статье Дж. Ривза 'Как проектировать ПО?', ее можно найти в 'КТ'#589, и там же - критика этого подхода Д. Завалишиным с позиций реакционной метафоры 'строительства'). Однако и эта метафора почти столь же дырява, как и предыдущая: она игнорирует тот факт, что почти любой минимально законченный кусочек работы программиста может быть запущен, отлажен, переписан; а логический скачок, называющий компиляцию 'стадией производства', заставляет странно выглядеть переработку-рефакторинг (оставаясь в рамках метафоры, получается нечто вроде 'спроектировали машину абы как, произвели, запустили, не едет, чуть подправили проект - произвели, запустили, едет, но не туда...' - очевидно, что метафора не очень-то хороша).
Как бы то ни было, почти любая попытка определить деятельность разработчиков ПО приводит к тому или иному компромиссу между производством (production) и творчеством (creation) [На научные же методы, как основу процесса разработки, мало надежды осталось со времен краха автоматизированных средств написания и верификации программ]. Соответственным образом выглядит и большинство современных средств разработки: как среда для созидания с множеством возможностей анализа структуры и процесса, а также использования 'типовых решений'.
Но попробуем взглянуть пристальнее на процесс и его результат - на то, что происходит в реальности, а не должно бы происходить в некоем 'идеальном процессе разработки'. Разработчики (один, десяток или тысяча) могут действовать в соответствии с простой метафорой или 1000-страничным 'описанием архитектуры', но в любом случае проект движется от небольших 'атомов' (или 'клеток'), от отдельных строк кода, к модулям, подсистемам и целому. В процессе этого движения атомы-клетки многократно изменяются под влиянием тестирования, изменений в требованиях к проекту и в команде разработчиков, эффектов, возникающих от
