Что значит программировать, и почему многие не понимают этот процесс

Что значит программировать. Почему многие не понимают этот процесс. Как решить эту проблему. И почему программирование всегда про рациональный подход.

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

Мой канал в телеге - https://t.me/tobeprog (там о самих методах обучения и обзоры на уч.материалы).

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

Программирование - процесс который не понимают

Утрированный пример - есть менеджер, абсолютно не понимающий в разработке, и при этом стоящий над разработчиком(так быть, разумеется, не должно). Как он видит процесс работы программиста?

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

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

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

Довольно интересно наблюдать, как сами разработчики пытаются подобрать понятную метафору для этого процесса, к примеру, нередки сравнения с творчеством(если хочется покопаться в теме метафор, то довольно интересно это описывает Макконнелл, во 2 главе “Совершенного кода”)

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

При этом, со стороны программистов, эти свойства, эти описания и вообще сам процесс настолько очевидны/логичны/правильны, что об этом как будто бы, нет смысла даже говорить.

Немного про сам процесс

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

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

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

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

Зачастую, самому процессу программирования уделяют(если вообще уделяют) очень мало внимания. Нопо сути, яп - лишь инструмент, можно сказать переменная, а сам процесс программирования - постоянная. Именно поэтому, многие разрабы скажут, что абсолютно неважно с какого языка начнешь учить, и могут даже предложить достаточно экзотический вариант(сразу на ум приходит легендарная книга из 80-ых, написанная в MIT, где яп - lisp), главное - понять сам процесс.

Как же понять этот самый процесс?

Вернемся к тем 2-ум пунктам из поста про уч.материалы, но перед этим, пару слов о питоне и почему вообще, это один из лучших вариантов первого япа.

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

1. Чтобы понять процесс программирования, для начала надо его увидеть.(увидеть процесс программирования и досконально понять код - разные вещи, нам нужно именно само мышление).

https://www.youtube.com/watch?v=vpyWbpdk3Xs серия видео, где показан именно тот самый процесс мышления при написании программы.

Будет позитивной практикой, время от времени пересматривать и отмечать что-то новое, трекать свой прогресс. Можно считать видео ориентиром, когда подобный способ понят, понят и сам процесс программирования.

2. https://stepik.org/course/4519 курс в котором учат гуглить, искать на StackOverflow, читать документацию, и юзать библиотеки. Это тот самый подход, про такую - трушную практику. В каком то смысле, здесь учат делать, как в видео выше.

Забавная штука насчет этого курса, пару раз видел реакцию, из разряда - “какой ужас, в нем ищут ответы на StackOverflow”. Это идеально иллюстрирует то самое “непонимание процесса” из начала поста.

Программирование всегда про рациональный подход

Есть еще один важный момент, касаемый странных свойств процесса - программирование всегда про рациональность.

Лучше раньше об этом узнать(и принять), отпадет куча вопросов и сохранится куча нервов. Рациональность - в буквальном смысле слова, всегда выбираем более выгодный вариант.

Многих новичков смущает, что в тех же ЯПах есть проблемы/неудобства, о которых все знают(и обсуждают), но, кажется, ничего по этому поводу не делают. Во-первых - это не так, ЯПы постоянно прогрессируют/исправляются, иногда плавно, иногда весьма радикально(когда Python разошелся на 2.x и 3.x версии). Во-вторых, не всегда исправление - рациональный вариант, к примеру, если оно коснется чего то глубокого, после него придется затратить кучу ресурсов(переписать огромное количество кода), учитывая 'наслоение' технологий друг на друга, это может, стать невыполнимой задачей.

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

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