Интересное замечание, что люди пытались/пытаются формализовать методы, и что эти попытки часто приводят к сложным и трудночитаемым моделям. Это связано с тем, что методы сложно разложить на простые составляющие из-за их зависимости от контекста и множества факторов.
Зачем формализовать - понятно: лучше передача знаний, стандартизация и повторяемость, улучшение коммуникации.
А вышли из этого путем описания на естественном языке и применением SME(situational method engineering / ситуационной инженерии методов). Про естественный язык понятно, а в SME я так понимаю, что каждый раз происходила/происходит какая-то компиляция под текущие условия.
Пример который я вспоминаю - мы внедряли SCRUM, сначала пытались делать все точно по книжке, но потом постепенно отходили от книжной инструкции: например в какой-то момент надоело оценивать и договорились дробить задачи на ± одинаковые, т.е. вот прям сразу, на этапе заведения задач.
Я так понимаю случился своего рода SME. Но все равно важный момент - что это не откуда-то из ниоткуда появляется, а на базе каких-то существующих методов. Я так понимаю, что важный момент тут - признание и фокус на том, что то, что вы найдете в “учебниках” вас не удовлетворит, но если сами подумаете и допилите - то можно сделать хорошо.
Ну и важная мысль этой главы - что нужно думать о методах и искать более эффективные. При чем скорее всего эффективные методы уже есть и кем-то описаны, нужно их только найти и применить. Можно и свое придумывать, но если только начинаешь - вряд ли придумаешь что-то дельное. Но “подпилить” - это вполне.
Это очень применимо и в разработке софта, эта область “славится” своим велосипедостроением, сам неоднократно этим занимался.
Еще раз про деятелей. Мышление не является пассивным процессом; оно включает в себя физические действия по изменению мира и себя. Без практического применения результаты мышления теряют значение. Мышление и действие взаимосвязаны и дополняют друг друга.
Еще интересно про структуру метода:
Структура метода: Альфа метода имеет три важных подальфы:
- Дисциплина/теория/объяснения/алгоритм: описание метода, которое становится мастерством исполнителя
- Инструментарий: средства, поддерживающие выполнение метода.
- Предметы метода: объекты, которые изменяются или обрабатываются с помощью метода.
Как я это понял на примере разложения “разработка программного обеспечения” на 3 подальфы:
-
Дисциплина/теория/объяснения/алгоритм:
Это знания и принципы, лежащие в основе разработки ПО(т.е. обеспечивает теоретическую базу и понимание того, как следует разрабатывать программное обеспечение):- Принципы программирования: объектно-ориентированное программирование, функциональное программирование, принципы SOLID и DRY
- Алгоритмы и структуры данных: понимание того, как эффективно хранить и обрабатывать данные
- Методологии разработки: Agile, Scrum, Kanban, Waterfall
- Паттерны проектирования: шаблоны, которые помогают решать общие проблемы в программировании
- Теория тестирования: методы обеспечения качества, такие как модульное тестирование, интеграционное тестирование, OSS-Fuzz, etc.
Эти знания изучаются и превращаются в мастерство разработчика, позволяя ему эффективно применять их на практике
-
Инструментарий:
Это средства и инструменты, которые поддерживают выполнение метода разработки ПО(предоставляет средства для практического применения этой теории и облегчения процесса разработки):- Интегрированные среды разработки/редакторы: Visual Studio Code, Goland, Sublime, Vim, etc.
- “продвинутые помощники”(не знаю как их обозвать), всякие LLM-ы: Github copilot, claude, etc.
- Системы контроля версий: Git, SVN, Mercurial
- Системы управления проектами: Jira, Trello, Asana
- Инструменты для тестирования: Selenium, k6, go-fuzz, etc.
- Компиляторы и интерпретаторы: GCC, Java Virtual Machine, Python Interpreter, etc.
- Базы данных и инструменты работы с ними: SQLite, PostgreSQL, Oracle, MongoDB, etc.
Этот инструментарий разворачивается на рабочем месте разработчика и позволяет ему применять свое мастерство для создания и изменения программного обеспечения
-
Предметы метода:
Это объекты, которые изменяются или создаются в процессе разработки(те объекты, над которыми работает разработчик, применяя свою дисциплину и инструментарий для их преобразования):- Исходный код: файлы с кодом на разных языках программирования
- Документация: технические спецификации, пользовательские руководства
- Гипотезы использования: описания функциональности, которую должна обеспечить программа
- Тестовые сценарии: наборы тестов для проверки работоспособности кода
- Сборки и релизы: скомпилированные версии программ для распространения
- Баг-репорты: отчеты об ошибках для их последующего исправления
В ходе работы разработчик преобразует эти предметы метода из одного состояния в другое. Например, из набора гипотез создается исходный код, который затем превращается в работающую программу