В копилку наблюдений за разностью в работе голов. Тема будет насколько специфичной (с профтерминами), но, в общем - понятна, при известном желании вникнуть и напряжении интеллекта,
Дело было как раз на том проекте, где мы с этим профессором и познакомились. Сам он - физик. Занимается всякими сплавами и влиянием на их изменение их прочности под действием окружающих условий (нагрузки, температура, ударные воздействия...). В силу специфики работы, он немного ещё и программирует.
Мы начали контактировать на этапе, когда куча его наработанного расчётного и анализирующего кода, должна была быть включена в некий подготовленный фреймвок для разработки системы, объединяющей испытательные стенды, базы данных, сетевые интерфейсы, интерфейс пользователя. Короче - такая себе разнесённая испытательно-экспертная система.
Естественно, что система, до включения его кода, уже обладала некоторой архитектурой и набором классов. Его часть была ОЧЕНЬ важной и тоже обладала уже своей внутренней идеологией и архитектурой. Но он сразу согласился, что приоритетом по вынужденным изменениям (в ходе "притирки" общей системы с его частью) будет именно его подсистема.
Для этого мы начали перепроектировать систему классов у нас и вводить классы в его часть (что бы они стали "бесшовно соединимы" с общую систему). Занимались этим, опять-таки, естественно, не только мы с ним вдвоём, а ещё человек семь. Там было больше рутинной работы, чем какого-либо творчества... Но это - на взгляд меня и ещё двух человек из бывшего СССР.
А вот у американцев и англичан возникли проблемы.
Я не буду описывать полностью всю картинку, расскажу о сути затруднений.
Постсоветские разработчики (с опытом советской высшей школы в области разработки программных комплексов) отличались от профи из англоязычных стран одним свойством. Мы не привязывались накрепко в мышлении к чисто классово-интерфейсной парадигме организации кода по типизации и повторного использования функционала. То есть, амеры и англичане накрепко ухватывались за наследование, совершенно не используя агрегацию и делегирование функциональности!
Это было - как наваждение!
Мы смотрели на них и недоумевали: там, где можно было обойтись совершенно меньшим количеством кода с расширяемой "на лету" функциональностью (даже, подчас, БЕЗ ПЕРЕСБОРКИ проекта), они постоянно городили совершенно дикое количество посторонних классов и интерфейсов, накрепко привязываясь к заложенной раз и навсегда архитектуре.
...которая постоянно распухала…
После некоторого времени перепроектирования таким образом, малейшее изменение требований в проекте каждый раз превращалось в перестраивание общей архитектуры проекта, введением новых классов и наследованием (с переписыванием почти всего кода в виртуальных функциях в наследниках)... Кроме этого, после введения новых классов и наследников старых, требовалось каждый раз перепроверять уже имеющийся функционал. Причём, не непосредственно связанный с задачами, ради которых система и создавалась, а - именно тех, которые обеспечивали "инфраструктурную связность и согласованность работы" всей библиотеки классов.
То есть, после довольно плотной работы и обсуждения, всеми участниками проекта с постСоветской стороны был сделан общий однозначный вывод: мышление участников проекта с "вражеской стороны", демонстрировало ярчайшую склонность к шаблонным и закостенелым схемным решениям. Вызывало удивление их удивление, что "оказывается можно было сделать и так". Причём, что самое удивительное, они даже не "перекладывали" понятия, их роли и отношения между ними, выявленные в предметной области, прямо в проектные решения, ДАЖЕ ЗНАЯ о каких-то свойствах языка разработки (были С++ и Ява), позволяющих напрямую выразить в языковых конструкциях эти отношения и свойства!
Они продолжали, с ослиным упрямством, каждый раз трансформировать задачи в строго определённый набор формальных конструкций. Причём, как мы заметили? именно в те конструкции, за которыми наиболее внимательно "следит" компилятор и среда исполнения. При этом они часто до неузнаваемости изменяли первоначальные требования и условия задач. Вплоть до изменения внешних ограничений и условий функционирования! То есть, проводили подгонку внешнего мира под своё видение, а — не наоборот!
В конце концов, отношения накалились, когда их система классов стала уже просто ужасающей и трудно воспринимаемой.
Спасло нас то, что, профессор, "ради собственного интересу", начал всё больше времени проводить с нашими ребятами и интересоваться нашими подходами, переписывая свою часть в соответствии с ними.
Результатом этого взаимодействия стало то, что мы настолько его натаскали в ООП, что он стал писать в этом и подходе даже на Си (без плюсов). Просто ему, по задачам часто нужна "скорострельность" "чистого Си", а проектировать вне ООП парадигмы он уже не мог...
Я сначала думал, что подобные подходы были "бедой" лишь той группы программистов, с которыми мы столкнулись на совместном проекте… Ну, типа, так звёзды сошлись…
Но, как-то, поделившись своими наблюдениями, позже с несколькими коллегами, тоже поработавшими на амерский авиакосмос, понял, что это — общая черта тамошних разработчиков. Причём, самое интересное, что таковая тенденция в подходах к проектированию, стала проявляться последние лет 10-15. Раньше гибкость мышления при работе над проектными решениями была не в пример выше. Собственно, многие разработки в области ОО проектирования и языков именно из США родом.
Почему, вдруг с их мозгами такая напасть приключилась — удивительная загадка!
Может это — не только в области ИТ теперь у них?...
