Ключевая проблема сложности программирования как раз в том, что нормальным людям, если они не прирождённые математики, трудно думать абстрактно

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

Именно поэтому и возникают у 98,8% разработчиков те самые проблемы, о которых говорил в прошлой серии:

https://vk.com/wall-152484379_3527

Поэтому я хочу попробовать такой подход, что крутые абстрактные думательные машинки от MIT или CMU понижаем до прозаического повседневного понимания самого обычного программиста в виде набора формальных правил написания кода. Но это не может быть достигнуто путём переделки стандартных схем обучения в университетах/на курсах. Если бы это было возможно, то это уже было бы где-то в мире сделано. Такие классические подходы, как подробный разбор сложной темы в текстовых материалах, и множество сопроводительных примеров и задачек, тут уже не работают вот ровно потому, что обучить таким образом сильному абстрактному мышлению можно всё равно только способных к этому ребят. При том, что даже очень способные далеко не все рвутся этому обучаться ))) Им и так хватает их соображалки, чтобы зарабатывать 500т/месяц и при этом даже не особо напрягаться.

=

Уже писал об основной идее раньше, как буду это решать: систематизирую основные абстракции, которые удаётся выудить у разных гуру, и главное, представлю их в виде "тупого" дерева правил, которых надо придерживаться просто "по форме", вообще не думая. Сами абстракции в них полностью скрыты "под капотом". Содержания, семантики не касаемся, работаем только с "конкретным" видимым на экране кодом.

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

Будет это в таком формате, что те, кто у меня занимаются и уже работают, периодически получают особые небольшие дополнительные задания, которые должны будут применить к своим рабочим проектам, и потом сделать небольшой отчёт, или дать ссылку на гитхаб. Например, понизить цикломатическую сложность в какой-нибудь функции в два раза, или поработать с редактором кода, действующим на уровне логических структур (сейчас постепенно появляются такие уникальные, но малоизвестные проекты, скоро и AI-ассистанты к ним добавится), специально буду подбирать подходящие инструменты, и т. п. Основной акцент будем делать на приёмах снижения сложности проекта.

=

Пока единственный момент, который я пока не придумал как решить, это проектирование для начинающих. Как раньше говорил, начинающие курсанты программируют хорошо (programming in small), но путаются уже в простом проекте, где надо связать пять классов (проектирование в чистом виде, programming in large). На индивидуальных занятиях я бы обучил этому за несколько часов, сделали бы вместе несколько проектов, которые человеку интересно, и всё. Но к сожалению, это требует слишком много времени и совсем не масштабируется даже на три десятка курсантов.

А какие-то проэкты по шаблону давать делать, считаю, это зашквар :)

С шаблонными конечно справляются все, и даже близкие к ним по темам проекты получается потом сделать, но эффект от этого нулевой: как только надо что-то своё с нуля спроектировать, полный швах.

Проблема в том, что этому нигде в мире тоже не учат, потому что, как в прошлом посте говорил, классическое ООП — это про моделирование именно запутанных, противоречивых и нечётких систем и явлений, и кроме Алана Кэя, наверное больше почти никто и не умеет как следует это делать :) Поэтому, вероятнее всего, буду развивать дальше мой нынешний третий курс по ООАП, где разбираем методики проектирования Бертана Мейера (он на сегодня единственный фактически гуру из академической среды, кто вразумительно учит этим темам), дополняя его рекомендациями Кэя.

Тут конечно однозначно надо учить прежде всего умению формировать онтологию предметной области, без неё в проекте будет полная путаница.

=

А что касается "думательные машинки от MIT или CMU понижаем до прозаического повседневного понимания самого обычного программиста", то я решил, что будет это доступно бесплатно всем, кто у меня регулярно занимается на 1 августа 2022-го, и прошёл как минимум два трека "Как понять в программировании всё" и "Объектно-ориентированный анализ и проектирование". Причём доступно это будет бесплатно и пожизненно :) То есть те, кто все курсы пройдёт, всё равно сможете эти задания продолжать выполнять бесконечно долго.

Когда? В этом августе и начнём. Но это будет принудительно :)

Источник: vk.com

Комментарии: