IT-источники знаний о мышлении — различия между версиями

Текущая версия на 19:57, 5 ноября 2018

Как писал в одном из своих недавних постов Анатолий Левенчук, стоит упомянуть "мышление" - тут же набегает много народа с идеями... Я тоже из набежавших, но у меня нет предложения развертывать представления о мышлении на основе любимой школы или мыслителя. У меня есть несколько тезисов о потенциальных источниках знаний о мышлении, лежащих в IT-области. При этом они лежат в сыром виде первичной информации, и их использование требует промежуточной исследовательской работы, а в курс можно включать только результаты таких исследований, и то если они будут успешны. Поэтому данный пост находится несколько в стороне от непосредственной цели сообщества. Но, с другой стороны, исследования - они итеративны и, возможно, пост сможет послужить как отправная точка каких то частных исследований, возможно, некоторые из них могут в будущем курсе выполнять роль практических работ. И тут надо сформулировать мою личную позицию: тема меня интересует, я готов в ней участвовать, но - в составе заинтересованной группы, и не готов быть основным двигателем. При этом я ясно вижу ее объем и непосильность для одного человека.

После этой преамбулы перехожу к идеям.

1. Разработка софта, включая написания кода - чистое мышление, соответствует этапу проектирования (НИОКР) для других отраслей деятельности (например, разработки самолетов). Тезис - старый, насколько я знаю, был впервые сформулирован Ривзом (Reeves) в 1992 в статье http://www.developerdotstar.com/mag/articles/reeves_design.html (перевод http://lib.custis.ru/Reeves). Но при этом результаты этого мышления непосредственно зафиксированы в коде программ. Об этом свидетельствует закон Конвея (https://en.wikipedia.org/wiki/Conway's_law), гласящий что структура системы соответствует структуре коммуникаций в команде, которая разрабатывала эту систему. Таким образом, в коде софта мы можем наблюдать результат коллективной мыслительной деятельности команды разработки. А практика хранения кода в системе контроля версий позволяет прослеживать не только текущие результат, но и логику развертывания этого мышления во времени. Если к этом добавить концептуальный слой проектирования, история которого зафиксирована в версиях вики, а также сопутствующую этому переписку в таск-трекере, которая содержит основания для изменений в коде, то получается большой массив первичных данных для исследования мышления. При чем он доступен в исходном виде для большого количества открытых проектов самого разного размера. При чем это мышление касается практически всех областей деятельности человека, а так же физического мира, поскольку все они в той или иной мере поддержаны и воплощены в софте.

Дальше есть вопрос с методами проведения исследований. В принципе, есть такая область (дисциплина?) "управление знаниями", и там были исследования про явное и неявное знание, структуру знания и т.п. Но все это было давно, проводилось конкретными исследователями, которые имели дело с конкретными (единичными) объектами, и я лично - совершенно не представляю, насколько можно взять те методы, автоматизировать их на современном уровне и применить к тому большому массиву первичных данных, на который я указал. Если они не применимы, то возможно, есть другие методы, о которых я не знаю. Или тут есть задача отработки методики исследований как таковой, которая позволит на первичных данных построить абстрактные конструкции устройства мышления.

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

2. Эрик Эванс, разрабатывая DDD (Domain Driven Design, https://en.wikipedia.org/wiki/Domain-driven_design) в своей концепции ограниченных контекстов перенес шаблоны проектирования объектно-ориентированного подхода (ООП) на онтологическую работу - построение понятийной модели предметной области (домена). При этом сформулировал, что прежняя практика построения единой и непротиворечивой модели и связанного с ней понятийного аппарата является слишком сложной для реализации в темпе проекта (как и построение монолитного софта), и потому онтологии предметной области должны быть модульными, с точками расширения, и следует применять для их построения те же приемы, которые наработаны для построения софта в ООП (наследование, библиотеки общих частей, изоляция разных областей, инкапсуляция и т.п.). Последующее развитие DDD показало, что именно это является наиболее ценной частью концепции. Но сформулировано все это на языке IT и для IT-инженеров, и, как водится, It-шники не слишком заботятся о том, чтобы обратным ходом попробовать включить это в "большую науку", переформулировав в принятых там терминах и связав с другими концептами. Мне кажется, в рамках формулирования курса могло бы быть интересным подумать о включении в него и этой составляющей тоже.

3. Agile, итеративная разработка существенно изменил подход к проектированию, как мыслительный процесс, по отношению к водопадному подходу, предусматривавшему целостное проектирование. Насколько я представляю, это изменение существует в виде различных практик, но оно не отрефлексировано теоретически, все учебники о разработке софта написаны еще в старом подходе. Я из опыта знаю, что когда разрабатываешь софт в логике Agile, то есть регулярных демонстраций законченного и ценного функционала для пользователей, то и последовательность разработки и последовательность проектирования существенно отличается от того, что оказывается естественным, когда сразу делаешь проект целиком.

При этом мне представляется, что получившийся в Agile процесс мышления гораздо больше соответствует мышлению как поиску и решению проблем в мире, в условиях ограниченной и неполной информации, чем подход в рамках водопадной модели. А большинство моделей мышления разных школ соответствуют, скорее, водопадной модели как более стройной. Идея в следующем: (а) попробовать сформулировать те изменения, которые внес Agile на языке описания мышления (а не описания процессов), рассматривая проектирование и разработку софта именно как процесс мышления; (б) очистить эти изменения от специфики IT и обобщить. В процессе можно еще воспользоваться овеществленными следами мышления в IT, о которых я писал в п.1.

4. Частным, но важным проявлением такой аналогии я бы полагал изменения, которые сейчас происходят в lifecycle профессиональной деятельности человека. Если раньше она разворачивалась преимущественно в водопадной модели: школа - институт - работа по профессии, а смены профессии или дополнительное образование были редки и, скорее, исключениями, то сейчас она переходит к итеративной работе, непрерывному образованию на протяжении всей жизни. Если образование рассматривать как фазу проектирования (фрагмента) софта-человека, а работу по специальности - как фазу кодирования, и дальше сформулировать те изменения, которые принес Agile в разработку как изменения, которые произойдут с профессиональным путем человека, то. как мне кажется, можно получить достаточно интересную картину. Понятно, что такая штука имеет ограничения, как всякий межотраслевой перенос шаблона, но она позволит сформулировать ряд гипотез о будущем, с которыми далее работать - поскольку переход на Agile уже произошел и последствия доступны для анализа, а вот изменение профессионального пути еще только разворачиваются. Эта метафора уже в лежит стороне от создания курса по мышлению, однако она касается изменений, которые сейчас происходят в надсистеме (через пару уровней) и потому может быть интересной.

На этом - все. Текст получился достаточно длинным, и, возможно, для обсуждения его следовало разбить на несколько постов, так как пункты слабо связаны. Но поскольку я не очень знаю, насколько все эти идеи будут интересны в сообществе, пусть будет один пост.