Программистские катакасты -- еще шаг от примата кода к примату процесса
Относительно новая мода -- катакасты (http://katas.softwarecraftsmanship.org/, все нужные ссылки с объяснениями -- http://katas.softwarecraftsmanship.org/?page_id=2).
Идея программистских ката проста и понятна, это идея обучения любому процессному навыку. Изучение НЛП начинается как раз с описания примера обучения вождению машины и подробно рассказывается про интериоризацию навыков. Музыкантам, танцорам, спортсменам этого тоже объяснять не нужно. Почему-то это нужно объяснять программистам (минут по десять каждое объяснение высококвалифицированными дядьками, и суть этого объяснения -- давайте брать в пример каратистов и музыкантов), и это объяснение почему-то программистов завораживает.
Я в далекой молодости тоже делал программистские ката: все в программировании мне давалось легко, только сортировка методом пузырька почему-то давалась трудно. Первый раз я ее кодировал часа полтора. Второй раз -- час. Третий раз -- полчаса. А еще через несколько раз -- писал свободно (пока не узнал, что сортировать пузырьком -- это стыдно). Примерно это объясняют при рассказе о программистских ката, причем тратят на это непропорционально много времени.
Я вначале даже не понимал, откуда столько восторгов. И только потом понял (хотя отнюдь не все из этого звучит в объяснениях самих программистов, это остается невысказанным):
а) это действительно радикальный сдвиг от обучения путем чтения чужих программ-результатов (наиболее распространенная парадигма обучения программированию: "хороший программист не тот, кто много кодирует, а тот, кто много читает чужой код") к обучению путем копирования процесса мастера. В ката учишься не "лучшим решениям", а учишься процессу их достижения. Учишься не дизайн-паттернам, а способам их вписывания в текст программы. Учишься процессу, а не структуре.
б) Тайминг важен. Читая книжку, невозможно понять ритм исходного действия. Ноты "Полета шмеля" не передают характера музыки, картинки характерных поз каратиста не передают скорости движений. В ката этот ритм очевиден. К тому же в книжке показать мультиоконное программирование невозможно, а видео решает проблему.
в) существеннейшая часть работы программиста перешла из кода в последовательность кодирования. TDD невозможно понять "по книжке": отсутствие ритма заставляет разбираться со многими похожими картинками (перескок между которыми дополнительно распыляет внимания) как с кинолентой, пытаясь восстановить движения по многочисленным похожим кадрикам. В результате TDD оказывается неосвоенным, и от него отказываются при легком дуновении дедлайнового ветерка. То же относится ко многим другим практикам: они сегодня относятся к процессу, а не к описанию результата. Процесс требует развертки во времени.
Современная форма программистских ката также требует перформанса, демонстрации другим людям. Так это же наш старый друг конструкционизм (http://en.wikipedia.org/wiki/Constructionist_learning) -- обучение заключается не столько в передаче знаний, сколько в создании каких-то значимых предметов и демонстрации их окружающим для получения обратной связи. В простейшей форме, это "набивание руки" на решении задач по уже освоенному материалу, переход осознанной компетентности в неосознанную, доведение мыслительного навыка до автоматизма -- но задачи эти нужно предъявлять, чтобы а) была цель, б) быть уверенным, что решил их правильно, в) получить обратную связь по улучшению.
Я вот думаю, какие могли бы быть ката в системной инженерии. И понимаю, что делать их нужно в САПР -- точно так же, как программистские ката делают в программных средах, а не с карандашом и бумагой. Учить нужно процессу, а не только результату. Недостаточно давать задачки типа "требования вот такие, найдите архитектурное решение". Нужно делать задачки в САПР, и затем добиваться ритма.
Но при программировании на DSL (а в САПР идет именно оно: программирование=моделирование на декларативных domain specific languages) почему-то нет тех практик, которые приняты при программировании на GPL (general programming languages). Но ведь суть та же! Значит, и приемы работы должны быть похожи, и приемы обучения.
Идея программистских ката проста и понятна, это идея обучения любому процессному навыку. Изучение НЛП начинается как раз с описания примера обучения вождению машины и подробно рассказывается про интериоризацию навыков. Музыкантам, танцорам, спортсменам этого тоже объяснять не нужно. Почему-то это нужно объяснять программистам (минут по десять каждое объяснение высококвалифицированными дядьками, и суть этого объяснения -- давайте брать в пример каратистов и музыкантов), и это объяснение почему-то программистов завораживает.
Я в далекой молодости тоже делал программистские ката: все в программировании мне давалось легко, только сортировка методом пузырька почему-то давалась трудно. Первый раз я ее кодировал часа полтора. Второй раз -- час. Третий раз -- полчаса. А еще через несколько раз -- писал свободно (пока не узнал, что сортировать пузырьком -- это стыдно). Примерно это объясняют при рассказе о программистских ката, причем тратят на это непропорционально много времени.
Я вначале даже не понимал, откуда столько восторгов. И только потом понял (хотя отнюдь не все из этого звучит в объяснениях самих программистов, это остается невысказанным):
а) это действительно радикальный сдвиг от обучения путем чтения чужих программ-результатов (наиболее распространенная парадигма обучения программированию: "хороший программист не тот, кто много кодирует, а тот, кто много читает чужой код") к обучению путем копирования процесса мастера. В ката учишься не "лучшим решениям", а учишься процессу их достижения. Учишься не дизайн-паттернам, а способам их вписывания в текст программы. Учишься процессу, а не структуре.
б) Тайминг важен. Читая книжку, невозможно понять ритм исходного действия. Ноты "Полета шмеля" не передают характера музыки, картинки характерных поз каратиста не передают скорости движений. В ката этот ритм очевиден. К тому же в книжке показать мультиоконное программирование невозможно, а видео решает проблему.
в) существеннейшая часть работы программиста перешла из кода в последовательность кодирования. TDD невозможно понять "по книжке": отсутствие ритма заставляет разбираться со многими похожими картинками (перескок между которыми дополнительно распыляет внимания) как с кинолентой, пытаясь восстановить движения по многочисленным похожим кадрикам. В результате TDD оказывается неосвоенным, и от него отказываются при легком дуновении дедлайнового ветерка. То же относится ко многим другим практикам: они сегодня относятся к процессу, а не к описанию результата. Процесс требует развертки во времени.
Современная форма программистских ката также требует перформанса, демонстрации другим людям. Так это же наш старый друг конструкционизм (http://en.wikipedia.org/wiki/Constructionist_learning) -- обучение заключается не столько в передаче знаний, сколько в создании каких-то значимых предметов и демонстрации их окружающим для получения обратной связи. В простейшей форме, это "набивание руки" на решении задач по уже освоенному материалу, переход осознанной компетентности в неосознанную, доведение мыслительного навыка до автоматизма -- но задачи эти нужно предъявлять, чтобы а) была цель, б) быть уверенным, что решил их правильно, в) получить обратную связь по улучшению.
Я вот думаю, какие могли бы быть ката в системной инженерии. И понимаю, что делать их нужно в САПР -- точно так же, как программистские ката делают в программных средах, а не с карандашом и бумагой. Учить нужно процессу, а не только результату. Недостаточно давать задачки типа "требования вот такие, найдите архитектурное решение". Нужно делать задачки в САПР, и затем добиваться ритма.
Но при программировании на DSL (а в САПР идет именно оно: программирование=моделирование на декларативных domain specific languages) почему-то нет тех практик, которые приняты при программировании на GPL (general programming languages). Но ведь суть та же! Значит, и приемы работы должны быть похожи, и приемы обучения.