В своей колонке для dev.by Senior Android Developer Вячеслав Кацубо приводит пул правил для тех, кто пошёл на курсы по программированию, и тех, кто там преподаёт.  

Читать далее...

«Я прошёл курсы — я бог программирования и царь разработки», — частенько приходится читать сопроводительные письма к резюме с подобным настроением. Чем выше спрос на разработчиков, тем больше людей думают, что порог вхождения в отрасль крайне низкий. Ну, правда ведь — крупные компании набирают людей десятками, а то и сотнями ежегодно. Чем я хуже тысяч программистов в своём городе? И неужели нельзя быстренько окончить курсы и за год стать программистом?

Программистом нельзя стать за год. И порой даже за десять. Потому что программист — это не столько то, что ты умеешь делать, сколько то, как ты мыслишь. Поэтому, если хотите стать «просто программистом», не идите на курсы. А вот если хотите начать программировать, это уже совсем другая история. И мы отталкиваемся именно от этой цели, считая, что на курсы идут за знаниями, а не бумажкой.

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

Я пошёл на курсы, поэтому мне следует:

1. Ответить на вопрос «Зачем мне эти курсы: чтобы научиться или для бумажки?».

Если утвердительно ответили на первую часть, значит, вы не хотите стать «просто программистом», а стремитесь начать программировать. Тогда продолжаем. В противном случае не тратим время и деньги зря.

2. Постоянно задавать вопрос: «А что это?»

Очень часто начальным этапом обучения является работа со словами и строками. Многие считают, что это просто. Чаще всего потому, что глубоко не копают, не понимают сущность. Вот есть строка. А что это? Отвечают, что просто текст. Никто не рассказывает, что текст — это символы, которые идут один за другим. Кто-то может подумать, что это очевидно, однако для начинающих это обязательно надо проговаривать. Символы представляют собой цифру/набор цифр (не будем углубляться в кодировки). На практике часто возникают задачи по работе со строками или их символами. Добавление одного символа в середину строки может и казаться простой операцией, но ведь мы-то знаем, что это на самом деле далеко не тривиальная задача.

Для тех, кто в танке, пример на с++: выделить память под новую строку, скопировать первую часть старой строки до места добавления, положить добавляемый  символ, скопировать оставшуюся часть строки.

3. Не забывать про вопрос «А что, если?». Так вы получите не сырую информацию, а нужные вам знания.

Вам  сказали, что 1+1 = 2. А что, если 2+2? А 2+3? Сказали, что есть вот такая сортировка. А что, если сортировка будет другая? А как она работает? Вам дали лодку — разберите её на части, сделайте её анализ.

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

4. Всё применять на практике.

Получили знания — сразу же пишите код, каким бы простым он ни казался. Практика нужна всегда. Многие считают что запускать «Hello world» не обязательно всегда  это же понятно и просто. Но это делать необходимо. Скомпилировать и запустить. Все наши знания — это комплекс маленьких знаний и связи между ними. Пропустим что-то маленькое, и большой объём знаний получит ахилесову пяту, которая рано или поздно себя обнаружит.

Был у меня студент, который пропустил по курсу Java пакет Math, в итоге у него был свой MathHelper (sign, max, min, PI, E и т.д.). Любой программист со стажем над этим только посмеяться может.

5. Всегда ставить перед собой большие цели, располагая небольшим объёмом знаний.

Главное — помнить о системности математики, логики, программирования. Так вы приумножите знания за относительно короткий период времени.  Вам рассказали, как рисовать точку, нарисуйте две, четыре, шестнадцать, а потом напишите «Танчики».

Пример из практики. Как-то в рамках одного проекта надо было сделать табличку, которая крутится, а потом останавливается, и в ней меняется текст. Если попытаться решить эту задачу в лоб, крутить таблицу, делать трёхмерную графику, потребуется слишком много усилий и времени. Что делать? Анализировать. Как сделать эффект, что таблица крутится? Сузить по высоте и плавно разжимать обратно. Это одна строчка кода, трёхмерная графика вообще не нужна. Дальше начинается математический анализ. Как плавно раскрутить и так же плавно остановить таблицу? Строим график для нашего «виртуально угла поворота» (напоминаю, что угол транслируется в коэффициент вертикального масштабирования). Получим график косинуса [-PI/2,PI/2] и идеальный вариант — плавно возрастает, набирает обороты, относительно равномерно крутится на пике и плавно угасает. Что дальше? График есть. Как подсчитать угол? Вспоминаем курс вышки: угол в точке X представляет собой интеграл этой функции от начала до X.  Вот так у нас из комплекса знаний по разным направлениям получается элегантное и относительно простое решение (поверьте, считать один раз интеграл в разы проще, чем работать с матрицами в трёхмерном пространстве, там ведь ещё есть перспектива, камера, проекция, трансформация и много другой ереси)

6. Выполнили задание – обязательно сделайте работу над ошибками и детально разберите все провалы.

То, как делать не нужно — это очень ценный опыт.

Я преподаю на курсах, поэтому мне следует:

1. Самому участвовать в реальных проектах и программировать.

2. Сразу выделить людей, которые пришли учиться, а не за бумажкой. Именно им уделять большее внимание. Не надо проявлять интерес к тем, кто не проявляет интерес сам.

3. Давать знания систематизировано и раскладывать их на слои. Не надо человеку, который только пришёл учиться программировать под Android, сразу рассказывать, как переключать экраны с анимацией. Сначала надо научить, как открыть экран, как создать текст, показать картинку.

4. Акцентировать внимание на сущности. Если рассказываете о структуре данных, способах хранения, указателях, ссылках, списках, расскажите о различиях между массивом и связным списком. Почему это важно?

Пример.  

Возникла задача написать видеопроигрыватель. Настал момент работы с кадрами. Требуется отображать кадры в том порядке, в каком они поступили в память, иногда (при загрузке процессора) пропускать. Поскольку кадров несколько, значит их надо хранить в списках. А в каких? Массив — и мы получаем проблему с постоянным копированием. Список? А какой? ArrayList? Получим то же, что и с массивом. LinkedList? Уже лучше. Понимание принципов работы таких структур очень важно и любой, кто хоть немного понимает их,  сразу выдаст, что тут уместен «FIFO» список (он же «очередь»). Ради интереса я проверил и получил, что с ArrayList скорость воспроизведения падала почти в 1,5 раза.

5. Предлагать задания «со звёздочкой». Научили открывать экран и показывать на нём текст — дайте задание открыть экран и показать два текста. Научили нажимать на кнопку — попросите нажать на три кнопки в определённой последовательности.

6. Когда есть «если», на конкретных примерах рассказывать и про «то».

Приведу пример плохого обучения: если мы сделаем сортировку вот так, у нас всё будет круто. А что если не так, а по-другому, Почему именно так? Почему не иначе? Чем эта сортировка лучше других?

А вот хорошее обучение: если мы воспользуемся этой сортировкой, то всё будет хорошо, а если другой, мы не получим большого прироста скорости или качества. Потому что конкретно для нашей задачи эта сортировка подходит лучше.  И детально объяснить, почему.

7. Помнить, что лучшее обучение — «агрессивное». Нет, кричать и проявлять агрессию в её привычном понимании не надо. А вот поэтапно, системно, но целенаправленно бросать людей «в реку» — очень даже!

Пример.

Предположим, к вам пришли на курсы программирования под Android? План такой.

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

Вторая неделя — учите создавать кнопки, текст.

Третья неделя — работа с графикой.

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

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

С третьего месяца уже можно подключать к решению задач в рамках больших настоящих проектов.

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.