Суровый C++-ник скептически относится к пробело-чувствительности Python и считает ее бездонным источником ошибок? А как вам мнение, что ФП — хайповая тема и на самом деле все то же самое можно отлично сделать на ООП? Знакомо такое отношение? Надеюсь, что нет. Впрочем, скорее всего за свою карьеру вам доводилось сталкиваться с подобным. Об этом и хочу поговорить.
Про забывчивость
Есть вероятность, что вы сами думали подобным образом, просто не помните этого. Вообще, это довольно важная проблема: люди, которые чему-то научились, забывают о том, как они думали раньше. Это одна из вещей, которая делает обучение и передачу опыта таким сложным делом.
Лично я для себя это явление открыл, когда вдруг вспомнил, как я в детстве делал Bomberman’а на DarkBasic и в какой-то момент мне захотелось сделать режим hot seat (то есть именно то, чем эта игра вообще знаменита). У меня на тот момент уже был “главный цикл” для одиночного режима, в котором обрабатывалось все, что должно обрабатываться: ввод игрока, перемещение, установка и взрывы бомб, разрушение стен, подбор бонусов и т.п. В общем, классический такой симуляционный код. Но совершенно не модульный. Когда я говорю “главный цикл”, я именно это и имею в виду — FOR. Не FOR, вызывающий с десяток update’ов, а… FOR с десятком разнообразных подблоков прямо в нем (конечно, с огромными комментариями-шапками!).
Так и что, вы думаете, я сделал для реализации hot seat? Правильно, скопировал этот 2000-строчный FOR. Завернул его в другой FOR, по количеству игроков. Скопировал и поправил использование некоторых переменных — ну, чтобы в hot seat цикле вместо PlayerPosX использовалось PlayersPosX[i]. Переключение между этими двумя FOR’ами было через GOTO и вызывалось из другого цикла, который обрабатывал “главное меню”. Удивительная вещь: когда я недавно слушал про споры вокруг GOTO, то подумал, что не застал тех времен, когда эта возможность где-либо применялась. И вот только теперь, более детально вспоминая прошлое, я вдруг обнаружил, что и сам использовал GOTO весьма активно!
Про обучение
К чему я это все? К тому, что вещи, которые кому-то кажутся очевидными и такими же естественными, как почистить зубы перед сном, для кого-то просто слишком сложны. Сложны не потому, что человек глупый, а просто потому, что он еще не развил нужные навыки. Когда решаемая задача кажется настолько сложной, что челленджом является просто решить ее, то ни о какой красоте, простоте и сопровождаемости речи не идет…
Тут нужно сделать небольшое пояснение. Я все это говорю опираясь на свой опыт самоучки, у которого практика всегда шла вперед теории (зато как приятно потом читать теорию, когда ты понимаешь, о чем они говорят!). Возможно люди, которые входят в программирование сейчас, которые слушают всякие правильные курсы и читают одну из миллиона книг “для новичков”, не сталкиваются с такими проблемами. Возможно им сразу говорят, что такое модульность и простота, чем это хорошо. И они это сразу понимают и начинают применять. Да, определенно есть люди, которые научились программировать быстрее и лучше, чем я. Я с этим не спорю.
Но факт в том, что по какой бы дорожке обучения вы не шли, это все равно последовательный процесс. Сегодня вы знаете и умеете больше, чем знали вчера. А если сравнить вас сейчас и вас два года назад, то разница может быть ооочень значительной. И хоть вы и прекрасно живете в себе теперешнем, вы обычно совершенно не задумываетесь о том, как видели мир раньше.
Когда я говорю “дорожка обучения”, я не имею в виду методичное взбирание на гору. Я бы скорее сказал, что это огромное поле, с оврагами и холмами и вы вольны идти на все четыре стороны. И не факт, что движение в одном направлении как-то потом поможет в движении в другом. Разве что вы станете чуть выносливей. Можно углубиться в computer science, придумывать новые алгоритмы и писать неприемлемый с точки зрения продакшена код. Можно уйти во фриланс на ПХП (уже нет?) и ничего не знать о “кровавом энтерпрайзе”. А можно методично долбить Java/Spring/Hibernate. Думается, с точки зрения карьеры — это самый удачный вариант.
Учитывая острую потребность рынка в “опытных специалистах”, когда под опытом имеется в виду опыт использования конкретного фреймворка или языка, очень легко всю жизнь просидеть в одной области. Стоит ли говорить, что это несколько искажает наше представление о разработке ПО!..
Ловушка осведомленности
“Ха, я-то не такой”, думаете вы? Я занимаюсь фронт-эндом на JS, но держусь в курсе и других областей разработки. Читаю про другие языки, технологии.
Если это так, то здорово. Быть осведомленным правда важно и полезно. Но я говорю скорее о таких темах, в которых осведомленность… мало что значит. Из области навыков и ощущений, не из области понимания. Именно в этой области бывают самые жаркие баталии: линукс vs виндуз, статическая типизация vs динамическая, IDE vs текстовый редактор. Потому что приобретение таких навыков — процесс долгий и сложный. Кроме того, это меняет то, как мы вообще смотрим на мир. Именно поэтому ООПшнику, который никогда не писал функционально, так сложно понять эту сторону.
Другую сторону невозможно понять логически. Это как логически понять сноубординг или футбол. Ну, ездят на доске по снегу… разве в этом суть? Разве это то, как видят сноуборд сноубордисты? Единственный способ понять, в чем “фишка” emacs’а — засучить рукава и приготовиться к болезненным часам.
В том, что касается “священных войн”, интеллектуальная осведомленность может, напротив, сыграть дурную службу. “Зная” про какой-то язык, вы очень убедительно можете указывать на его слабые стороны в сравнении с вашим “основным” языком. Можно даже специально для этого прочитать всю документацию на него! Чтобы знать о всех его фичах. Чтобы можно было аргументированно доказывать, почему этот язык — говно.
Да-да, когда я пишу это так, оно звучит несколько… невежественно. Мол, только круглый идиот может поступать так. Печальная особенность идиотизма в том, что мы слепы к своему собственному :-(
Просто, это очень эмоциональная сфера. Мы начинаем думать на языке, он становится привычным, “нашим”, а признавать, что “наше” — так себе, как-то не приятно (по крайней мере до тех пор, пока у нас нет альтернативного “нашего”). Если не прикладывать сознательных усилий, то скатиться в эту ловушку очень легко. Именно поэтому я призываю всех к двум простым вещам.
- Не относитесь предвзято к незнакомым технологиям. Вместо поиска недостатков, ищите в них плюсы. Если какая-то технология вам кажется плохой, но вы с ней не работали — это тревожный знак1. Обращайте внимание на такие вещи.
- Отдавайте предпочтение активным действиям. По вечерам, вместо того, чтобы читать тематические ресурсы, садитесь и пишите код на незнакомом языке. В отличие от чтения, это формирует новый навык и меняет ваше мировосприятие. Я не говорю, что читать не надо. Просто, чтение требует меньших усилий и потому откатиться на него вы всегда успеете.
Примечания
- Тут нужно сделать уточнение, что я сейчас говорю не про вещи вроде PostgreSQL vs MySQL. И то, и другое — реляционные СУБД и разница между ними совершенно не значительна с точки зрения навыков. А вот если вы не хотите рассматривать NoSQL только потому, что это “всю жизнь SQL хватало”, то это уже странно…
Надеюсь правильно сформулировал сквозную идею статьи: “все технологии хороши и заслуживают быть изученными, а плохие технологии умерли и канули в лету”.
Обучаться полноценно, глубоко, с практическим пониманием дела сложно, но в основном из-за объемности. Не получится охватить все что заслуживание внимания. Мы ограничены во времени, а динамика создания “того что заслуживает внимания” совсем неутешительно ползет вверх. Программисты вынуждены кластеризироваться. Раньше можно было быть full-stack и знать HTML, JS, Java, MySQL и делать полноценный софт, а сейчас нельзя, каждый из элементов, будь то клиент или сервер, делится на столько подсистем, подуровней, что постичь все нереально.
Плюс, по поводу карьеры. Да, придется углубляться в то за что деньги платят, без этого никуда, но это не обязательно должен быть java-like back-end. Клиентские приложения тоже нужно кому-то разрабатывать, веб, мобайл, везде есть хорошие карьерные пути. И тот же computer science с его спагетти кодом, и тот же HLSL, который понять вообще не каждый может, все это направления движения в “поле”. Так что можно взять то что по душе и полировать эти знания, быть в теме того как все развивается.
Что касатеся осведомленности. Мне кажется это вторая важная составляющая развития. Первая это основное направление, тут нужно быть про, а вот вторая это “боковое зрение”, которе позволит сориентировать если из одного участка “поля” вас телепортируют в другой. Я часто был вынужден нырять с места в гущу разработки при этом не имея больших практических знаний целевой технологии. Но вот что помогало так это как раз наличие осведомленности. Официальные гайды или книжки дают обзорное знание, статьи на хабре подкрепляют его какими-то нетрадиционными аспектами, хаками, подводными камнями и прочим. Что в сумме строит базовое понимание технологии и позволяет избавиться от ступора когда дело дойдет до практики.
С примером про английский. Допустим нет времени учить его глубоко. Ок, тогда можно просто обзорно почитать что есть в языке. Артикли, падежи и прочее. Прочитать и забыть. Но как только припечет, и нужно будет срочно учить язык, будет уже легче, уже будут пусть не полноценные знанния, но знания которые позволят построить путь изучения, или план или даже пусть заведомо обратить на что-то дополнительное внимание. Это уже что-то.
Реюмирую. Все технологии важны, полезны и заслуживают внимания. Раз они есть значит есть применение. Спрос порождает предложение. Не все из них получится изучить или применить, но знать о них, пусть и бегло – стоит. Но следуя основной мысли статья – обижать технологию не стоит, а если хочется значит применяете ее не по назначению. Так что может таки у вас недостаточно обзорных знаний?
Для начала скажу, что полностью согласен со всем написанным. Проблема только в том, что первоначальный пост не очень четко выражал мою точку зрения. И твой комментарий помог мне это понять. Поэтому я взял на себя смелость отредактировать оригинальный пост. Что поменял:
– убрал некоторые пассажи, из-за которых могло сложиться впечатление, что я динамические ЯП и ФП ставлю выше, чем статические ЯП и ООП;
– явно указал, что говорю о навыках, а не о знаниях. Именно этот пункт мне самому был не до конца понятен. Надеюсь теперь стало чуточку ясней, о чем я хотел сказать.
То есть, возвращаясь к комментарию: сквозная мысль в том, что в мире программирования есть вещи, которые можно понять, только попробовав их. И их надо брать и пробовать, не просто читать о них. Это по-началу неприятно, может даже больно, но это делает нас лучшими программистами.
Еще раз повторю, с твоими замечаниями полностью согласен. Кругозор – вещь правильная и полезная, это я сомнению подвергать не собирался. Просто хотел сделать акцент на таком виде понимания, который формируется только в процессе практики, и на том, что недостаток такого понимания иногда ведет к тому, что разработчики начинают “обижать” незнакомые им технологии.
100% согласен! Но вот что я люблю больше всего это симбиоз кругозора и практичесного понимания. Прочитав про что-то я уже примерно понимаю область применения, а потом когда возникает задача, иду и пробую, получается – применяю, нет – ну значит ошибся.. но в большинстве случаев все получается как нужно, главное прочитав про что-то задать себе вопрос – Какую практическую задачу можно так решить? Я вот помню как таким же путем начал применять RX, корутины, акторы и еще кучу всего что само по себе довольно комплексно для полного охвата но ужимается в лаконичное описания для получения обзорных знаний.