План изучения программирования | Небольшое дополнение | Часть 2
Приветствую, Это не совсем самостоятельная часть плана, скорее небольшое дополнение к предыдущему посту. Пока, что бы было меньше путаницы, пускай это будет 2 часть. Главное - ее можно пропустить, на ход плана она не влияет. Со следующей части начнется computer science, и мы на время отойдем от python(но после cs, к нему вернемся), поэтому, в каком то смысле, эта часть сглаживает этот резкий переход. Посты дополняющие/раскрывающие план, будут на моём канале - https://t.me/tobeprog .
Прошлые части:
Часть 0 | План сосредоточенный на проблемах новичков, зачем очередной план и как он устроен?
Почему в следующей части сразу cs?
Специфика плана, из-за того, что он выстроен вокруг проблем, некоторые шаги будут не стандартными. Подробней в 0 части, кратко - не ждем когда проблема себя проявит в процессе изучения, а выстраиваем процесс изучения вокруг проблем. На примере предыдущей части - проблема не понимания процесса программирования, она всплывает поздно и абсолютно не понятно что с ней делать, пласт уч. материалов изучен, но нет понимания как эти знания применять(как наконец то написать то, что хочешь).
Пользуясь тем, что сам процесс везде одинаков, выбираем удобный круг задач(автоматизация рутины), уч.материалы привязанные к большому количеству практики(по сути, там одна только практика), и спойлером на что стоит обратить внимание(все эти кусочки кода, 2 уровня и т.д.). Мы как бы искусственно приближаем проблему, и разбираемся с ней в удобных для нас условиях.
Не понимание процесса программирования - критически важная проблема, поэтому мы начали с нее. Дальше - изучение cs, дело в том, что даже понимая процесс программирования, и зная более менее синтаксис, можно проскочить изучение основ, фундаментальных вещей. В программировании все связано, поэтому так или иначе, придется эти основы узнать, но вместо растягивания на долгий период(если не систематизировано, то на ОЧЕНЬ долгий), мы сделаем это в начале, сэкономив кучу времени и нервов.
Небольшое дополнение:
Жалел, что не поделился этими 2 ссылками в прошлом посту, они сложнее - выбивались подхода, о котором писал выше
1. https://stepik.org/course/512 - курс по питону, для тех кто прошел основы. Стоит посмотреть хотя бы начало - там небольшой ввод в само устройство языка, стек вызовов, пространство имен, области видимости и прочее.
2. https://youtu.be/g6zzZxxifAw - один из лучших каналов для изучающих python. Ссылка на видео, где разбирают исходники одной python библиотеки. Думаю очевидно, насколько это ценный и редкий(тем более на русском) контент. Отдельно стоит отметить стримы с code review.
Немного о самом процессе
3.DRY [Don't repeat yourself(не повторяйся)]
Это один из принципов разработки, на самом деле, он намного глубже(о более сложных вещах), но это не мешает использовать его, в таком, максимально простом варианте. Не повторяйтесь, скорее всего это не нужно. Если в коде, подряд повторяется одно и тоже - нужен цикл, если повторяется, но в разных местах - нужна функция.
4. Псевдокод/блок схемы/комментарии нужны чтобы помогать
Именно помогать, а не мешать/раздражать/напрягать. Странная тенденция в некоторых курсах - буквально под каждую задачу заставляют делать эту, зачастую не нужную подготовку(псевдокод/блок схемы). Как, то что придумано для удобства может навязываться? Это просто бессмысленно. Особенно стоит насторожится, если вам начинают рассказывать про синтаксические правила псевдокода(их просто не существует) или построить блок схему к очередному "хелловорлду".
Очень естественным путем становится понятно зачем нужно все вышеперечисленное(те же, комментарии - ровно в тот момент, когда сам себе впервые задаешь вопрос - "почему/как/что я здесь написал?"), и если надобности в этом нет - то стоит задать вопрос "действительно ли задача этого требует?".
5. Самый верный способ понять 'что не так/где проблема' - построчный 'проход' кода(смотрим и объясняем себе же, что конкретно происходит в каждой строке)
Рациональность
6. Программирование всегда про рациональный подход
Лучше раньше об этом узнать(и принять), отпадет куча вопросов. Рациональность - в буквальном смысле слова, всегда выбираем более выгодный вариант.
Многих новичков смущает, что в ЯПах есть проблемы/неудобства, о которых все знают(и обсуждают), но, кажется, ничего по этому поводу не делают. Во-первых - это не так, ЯПы постоянно прогрессируют/исправляются, иногда плавно, иногда весьма радикально(когда Python разошелся на 2.x и 3.x версии). Во-вторых, не всегда исправление - рациональный вариант, к примеру, если оно коснется чего то глубокого, после него придется затратить кучу ресурсов(переписать огромное количество кода), учитывая 'наслоение' технологий друг на друга, это может, стать невыполнимой задачей.
Если в программировании, на первый взгляд, что-то кажется не рациональным, стоит взглянуть на всю систему в целом, с большой вероятностью, из виду упущен какой то важный момент.
К примеру, существование какой то распространенной практики всегда рационально, иначе она бы не распространилась. Возьмем те же, стандарты оформления кода(стиля), крайне удобная штука, но видно это будет, когда начнется работа с большим количеством кода(особенно чужого).
7. Язык программирования это инструмент, книги/курсы по япам это инструмент для изучения инструмента
Вроде бы, очень очевидная мысль. Но, на практике, отношение к уч.материалам противоположное - будто существует один, самый правильный вариант и нужно, сначала долго его искать, потом учить именно по строго определенной книге/курсу/методу. Как будто, это не один из вариантов(инструментов), а единственно возможный.
Если инструмент работает плохо, его надо менять. Определенные инструменты подходят под определенные задачи(материал подан отлично, за исключением одной главы, это может сильно затормозить, поскольку все вводы в ЯПы по одному сценарию(рациональный подход), можно получить те же знания из другого источника, а не топтаться на месте).