План изучения программирования | Python | Часть 1⁠⁠

Приветствую, это 1 часть ‘плана изучения программирования’. Первые 4 пункта - об учебных материалах(они идут в порядке их прохождения), 5 и 6 - о самом процессе программирования(моменты на которые стоит обратить внимание). Чтобы не получилось текстовой вакханалии(как в прошлых постах), в дальнейшем будет именно такой формат - только основные моменты. Посты дополняющие/раскрывающие план, будут на моём канале - https://t.me/tobeprog .

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

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

1. Для начала, нужен синтаксис, самые основы. Свейгарт[Автоматизация рутинных задач с помощью Python] - идеальный вариант, не перегруженный, понятный, с интересными задачами, к тому же, по пути задаваемым книгой и будет дальнейшее движение этого плана.

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

2. Чтобы понять процесс программирования, для начала надо его увидеть. https://www.youtube.com/watch?v=vpyWbpdk3Xs - уникальный пример, где автор показывает процесс мышления при написании программы, к сожалению, в ру сегменте больше ничего подобного не нашел.

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

Почему автоматизация рутины?

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

Книга Свейгарта породила огромную волну материалов по "автоматизации". Если вбить на ютубе "python automation", то темы роликов будут от работы в Excel до знакомств в Tinder(десяток подобных видео, и алгоритм рекомендаций избавит от нехватки новых идей).

3. [опционально, но лишним не будет] https://stepik.org/course/575 - курс по автоматизации тестирования, нам интересны первые две его части. Там про selenium - инструмент, для автоматизации в браузере(это про - зайти на страницу, заполнить форму, нажать кнопочки, оставить комент и т.д. и т.п.).

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

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

Составляющие процесса программирования

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

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

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

Кусочные правила:

5.1.Самое важное: Контроль происходящего

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

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

5.2. Кусочки кода должны быть универсальными - будет намного удобней с ними работать. Есть код, заполняющий таблицу из 10 строк, по ходу проекта, понимаем, нужно 25 строк и еще 2 столбца, потом 5 строк 5 столбцов и т.д.

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

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

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

Снова об уровнях

Какого-то строго перехода/переключения, с одного уровня на другой - нет(понимание придет на практике). Главное помнить - этап планирования происходит постоянно, он не заканчиваться блок схемой/псевдокодом, он параллелен написанию кода.

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

Прыгающие динозавры

Куда больше внимания планированию уделим в дальнейшем, пока обсудим лишь пару связанных с ним моментов. Для этого посмотрим туториал - https://youtu.be/bf_UOFFaHiY - программа сама играет в динозаврика в хроме. Основная идея проста - постоянно делаем снимки экрана, смотрим цвет пикселей в нужных местах, в игре всего два цвета, т.е. если цвет в определенном месте сменился с цвета фона, значит в этом месте препятствие, реагируем на это клавишей.

6.1. Главное препятствие в решении проблемы - взаимодействие с происходящем в игре. Мы его видим, а как сделать так, чтобы его видела программа? Худшим вариантом, будет решить - никак, и пытаться иначе решить проблему(спамить кнопки, пытаться понять алгоритм появления препятствий). Правильный способ - выделить подзадачу "определять что происходит на экране", и работать уже с ней(можно просто загуглить варианты это сделать), потом поймем, что нам нужен не весь экран, а только то, что происходит у носа динозавра и т.д.

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

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

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

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