Причинно-следственные связи. Почему трудно научиться программированию?

Однажды я решил научиться программировать, и у меня возникла идея следующего подхода: я планировал начать с джуниор-позиции, где бы меня обучали опытные тимлиды. Я рассчитывал научиться у искушенных коллег и при этом еще получать оплату за свою работу. Вдобавок к этому, я собирался изучать что-то дополнительно после работы. Таким образом, я надеялся быстро освоить программирование в живых условиях, работая над реальными проектами, и избежать рутины, связанной с долгим изучением и решением логических задач.

Работа в команде диктует нужный ритм и позволяет значительно улучшить свои навыки. Однако в таких условиях обучаться бывает сложно и практически невозможно. Работа требует высокой продуктивности, и постоянные вопросы и ошибки учащегося могут быстро раздражать всех остальных.

Компании стремятся сократить время разработки и повысить качество своих продуктов. Для этого они используют различные паттерны и подходы к проектированию архитектуры приложений. В большинстве случаев используется объектно-ориентированный подход и микросервисная архитектура.

Естественно, мне не удалось сразу освоить уровень абстракции и сложные концепции, потому что связи причинно-следствия еще не сформировались, и большая часть кода казалась для меня какой-то магией. Очень долго мой мозг отказывался воспринимать парадигму ООП.

Почему же лучшие практики программирования не даются сразу?

Вот тогда мне пришло в голову соображение из моего опыта верстки. Когда я изучал базовый CSS и HTML, я не использовал никакие метаязыки (less, sass), и только позднее стал использовать их. Я также использовал фреймворк Bootstrap. Использование Bootstrap не было проблемой, потому что я уже понимал основные принципы и связи причинно-следствия прослеживались легко. Но что было бы, если бы я начал с Bootstrap, не имея предварительных знаний о CSS? Скорее всего, это было бы очень сложно. То же самое произошло со мной в программировании - я пропустил основы и сразу взялся за более сложные вещи.

Приведу аналогию:

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

Почему всё усложняют?

Процедурный стиль программирования проще для восприятия человеком. Код формируется последовательно и каждое последующее действие проистекает из предыдущего.

Процедурный подход в программировании является более простым и прямолинейным подходом к написанию кода. Однако в сравнении с объектно-ориентированным подходом у него есть несколько недостатков:

1. Низкая модульность: Процедурный код обычно состоит из множества глобальных переменных, которые могут быть доступны отовсюду в программе. Это затрудняет понимание и отслеживание того, какие данные используются в разных частях кода. В результате повышается вероятность ошибок и усложняется сопровождение кода.

2. Отсутствие инкапсуляции: Процедурный подход не обеспечивает инкапсуляцию данных и функциональности. Это означает, что данные и функции могут быть свободно доступны и изменяемы в любой части программы. Это может привести к несогласованности данных и неявным изменениям состояния программы.

3. Повторное использование кода: В процедурном подходе код не всегда легко повторно использовать. Код может быть сильно связан с другими частями программы и использование его в другом месте может потребовать большого рефакторинга. В результате затрудняется создание модульного кода, который можно повторно использовать в различных проектах или частях программы.

4. Сложность сопровождения: Процедурный код обычно имеет линейную структуру и не предоставляет явных механизмов для обработки ошибок или расширения функциональности. Это затрудняет отслеживание и управление сложными потоками данных и логикой программы. В результате усложняется сопровождение кода и устранение ошибок.

5. Ограниченные механизмы абстракции: Процедурный подход не предлагает эффективных механизмов абстракции, что может затруднить создание сложных архитектур и моделей данных. В результате создание сложных и гибких систем становится более сложным и требует больше усилий.

6. Большая зависимость от глобального состояния: В процедурном коде состояние программы часто хранится в глобальных переменных или передается через аргументы функций. Это делает код более сложным и уязвимым для ошибок, особенно в многопоточных или распределенных системах.

В целом, процедурный подход может быть полезен для маленьких программ или быстрых прототипов, где простота и скорость разработки важнее сложности и гибкости кода. Однако для более крупных и долгосрочных проектов объектно-ориентированный подход предлагает более модульную, гибкую и поддерживаемую архитектуру.

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

Но, что если вы не имеете практики программирования в процедурном стиле? В этом случае, образование прочных нейронных связей в голове будет проблематично, за счет скрытя реализации некоторых функций. Возникают следующие трудности:

• отстутствие причинно-следственных связей. Не видишь каким образом те или ины компоненты связаны друг с другом.
• невосприятие к технической документации. Секрет успеха опытного программиста - умение пользоваться документацией. У человека с маленьким практическим опытом возникает впечатление отсутствие контекста в официальной документации и как правило отправляешься за информацией на сторонние блоги и форумы.
• отстутствие причинно-следственных связей. Не видишь каким образом те или ины компоненты связаны друг с другом.

Вот такие проблемы я выявил в моем небезупречном плане по обучению. В результате: прокрестинация, выгорание, эмоциональное переутомление и выбывание из игры на неопределенный период.

Чтобы я посоветовал себе, если бы мог отправиться в прошлое?

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

Да, это занимает время, но дело того стоит!

После таких практик было намного проще продожать изучение различных фреймворков и ООП. И после этого, я пришел к тем мыслям, которые изложил выше.