Как стать программистом?

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

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

If you wish to make an apple pie from scratch, you must first invent the universe. (с) Carl Sagan

Конструкции

Казалось бы нельзя программировать не зная основы языка — его синтаксиса, но для самой первой программы которая печатает «Hello world!», синтаксис знать не нужно :) нужно знать только две конструкции.

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


public class MyClass {
    public static void main(String[] args) {
        System.out.print("Hello world!");
    }
}

Когда человек заканчивает писать этот код он еще не думает ни о каком синтаксисе, модификаторах доступности класса и метода, типах данных, аргументах и возвращаемом значении. Он думает, о том, что успешно сделал ctrl+c/v из учебника двух конструкций, первая, нужна всегда, для того что бы программа запускалась, а вторая собственно печатает сообщение. Это потом он будет разбираться со всем выше перечисленным, а сейчас он учит конструкции и создает текстовый файлик в котором записывает те которые считает наиболее полезными.

Синтаксис языка

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

Типы данных

Это первое что начинает выносить мозг нашего трудяги. С простыми типами все вроде бы понятно, или нет? Почему нужно столько конструкций что бы записать число? int, double, float, (un)signed short/long со своими обертками нужны только для записи десятичных чисел, двоичные, восьмеричные и шестнадцатеричные числа имеют свою форму записи. Непонятно почему нельзя сравнивать строки содержащие числа с числами. С массивами тоже не все так просто, помимо простых массивов есть еще списки, мапы, хеши и их производные сводящие с ума разнообразием малозаметных отличий, а потом оказывается, что еще и строка это тоже массив символов. Немного в сторонке стоит и покуривает enum, его ни массивом не назвать, ни объектом. О точно — объекты… Почему нельзя сравнить два объекта?

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

Если вам мало попробуйте разобраться с датами: перевести из одного календаря в другой с учетом временной зоны, потом представить в виде строки, или наоборот перевести строку в unix timestamp.

Функции

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

Некоторые функции запоминаются на память вместе с объектами которым они принадлежат (System.out.print), некоторые понятны из названия (Object.toString), некоторые нужно долго искать в документации (если таковая есть).

Объектно Ориентированное Программирование

Да-да те самые три кита инкапсуляция, наследование и полиморфизм. Что, четыре? Прототипирование, не, не слышал. Тут возникает целый ряд вопросов, думаю самый первый из них: что это за конструкция this и какая у нее область видимости. Дальше совершенно непонятна избыточность POJO. Зачем нужны статические утилитарные классы и зачем вообще создавать класс на каждый чих, если все можно напихать в один? Как сделать множественное наследование? Что такое рефакторинг?

Исключения

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

Потоки

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

Шаблоны программирования

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

Так вот в один прекрасный день, ‘младшему’ надоедает изобретать велосипед и он начинает изучать шаблоны проектирования. Эти шаблоны — всего лишь надстройка (конструкция) верхнего уровня над Объектно Ориентированным Программированием, ООП надстройка надо Функциональным Программирование (не тычте мне в лицо Java 8, вы знаете о чем я), ФП надстройка над Процедурным Программированием, ПП надстройка над двоичным кодом o_O . Грубо говоря шаблоны это еще один уровень абстракции.

Конкретные реализации этого уровня должны повышать производительность тем или иным способом, в местах где это необходимо, а не усложнять код. Как оперировать таким уровнем абстракции, как найти место где необходима оптимизация, как выбрать нужный шаблон, ведь это какие-то высокие материи в которые посвящены только задроты и ботаны? На самом деле мы каждый день оперируем куда более сложными конструкциями — мыслеформами.

Мыслеформы

Мы обычно не задумываемся о мыслеформах, самая простая из которых — существительное. Когда мы слышим существительное у нас в мозгу задействуются цепочки нейронов. С одной стороны эти цепочки раскладывают мыслеформу на более простые мыслеформы, так слово телевизор раскладывается на мыслеформы «первого круга»: социальная, метальная, физическая, историческая (первые что пришли мне в голову). Первый круг раскладывается на второй. Социальная — в голове возникают места где и при каких обстоятельствах люди могут смотреть телевизор. Метальная — что они смотрят, объясняются понятия: новости, ток-шоу, мыльная опера, фильм и тд. Физическая — в мозгу всплывают остатки школьного курса физики про радиоволны и имя Александра Белла. Историческая — на эту часть очень многие не обращают внимания, но тем не менее телевизор уже не то(р)т, какой его создали, и дело не в том что кинескоп уступил место гнущейся плазме, хотя и в этом тоже, показывают ведь совсем не то что раньше, хоровые ансамбли самодеятельности в народных костюмах уступили место поющим трусам и тд. Заметили что ящик у вас не ассоциируется с хором поющих на сцене бабушек, об этом я и говорю. С другой стороны мыслеформа должна усложниться поэтому к существительному дописываются прилагательные: большой/маленький, цветной/черно-белый, с кинескопом в огромной деревянном ящике или плазма с диагональю 40″. Из них отсекаются наиболее неправдоподобные варианты — вряд ли вам сейчас рассказывают об огромном черно-белом «электроне» накрытым бабушкиной кружевной салфеткой. В результате в голове остается несколько более менее правдоподобных вариантов с которыми вы и оперируете.

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

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